Text

NEI 20-07 Guidance for Addressing Software Ccf_Kscarola
	ML20351A218
Person / Time
Site:	Nuclear Energy Institute
Issue date:	08/31/2020
From:	Vaughn S; Nuclear Energy Institute
To:	Tekia Govan; Office of Nuclear Reactor Regulation
	Tekia Govan, NRR/DRO/IRAB, 301-415-6197
References
	Download: ML20351A218 (35)
	v • d • e

From: VAUGHN, Stephen To: Govan, Tekia Cc: Morton, Wendell; Rahn, David; Waters, Michael; Benner, Eric

Subject:

[External_Sender] DRAFT B - NEI 20-07 "Guidance for Addressing Software CCF in High Safety Significant Safety Related DI&C Systems" Date: Monday, August 31, 2020 2:03:41 PM Attachments: DRAFT B - NEI 20 Guidance for Addressing Software CCF in High Safety Significant Safety Related DI&C Systems.docx

Tekia, Attached is a draft of NEI 20-07 for the staffs informal review. We realize that there are several DI&C efforts underway thus far, but hopefully over the next 4-8 weeks the staff will get a chance to review the draft NEI 20-07 and be able to support a public technical discussion sometime this fall.

Regards, Steve STEPHEN J. VAUGHN l SENIOR PROJECT MANAGER, ENGINEERING AND RISK 1201 F Street, NW, Suite 1100 l Washington, DC 20004 P: 202.739.8163 M: 202.256.5393 sjv@nei.org This electronic message transmission contains information from the Nuclear Energy Institute, Inc. The information is intended solely for the use of the addressee and its use by any other person is not authorized. If you are not the intended recipient, you have received this communication in error, and any review, use, disclosure, copying or distribution of the contents of this communication is strictly prohibited. If you have received this electronic transmission in error, please notify the sender immediately by telephone or by electronic mail and permanently delete the original message. IRS Circular 230 disclosure: To ensure compliance with requirements imposed by the IRS and other taxing authorities, we inform you that any tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties that may be imposed on any taxpayer or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

Sent through www.intermedia.com

Draft B - NEI 20-07 GUIDANCE FOR ADDRESSING SOFTWARE COMMON CAUSE FAILURE IN HIGH SAFETY-SIGNIFICANT SAFETY-RELATED DIGITAL I&C SYSTEMS Draft B Prepared by the Nuclear Energy Institute August 2020

DRAFT B - August 2020 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.

DRAFT B - August 2020 Executive Summary Implementation of digital technology at nuclear power stations can provide significant benefits in 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 software common cause failure (CCF).

For a digital system to experience a software CCF there must exist a latent defect in the software.

Software defects can only be introduced through the software development process. Applying software development requirements for safety-related systems has allowed the NRC to consider a CCF coincident with a nuclear power plants accident analysis events as a beyond design basis event. However, the NRC still requires the industry to analyze for a CCF by way of a Defense-in-Depth CCF coping analysis using best estimate assumptions. At present the only NRC-approved methods for eliminating the consideration of CCF is by installing diverse equipment or by extensive testing that can only be applied to simple devices. This document provides an alternative to these two methods to eliminate the consideration of CCF for a safety-related system. This approach begins by establishing a set of first principles for the protection against software CCF in digital instrumentation and control (DI&C) systems and then subsequently decomposing these first principles into safe design objectives (SDOs). This document also proposes using an assurance case method to demonstrate that a safety-related application has sufficiently achieved these SDOs to provide reasonable assurance that the likelihood of a software defect being introduced during the software development process is sufficiently low and as a result, the likelihood of experiencing a software CCF is also sufficiently low, and therefore adequately addressed.

Numerous industries have managed to successfully implement software-based digital technology. Many of these industries manage extremely dangerous processes yet have found a way to safely and reliably 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 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 with over 1.6 billion hours of operation. The software used in these platforms was designed to a Safety Integrity Level (SIL) Systematic Capability of 3 as defined in IEC 61508. The research revealed no evidence that any of the platforms experienced a software CCF during the more than 1.6 billion hours of operation. Based on this research, it can be reasonably concluded that use of the guidance in IEC 61508 when developing platform software and extrapolating to application software will result in reasonable assurance that a latent software defect will not lead to a software CCF.

Based on evidence from EPRIs research, the nuclear industry has decided to apply the guidance in IEC 61508 when evaluating platform and application software in high safety-significant safety-related (HSSSR) systems and components. This document synthesizes from relevant guidance in IEC 61508 and other industry standards for establishing SDOs. Documenting an assurance case based on adherence to these SDOs will facilitate the demonstration of reasonable assurance that the HSSSR software will have a low likelihood of containing a software defect that could lead to a software CCF.

The guidance in this document is intended to be applied on digital upgrades to HSSSR systems and equipment. Although this guidance can be used for digital upgrades implemented under 10 CFR 50.59, digital upgrades to HSSSR SSCs will typically require a license amendment to implement.

DRAFT B - August 2020 This document was developed by the NEI Digital I&C Working Group, in support of the industry response to Modernization Plan #1 (MP#1) Protection Against Common Cause Failure in the NRCs Integrated Strategy to Modernize the Nuclear Regulatory Commissions Digital Instrumentation and Control Regulatory Infrastructure (SECY-16-0070, ADAMS Accession No. ML16126A140). MP#1, contained in of SECY-16-0070, is identified as a high priority within the NRC Action Plan.

DRAFT B - August 2020 TABLE OF CONTENTS 1 Introduction ..................................................................................................................................... 6 2 Background ...................................................................................................................................... 6 3 Definitions ........................................................................................................................................ 7 4 Purpose ............................................................................................................................................ 8 5 NRC Regulatory Framework Versus Implementation Level Activities to Address Software CCF .... 8 6 First Principles of Protection Against Software CCF ........................................................................ 9 7 Scope and Applicability .................................................................................................................. 12 8 Software CCF Evaluation Process................................................................................................... 12 9 Software at the Platform and Platform Integration Levels............................................................ 13 10 Software at the Application and Plant Integration Levels ............................................................. 15 11 Assurance Case Development........................................................................................................ 28 12 References ..................................................................................................................................... 28 Appendix A: Connection Between Software CCF First Principles and NRC Regulatory Framework........... 29 Appendix B: Assurance Case Development ................................................................................................ 33

DRAFT B - August 2020 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 analyses while random failures (e.g., hardware failures due to a degradation mechanism) are better understood. This document focuses on systematic failures due to a latent defect in software, and an approach to providing reasonable assurance through a quality software development process that the common cause systematic failure of an application is adequately addressed.

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 truedecreasing 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.

DRAFT B - August 2020 Prior to issuance of RIS 2002-22 Supplement 1 by the NRC in May 2018, there was a lack of NRC-approved guidance on addressing software CCF for safety-related systems. The lack of guidance resulted in regulatory uncertainty for both new and operating plants leading many licensees to avoid digital technology for safety-related systems. Consequently, the nuclear industry has been slow to adopt digital technology for HSSSR systems despite the need to replace obsolete analog and early digital components with modern technology thus not fully realizing the safety and economic benefits available from digital technology. RIS 2002-22 Supplement 1 provides this guidance for low safety-significant safety-related (LSSSR) systems. This document provides an approach to adequately address software CCF for HSSSR systems.

3 Definitions Common Cause Failure (CCF) - Loss of function to multiple structures, systems, or components due to a shared root cause [IEEE 603-2018].

Concurrent Trigger - A triggering condition on multiple segments/elements that occur at or about the same time.

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 and facilitate problem diagnosis [Adopted from RIS 2002-22 Supplement 1, Section 3.1.1].

Design Control Measures (DCMs) - The application of a formal methodology to the conduct of product development activities.

Latent Software Defect - Undetected errors in functional requirements, software design, or software implementation.

Process Discipline - Strict adherence to approved and documented methodologies and processes.

Random Failure - A failure occurring at a random time, which results from one or more of the possible degradation mechanisms in the hardware [IEC 61508-4, Section 3.6.5].

Safe Design Objective (SDO) - Objective criteria for addressing the potential for a software defect being 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.

DRAFT B - August 2020 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].

Systematic Capability - Measure (expressed on a scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of an element meets the requirements of the specified SIL, in respect of the 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].

Systematic Failure - Related in a deterministic way to a certain cause, which can only be eliminated by a modification of the design or of the manufacturing process, operation procedures, documentation, or other relevant factors. [IEC 61508-4, Section 3.6.6].

Triggering Condition - System states (conditions) that can manifest a latent software defect and create the potential for a software CCF.

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].

Verification - Confirmation by examination and provision of objective evidence that the requirements have been fulfilled [61508-4].

4 Purpose 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.

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.

RIS 2002-22 Supplement 1 provides guidance on evaluating software CCF for low safety-significant

DRAFT B - August 2020 safety-related systems and components. No guidance currently exists to adequately address HSSSR software CCF (other than by extensive testing).

In contrast, the nuclear industry has developed, and the NRC has endorsed, objective criteria for complying with the regulatory requirements associated with cyber security, electromagnetic compatibility (EMC) and human factors engineering (HFE) related activities. NEI 20-07 will provide objective criteria for evaluation of HSSSR software to adequately address software CCF.

This process of developing objective criteria to demonstrate that consideration of CCF of HSSSR software 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.

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.

NRC Regulatory Framework Software CCF First Principles Objective Criteria Application of SDOs (NEI 20-07)

Implementation Level (Evidence that SDOs are met)

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 bounding and 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

DRAFT B - August 2020 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 testing. A software defect in an I&C system is an error of commission or omission that results in the related plant systems or components not functioning or performing 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. Developing a method or combination of methods that can guarantee 100% complete and correct requirements for a digital-based system is extremely challenging. 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.

Developing a method or combination of methods than can guarantee 100% complete and correct software design and implementation is extremely challenging. 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.

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

DRAFT B - August 2020 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 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.

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

DRAFT B - August 2020 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 to maintain the plant in a safe state after it has reached safe shutdown; or

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) if no other automatic systems are available to provide the safety function, or no pre-planned manual operator actions have been validated to provide the safety function.

8 Software CCF Evaluation Process The software CCF evaluation process is illustrated in Figure 2.

DRAFT B - August 2020 Digital System or Component Is the SSC High SSSR? No Evaluate use of RIS 2002-22 Section 7.0 Supplement 1 Yes 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 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 assurance case to clearly document adherence to the SDOs as well as any exceptions taken to the guidance in this document.

9 Software at the Platform and Platform Integration Levels 9.1 Platform Software Systematic Capability Use of IEC 61508 as a source for developing SDOs to protect against software CCF is based on EPRI research as documented in EPRI 3002011817, Safety Integrity Level (SIL) Certification Efficacy for Nuclear Power [4]. The EPRI researchers reviewed failure data associated with nine operating platforms

DRAFT B - August 2020 containing SIL 3 certified software as defined by IEC 61508. The platforms reviewed had a cumulative operating history of over 1.6 billion hours. The researchers found no instances of software CCF in any of the SIL 3 certified platforms. The report concluded that SIL certifications appear to be an accurate indicator of software reliability at the platform level.

Based on the results of the EPRI report, SIL 3 systematic capability has been selected as a reasonable benchmark to excluding platforms for software CCF consideration.

9.1.1 Goals The safe design objectives for platform software systematic capability are intended to achieve the objectives or properties provided in the following clauses of IEC Std. 61508-3:

7.4.1 - Objectives

7.4.2 - General Requirements

7.4.3 - Requirements for Software Architecture Design

7.4.4 - Requirements for Support Tools, Including Programming Languages

7.4.5 - Requirements for Detailed Design and Development - Software System Design

7.4.6 - Requirements for Code Implementation

7.4.7 - Requirements for Software Module Testing

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

DRAFT B - August 2020 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.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

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 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

DRAFT B - August 2020

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.

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.

DRAFT B - August 2020 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 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 entities, 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 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.

DRAFT B - August 2020 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 If a full variability language is used for implementing the application software design, the 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 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

DRAFT B - August 2020

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 10.1.

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.

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

DRAFT B - August 2020

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 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, uses defined language features, supports detection of mistakes, and supports the design method.

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.

DRAFT B - August 2020 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.

10.5 Application Software Detailed Design and Development Quality 10.5.1 Goals 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 10.1

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

DRAFT B - August 2020 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 10.1.

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.

DRAFT B - August 2020 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 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

DRAFT B - August 2020

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.

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:

DRAFT B - August 2020 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 10.1

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 10.1.

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);

DRAFT B - August 2020 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 10.1 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 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 10.1 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 10.1, as well as completeness, consistency, and compatibility between the

DRAFT B - August 2020 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

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect 10.12.3 Safe Design Objectives Safe design objectives for achieving protection against concurrent, untested triggering conditions in the context of application software are as follows:

10.12.3.1 For each potentially hazardous control action identified via activities performed under SDO 10.1.3.2, causal factor scenarios related to the application software are identified and mitigated.

10.12.3.2 Analysis demonstrates that untested combinations of external and internal I&C system states have no impact on achieving the application software functional and performance requirements resulting from the SDOs provided in Section 10.1.

10.12.3.3 When equipment under the control of the I&C system is normally in the state needed to perform a safety function, the I&C system design has no inputs that will change state when the EUC is in its normal state, and non-normal states in the EUC are readily detectable via independent means. Administrative controls limit the duration of non-normal EUC states and limit the EUC in a non-normal state to one channel or division.

DRAFT B - August 2020 11 Assurance Case Development The Assurance Case is used to document adherence to platform and application software SDOs such that an auditor or inspector can clearly discern how each SDO was applied and how the software development complies with the first principles of protection against software CCF. Any exceptions taken to application of SDOs should be clearly documented with an explanation of why the excluded SDO was not applicable or essential to software development quality. Appendix B provides a suggested roadmap for developing the assurance case.

12 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. Regulatory Issue Summary (RIS) 2002-22, Supplement 1, Clarification on Endorsement of NEI Guidance in Designing Digital Upgrades in I&C Systems, May 2018.

4. Draft Revision 8 (August 2020) to Branch Technical Position (BTP) 7-19, Guidance for Evaluation of Defense in Depth and Diversity to Address Common Cause Failure due to Latent Defects in Digital Systems

5. IEC 61508, Edition 2.0, 2010-04, Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems

6. EPRI Report 30020011817, Final Report Dated July 2019; Safety Integrity Level (SIL) Certification Efficacy for Nuclear Power

7. EPRI 2018 Technical Report 3002011816, Digital Engineering Guide, Decision Making Using Systems Engineering

8. IEC 61513, Edition 2.0, 2011-08, Nuclear Power Plants - Instrumentation and Control Important to Safety - General Requirements for Systems

DRAFT B - August 2020 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 Requirements quality for safety-related software should meet the following applicable regulatory requirements in the following:

IEEE 603-1991 or IEEE 279 -1971 as incorporated by reference in 10 CFR 50.55(a)(h)

10 CFR 50.54(jj) and 10 CFR 50.55(i)

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 1, Quality Standards and Records

- GDC 2, Design Basis for Protection Against Natural Phenomena

- GDC 4, Environmental and Dynamic Effects Design Basis

- GDC 13, Instrumentation and Control

- GDC 19, Control Room

- GDC 20, Protection System Functions

- GDC 21, Protection System Reliability and Testability

- GDC 22, Protective System Independence

- GDC 23, Protective System Failure Modes

- GDC 24, Separation of Protection and Control

- GDC 25, Protection System Requirements for Reactivity Control Malfunctions

- GDC 28, Reactivity Limits

10 CFR Part 50, Appendix B Quality Assurance

- Criterion III, Design Control

b. Implementation and testing quality depend on design quality and process discipline

DRAFT B - August 2020 Design quality for safety-related software must meet the regulatory requirements in:

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 1, Quality Standards and Records

10 CFR Appendix B, Quality Assurance Criteria

- Criterion I Organization

- Criterion II Quality Assurance Program

- Criterion III Design Control Process discipline for safety-related software must meet the regulatory requirements in:

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 1, Quality Standards and Records

10 CFR Appendix B, Quality Assurance Criteria

- Criterion I Organization

- Criterion II Quality Assurance Program

- Criterion III Design Control

- Criterion V Instructions, Procedures, Drawings

- Criterion VI Document Control

- Criterion VII Control of Purchased Material, Equipment, and Services

- Criterion VIII Identification and Control of Materials, Parts, and Components

- Criterion XIII Handling, Storage and Shipping

- Criterion XIV Inspection, Test, and Operating Status

- Criterion XV Nonconforming Materials, Parts, or Components

- Criterion XVI Corrective Action

- Criterion XVII Quality Assurance Records

- Criterion XVIII Audits Implementation and testing quality for safety-related software must meet the regulatory requirements in:

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 1 Quality Standards and Records

- GDC 21 Protection System Reliability and Testability

DRAFT B - August 2020

10 CFR Appendix B, Quality Assurance Criteria

- Criterion I Organization

- Criterion II Quality Assurance Program

- Criterion III Design Control

- Criterion V Instructions, Procedures, Drawings

- Criterion VI Document Control

- Criterion XI Test Control

- Criterion XVII Quality Assurance Records

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. Commonality of software for safety-related software must meet the regulatory requirements in:

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 24, Separation of Protection and Control

10 CFR Appendix B, Quality Assurance

- Criterion III Design Control

b. A triggering condition depends on system conditions There are no regulatory requirements for triggering conditions or systems conditions

c. A concurrent triggering condition depends on timing and commonality of system conditions There are no regulatory requirements for concurrent triggers or timing. Commonality of system conditions is addressed in first principle 2a.

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 Limiting the impact of a software CCF on plant systems or components must meet the regulatory requirements in:

10 CFR Part 50, Appendix A General Design Criteria (GDC)

- GDC 24, Separation of Protection and Control

10 CFR Appendix B, Quality Assurance

DRAFT B - August 2020

Criterion III Design Control

b. An I&C system can be designed to force a preferred state in the event of a software CCF Forcing to a preferred state is a condition of quality and testing which are addressed in first principle 1.

c. Detection of an event or condition due to a software CCF provides an opportunity for response and recovery Detection of an event or condition due to a software CCF is related to quality and testing which are addressed in first principle 1.

4. Operating history can provide evidence of software quality Operating history is related to quality which is addressed in first principle 1.

DRAFT B - August 2020 Appendix B: Assurance Case Development The assurance case structure provided in this appendix was adopted from IEEE 15016-2. The assurance case starts with a top-level claim for the system and uses a structured argument and evidence to support the claim. Through multiple levels of subordinate claims, the structured argument connects the top-level claim to the evidence.

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

DRAFT B - August 2020 B.1 Assurance Case Claim Structure to Ensure Software CCF is Adequately Addressed Software CCF is Adequately Addressed Systematic Failure Likelihood is Sufficiently Low 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

ML20351A218

Text

Subject:

Navigation menu

Search