Latest revision as of 19:12, 20 January 2022

Text

Staff Detailed Comments - NEI 20_07 Draft Revision B -February 2021
	ML21050A090
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
	Govan T
References
	Draft B-NEI 20-07
	Download: ML21050A090 (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

1 2

3 4 Draft B - NEI 20-07 5

6 7

8 9

10 11 12 13 14 15 16 17 18 19 20 21 GUIDANCE FOR ADDRESSING SOFTWARE COMMON 22 CAUSE FAILURE IN HIGH SAFETY-SIGNIFICANT SAFETY-23 RELATED DIGITAL I&C SYSTEMS 24 25 Draft B 26 27 Prepared by the Nuclear Energy Institute 28 August 2020

DRAFT B - August 2020 1

2 3 Acknowledgements 4

5 NEI would like to thank the NEI DI&C Working Group for developing this document.

6 7

8 9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 NOTICE 42 43 Neither NEI, nor any of its employees, members, supporting organizations, contractors, or consultants 44 make any warranty, expressed or implied, or assume any legal responsibility for the accuracy or 45 completeness of, or assume any liability for damages resulting from any use of, any information 46 apparatus, methods, or process disclosed in this report or that such may not infringe privately owned 47 rights.

DRAFT B - August 2020 1

2 Executive Summary 3 Implementation of digital technology at nuclear power stations can provide significant benefits in 4 component and system reliability which can result in improved plant safety and availability. However, a 5 software defect in a digital system or component can introduce a safety hazard through a potential 6 software common cause failure (CCF).

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

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

24 25 Numerous industries have managed to successfully implement software-based digital technology. Many 26 of these industries manage extremely dangerous processes yet have found a way to safely and reliably 27 operate using digital technology by capitalizing on the use of quality software design standards, such as 28 IEC 61508. Research conducted by EPRI on the use of IEC 61508 for software development has revealed 29 conclusive results that demonstrate IEC 61508 safety integrity level (SIL) certified digital equipment 30 achieve their designated SIL reliability targets [4]. EPRI conducted a review of software-based platforms 31 with over 1.6 billion hours of operation. The software used in these platforms was designed to a Safety 32 Integrity Level (SIL) Systematic Capability of 3 as defined in IEC 61508. The research revealed no 33 evidence that any of the platforms experienced a software CCF during the more than 1.6 billion hours of 34 operation. Based on this research, it can be reasonably concluded that use of the guidance in IEC 61508 35 when developing platform software and extrapolating to application software will result in reasonable 36 assurance that a latent software defect will not lead to a software CCF.

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

44 45 The guidance in this document is intended to be applied on digital upgrades to HSSSR systems and 46 equipment.

47 Although this guidance can be used for digital upgrades implemented under 10 CFR 50.59, digital 48 upgrades to HSSSR SSCs will typically require a license amendment to implement.

DRAFT B - August 2020 1

2 3 This document was developed by the NEI Digital I&C Working Group, in support of the industry response 4 to Modernization Plan #1 (MP#1) Protection Against Common Cause Failure in the NRCs Integrated 5 Strategy to Modernize the Nuclear Regulatory Commissions Digital Instrumentation and Control 6 Regulatory Infrastructure (SECY-16-0070, ADAMS Accession No. ML16126A140). MP#1, contained in 7 Enclosure 1 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

2 3

4 1 Introduction 5

6 Digital instrumentation and control (DI&C) systems can be vulnerable to a software common cause 7 failure (CCF) as a result of a latent defect in the software or software developed logic, which could 8 defeat the redundancy achieved by the system architecture. When identical digital equipment is applied 9 across multiple trains of a safety related system, an undetected software defect could be triggered by 10 certain plant and/or system conditions and cause a simultaneous failure of multiple safety related 11 trains. Similarly, when previously separate control functions are combined within the same digital 12 component or system, a latent software defect that is triggered by an untested condition can result in 13 simultaneous failure of multiple functions.

14 15 These types of common cause systematic failures may not have been considered in the plant safety 16 analyses while random failures (e.g., hardware failures due to a degradation mechanism) are better 17 understood. This document focuses on systematic failures due to a latent defect in software, and an 18 approach to providing reasonable assurance through a quality software development process that the 19 common cause systematic failure of an application is adequately addressed.

20 21 This approach begins by establishing a set of first principles for the protection against software CCF in 22 high safety-significant safety-related (HSSSR) digital I&C (DI&C) systems. Appendix A provides a mapping 23 between these first principles and NRC regulation. These CCF first principles, derived and synthesized 24 from EPRI research and industry operating experience, provides a framework for industry consensus on 25 the fundamental principles upon which an approach to adequately address CCF can be developed. From 26 these software CCF first principles a set of safe design objectives (SDOs) are established, synthesized 27 from IEC 61508 and other industry standards, that address the software CCF first principles. Ultimately 28 the licensee would demonstrate, using an assurance case demonstrating compliance to the SDOs, 29 providing reasonable assurance that the HSSSR DI&C system does not have a latent software design 30 defect that could lead to a software CCF, by demonstrating compliance to the SDOs.

31 32 2 Background 33 34 Compared to their analog counterparts, properly designed digital systems are generally more robust, 35 reliable, and more capable of preventing malfunctions of multiple controlled systems or components 36 using redundancy, logic, and other design attributes. In addition, digital technology can be provided with 37 the ability to select a preferred state on a controlled system in the event of a DI&C failure, thus 38 affording the designer some alternatives that can improve plant safety and reliability. Digital technology 39 can also provide immediate annunciation of problems with associated diagnostic capabilities not 40 available in their analog counterparts.

41 42 Software CCFs are the result of latent defects in the software triggered by an untested condition. Once 43 triggered, a software defect can lead to misbehavior of a system or component. The same software 44 defect in multiple trains of a safety-related system can be simultaneously triggered and lead to a 45 software CCF. The greater the likelihood of a software defect, the greater the likelihood of experiencing 46 a software CCF. The inverse is also truedecreasing the likelihood of a software defect will decrease the 47 likelihood of experiencing a software CCF. This document provides an approach to demonstrate that a 48 software CCF is adequately addressed for a HSSSR DI&C system. The approach is based on mature 49 industry standards, primarily IEC 61508, used worldwide in the development of high-quality software 50 used in high safety-significant systems.

DRAFT B - August 2020 1

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

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

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

20 21 Defensive Measures - Design attributes to prevent, limit, or reduce the likelihood of a software CCF.

22 23 Design Attributes - Hardware and software design features that contribute to high dependability. Such 24 features include built-in fault detection and failure management schemes, internal redundancy and 25 diagnostics, and use of software and hardware architectures designed to minimize failure consequences 26 and facilitate problem diagnosis [Adopted from RIS 2002-22 Supplement 1, Section 3.1.1].

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

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

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

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

38 39 Safe Design Objective (SDO) - Objective criteria for addressing the potential for a software defect being 40 introduced during the software development and integration processes.

41 42 Safety Classification (Classes) - An assignment based on functionality and safety significance. Different 43 safety classifications (classes) require different levels of requirements (e.g., Class 1E versus non-Class 1E, 44 or safety-related and non-safety-related).

45 46 Software - The programs used to direct operations of a programmable digital device. Examples include 47 computer programs and logic for programmable hardware devices, and data pertaining to its 48 operation [IEEE 7-4.3.2-2016].

49 50 Software CCF - The result of a latent software defect on multiple segments/elements due to a 51 concurrent trigger.

DRAFT B - August 2020 1

2 3 Software Tools - A sequence of instructions and commands used in the design, development, testing, 4 review, analysis, or maintenance of a programmable digital device or its documentation. Examples 5 include compilers, assemblers, linkers, comparators, cross-reference generators, de-compilers, editors, 6 flow charters, monitors, test case generators, integrated development environments, and timing 7 analyzers. (Adapted from IEEE Std 610'-1990].

8 9 Software Module - Construct that consists of procedures and/or data declarations and that can also 10 interact with other such constructs [61508-4 Clause 3.3.5].

11 12 Systematic Capability - Measure (expressed on a scale of SC 1 to SC 4) of the confidence that the 13 systematic safety integrity of an element meets the requirements of the specified SIL, in respect of the 14 specified element safety function, when the element is applied in accordance with the instructions 15 specified in the compliant item safety manual for the element [61508-4].

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

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

23 24 Validation - Confirmation by examination and provision of objective evidence that the requirements for 25 a specific intended use are fulfilled. [61508-4 Clause 3.8.2].

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

29 30 4 Purpose 31 32 The purpose of this document is to:

33 34 1. Establish a set of DI&C software CCF first principles to provide a framework for industry 35 consensus on the fundamental principles upon which an approach to adequately address 36 software CCF can be developed. Appendix A provides a mapping between these first 37 principles and existing NRC regulatory framework.

38 39 2. Provide a set of SDOs, representing a decomposition of the first principles, that can be used 40 to demonstrate that a software CCF is adequately addressed.

41 42 3. Explain the use of an assurance case to demonstrate that the SDOs are adequately addressed 43 to reach the conclusion that a software CCF is adequately addressed for an HSSSR DI&C system.

44 45 5 NRC Regulatory Framework Versus Implementation Level Activities to Address Software CCF 46 47 NEI 20-07 is intended to fill the gap between the NRC regulatory framework and implementation level 48 activities associated with development of HSSSR software. This gap is filled by the establishment of a 49 consensus set of software CCF first principles and the detailed SDOs addressing those first principles.

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

DRAFT B - August 2020 1

2 3 safety-related systems and components. No guidance currently exists to adequately address HSSSR 4 software CCF (other than by extensive testing).

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

10 11 This process of developing objective criteria to demonstrate that consideration of CCF of HSSSR software 12 can be eliminated, involves establishing a set of first principles for software CCF for industry consensus, 13 and their relationship to the NRC regulatory framework. These first principles are then decomposed into 14 SDOs that serve to provide criteria for establishing that software CCF is adequately addressed for a 15 HSSSR DI&C system.

16 17 Figure 1 below illustrates how NEI 20-07 bridges the gap between the NRC regulatory framework and 18 implementation level activities associated with development of HSSSR software.

19 20 21 NRC Regulatory Framework 22 23 24 25 26 27 28 29 Software CCF First Principles Objective Criteria 30 31 32 (NEI 20-07) 33 34 Application of SDOs 35 36 37 38 39 40 41 Implementation Level 42 (Evidence that SDOs are met) 43 44 Figure 1 45 Connection Between NRC Regulatory Framework and Implementation Level Activities 46 47 6 First Principles of Protection Against Software CCF 48 49 The first principles against software CCF represent a synthesis of EPRI research and industry best 50 software design practices. The first principles listed in this section are considered bounding and 51 complete and represent the starting point for decomposition of SDOs. They include the role software 52 design defects play in the initiation of a systematic failure as well as first principle techniques to

DRAFT B - August 2020 1

2 3 adequately address the effects of latent software design defects. The first principles of protection 4 against software CCF will be achieved by executing the SDOs.

5 6 6.1 Software quality depends on complete and correct requirements, design, 7 review, implementation, and testing 8

9 Software quality depends on complete and correct requirements, design, review, implementation, and 10 testing. A software defect in an I&C system is an error of commission or omission that results in the 11 related plant systems or components not functioning or performing as required by the plant design.

12 13 6.1.1 Software design quality depends on requirements quality 14 15 Software design depends largely on a complete and correct understanding of the functional and 16 performance requirements of the affected plant systems and components. Developing a method or 17 combination of methods that can guarantee 100% complete and correct requirements for a digital-18 based system is extremely challenging. However, requirements engineering methods may be applied 19 with the appropriate rigor depending on the risks due to a requirements error.

20 21 6.1.2 Implementation quality depends on design quality and process rigor 22 23 It is important to differentiate design quality from implementation quality because design is about 24 decisions based on requirements and architecture while implementation is about realization of software 25 elements based on the design. Design quality is also a function of how completely and correctly the 26 design is expressed and reviewed. While implementation and test quality can be no greater than design 27 quality, inadequate implementation and test quality can result in an incomplete or incorrect realization 28 of the design.

29 30 Developing a method or combination of methods than can guarantee 100% complete and correct 31 software design and implementation is extremely challenging. However, engineering methods can 32 provide some measure of protection against an incomplete or incorrect design and such methods may 33 be scaled and applied with appropriate rigor depending on the risk significance of the affected system 34 elements.

35 36 6.2 Concurrent triggering conditions are required to activate a latent software defect 37 38 Failures due to a latent defect in software are systematic failures in that a requirements error or 39 omission, an incomplete or incorrect design, or an incomplete or incorrect implementation is a 40 necessary ingredient, as well as the plant or system states that can reveal incomplete or incorrect 41 requirements, design, or implementation. Undetected errors in requirements, design and 42 implementation are called latent defects, and the plant or system states that manifest them (and result 43 in failures) are called triggering conditions.

44 45 When defective DI&C equipment is running in multiple segments of a system and the system does 46 not function or perform correctly due to the latent defect when the system encounters the same 47 plant or system conditions in multiple segments (i.e., a concurrent trigger), the result is a software 48 CCF.

49 50 6.2.1 A common defect depends on the quality and commonality of the equipment

DRAFT B - August 2020 1

2 3 A common software defect is a single requirements, design or implementation error that is present in 4 two or more system elements (e.g., subsystems, controllers, control segments, divisions, etc.). If the 5 defect is discovered during system design, test or operation, then it should be corrected. If the defect 6 remains undiscovered (or uncorrected), then it is a latent defect.

7 8 6.2.2 A triggering condition depends on system conditions 9

10 A latent defect is a requirements, design or implementation error that remains undiscovered because 11 the actual system states or conditions applied or encountered during inspection, test and operations did 12 not reveal it. System states and conditions can range from the plant process states (fluid, electrical, etc.)

13 to faulted conditions (and how they are managed) in the platform or application software.

14 15 When in service and system conditions arrive at a state when the latent defect causes an incorrect or 16 incomplete functional response, or the defect causes the system to fail to meet performance 17 requirements, then the defect is considered triggered. If actual system conditions are constrained to 18 the same conditions applied or encountered during inspection, test and operations, and all defects 19 discovered during those conditions are corrected, then any remaining latent defects will not be 20 triggered.

21 22 6.2.3 A concurrent triggering condition depends on timing and commonality of system conditions 23 24 If a latent defect is present in two or more system elements but each element is encountering different 25 conditions, then the likelihood of it being triggered at the same time depends on how much difference 26 there is in the conditions encountered by each element or how much time it takes for each element to 27 encounter the same condition.

28 29 For example, a defect may be triggered in one element and detected/corrected in time before the same 30 defect is triggered in another element that encounters the same conditions, provided there is enough 31 time. In this case, the result is not a software CCF.

32 33 Note that two or more system elements that have the same latent defect and always encounter the 34 same conditions at the same time will trigger the defect in all elements at the same time if the triggering 35 conditions are encountered. In this case, the result is a software CCF.

36 37 6.3 The effects of a software CCF can be reduced by design 38 39 First Principles 6.1 and 6.2 are focused on the concept of prevention (albeit without a 100% guarantee) 40 as a means for protection against a software CCF. The principles of limitation, detection and 41 response/recovery also provides means for protection against software CCF with an emphasis on 42 reducing its effects.

43 44 6.3.1 The plant systems or components affected by a software CCF can be limited by design 45 46 The principle of limiting the number of plant systems or components that can be physically controlled or 47 affected by a system or subsystem where a software CCF is not adequately prevented will, by design, 48 limit the effects of the software CCF to just those systems or components.

49 50 For example, consider a system that applies the elements of one platform, and the system is composed 51 of many control segments where each segment is provided with redundant elements, such as a

DRAFT B - August 2020 1

2 3 main/backup pair of controllers. A software CCF of all control segments due to a latent defect in a 4 platform element common to all segments is adequately prevented. However, a pair of controllers in an 5 individual control segment do not encounter sufficiently different conditions such that a software CCF is 6 not prevented within that segment. In this case, limiting the number of plant components per segment 7 will limit the effects of a software CCF in one segment to just those components that are controlled by 8 that segment.

9 10 6.3.2 An I&C system can be designed to force a preferred state in the event of a software CCF 11 12 Software diagnostic features not subject to the software CCF can provide a means to detect and 13 respond by forcing an I&C system to a preferred state in the event of software CCF. A preferred state 14 may be fail- as-is, fail-off, shutdown, etc., with an attendant notification or alarm.

15 16 6.3.3 Detection of an event or condition due to a software CCF provides an opportunity 17 for response and recovery 18 19 Detection of a software CCF provides an opportunity to respond and recover from the event. If the 20 software CCF occurs in a system that can initiate a plant event, or it occurs in a mitigating system that is 21 required to respond to an initiating event, then independent means for detection and response via 22 automation and/or manual action can terminate the sequence of events within acceptable limits.

23 24 6.4 Operating history can provide evidence of software quality 25 26 Operating history can provide evidence of adequate software quality. The depth and rigor of acceptable 27 operating history (e.g., relevant, successful, substantial, available errata, etc.) from all safety industries 28 can also be scaled and matched to the risk of a software CCF in various system elements.

29 30 7 Scope and Applicability 31 32 Although the technical guidance in this document may be applied to any system or component that 33 contains software, the primary focus is on HSSSR DI&C systems. Risk insights from site-specific 34 probabilistic risk assessments (PRAs) can be used to support the safety-significance determination in 35 categorizing the DI&C system or component. Use of such risk insights should be an input to an 36 integrated decision-making process for categorizing the proposed DI&C system or component. The two 37 criteria below are additional inputs to consider in determining the high safety-significant categorization:

38 39 1. Safety-related SSCs relied upon to initiate and complete control actions essential to 40 maintain plant parameters within acceptable limits established for a DBE or to 41 maintain the plant in a safe state after it has reached safe shutdown; or 42 43 2. Safety-related systems and equipment whose failure could directly lead to accident 44 conditions that may cause unacceptable consequences (i.e., exceeds acceptable limits 45 for a DBE) if no other automatic systems are available to provide the safety function, 46 or no pre-planned manual operator actions have been validated to provide the safety 47 function.

48 49 8 Software CCF Evaluation Process 50 51 The software CCF evaluation process is illustrated in Figure 2.

DRAFT B - August 2020 1

2 3

Digital System or 4 Component 5

6 7

Is the SSC High SSSR? No Evaluate use of RIS 2002-22 Section 7.0 Supplement 1 8

9 Yes 10 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 11 12 Figure 2 13 HSSSR Software CCF Evaluation Process 14 15 Section 9 below provides goals and SDOs for evaluating HSSSR platform software. Section 10 provides 16 goals and SDOs for evaluating HSSSR application software. Section 11 describes the elements of an 17 assurance case to clearly document adherence to the SDOs as well as any exceptions taken to the 18 guidance in this document.

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

DRAFT B - August 2020 1

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

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

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

15 16

7.4.1 - Objectives 17

7.4.2 - General Requirements 18

7.4.3 - Requirements for Software Architecture Design 19

7.4.4 - Requirements for Support Tools, Including Programming Languages 20

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

7.4.6 - Requirements for Code Implementation 22

7.4.7 - Requirements for Software Module Testing 23

7.4.8 - Requirements for Software Integration Testing 24

7.5.2 - Requirements for Programmable Electronics Integration (Hardware and Software) 25

7.7.2 - Requirements for Software Aspects of System Safety Validation 26

7.9.2 - Requirement for Software Verification 27 9.1.2 Associated First Principles of Protection Against Software CCF 28 29

First Principle 6.1 - Software quality depends on complete and correct requirements, 30 design and implementation 31 32

First Principle 6.4 - Operating history can provide evidence of software quality 33 9.1.3 Safe Design Objectives 34 35 Safe design objectives for achieving platform software requirements quality are listed below:

36 37 9.1.3.1 The platform software, including user programmable integrated circuits (such as FPGA, 38 CPLD, ASIC, etc.), meets or exceed a systematic capability of SC3 (as for a SIL 3 system) as

DRAFT B - August 2020 1

2 3 described in IEC Std. 61508-3. If a platform does not have SC3 certification, the assurance 4 case should demonstrate how the platform meets the SIL 3 criteria in IEC 61508-3.

5 6 9.2 Platform Software Integration within a System Architecture 7

8 9.2.1 Goals 9

10

Platform software elements are described to the extent necessary to enable integration into 11 a system, subsystem, or element 12 13

When a platform software element is re-used or is intended to be re-used in other systems, 14 information about the element is sufficiently precise and complete to support an assessment 15 of the integrity of any safety functions that depend on the re-used element 16 17

Platform software element attributes are defined, including hardware constraints or 18 other software that must be accounted for during integration and application 19 20

Platform software element properties are described in terms of what the element is 21 designed for, including its intended behavior and characteristics 22 23 9.2.2 Associated First Principles of Protection Against Software CCF 24 25

First Principle 6.1 - Software quality depends on complete and correct requirements, 26 design and implementation 27 28

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent 29 software defect 30 31

First Principle 6.3 - The effects of a software CCF can be reduced by design 32 9.2.3 Safe Design Objectives 33 34 9.2.3.1 When platform software elements are integrated at the system level, subsystem level, or 35 among other elements, they are integrated in accordance with a safety manual that 36 complies with IEC 61508-2 Annex D or 61508-3 Annex D (for pre-existing platform 37 software elements).

38 39 10 Software at the Application and Plant Integration Levels 40 41 10.1 Requirements Quality 42 43 10.1.1 Goals 44 45 The safe design objectives for application software requirements quality are intended to achieve the 46 following goals:

47 48

Requirements correctly express system functions allocated to application software 49

Requirements completely express system functions allocated to application software

DRAFT B - August 2020 1

2

Application software requirements are unambiguous 3

Application software requirements are understandable 4

Application software requirements provide a basis for verification and validation 5

When application software functions of different safety classifications are required in one 6 system, independence between such software functions is expressly required (e.g.,

7 software functions within different safety classes do not interact or share data) 8 9 10.1.2 Associated First Principles of Protection Against Software CCF 10 11

First Principle 6.1 - Software quality depends on complete and correct requirements, 12 design and implementation 13 14

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent 15 software defect 16 17

First Principle 6.3 - The effects of a software CCF can be reduced by design 18 10.1.3 Safe Design Objectives 19 20 Safe design objectives for achieving application software requirements quality are listed below:

21 22 10.1.3.1 Application software requirements are derived from, and backward traceable to, the 23 functional and performance requirements of the affected plant systems and their 24 design and licensing bases.

25 26 10.1.3.2 A hazard analysis method is used to identify hazardous control actions that can lead to 27 an accident or loss, and application software requirements and constraints are derived 28 from the identified hazardous control actions.

29 30 10.1.3.3 The application software requirements resulting from activities performed under SDOs 31 10.2.3.1 and 10.2.3.2 are sufficiently detailed to support an assessment of functional safety.

32 33 10.1.3.4 Hardware constraints on the application software are specified and complete.

34 35 10.1.3.5 Application software functional and performance requirements are decomposed from I&C 36 system requirements, the I&C system architecture, and any constraints imposed by the 37 I&C system design.

38 39 10.1.3.6 If application software requirements are expressed or implemented via configuration 40 parameters, the specified parameters and their values are consistent and compatible 41 with the I&C platform and the I&C system requirements.

42 43 10.1.3.7 If data communications are required between application software elements and/or 44 between application software elements and external systems, data requirements 45 are specified, including best- and worst-case performance requirements.

DRAFT B - August 2020 1

2 3 10.2 Application Software General Quality 4

5 10.2.1 Goals 6

7 The safe design objectives for application software general quality are intended to achieve the following 8 goals:

9 10

The application software design fulfills the specified requirements 11

Application software requirements imposed by the hardware architecture are fulfilled, 12 including hardware/software interactions that influence the safety of the equipment 13 under control 14 15

The tools, languages, compilers, run-time system interfaces, user interfaces, and data 16 formats are suitable, and assist in verification and validation activities 17 18

The application software is analyzable and verifiable, and is capable of being safely modified 19

The required safety functions designed and implemented via application software are 20 achieved and verified 21 22 10.2.2 Associated First Principles of Protection Against Software CCF 23 24

First Principle 6.1 - Software quality depends on complete and correct requirements, 25 design and implementation 26 27

First Principle 6.4 - Operating history can provide evidence of software quality 28 10.2.3 Safe Design Objectives 29 30 Safe design objectives for achieving application software general quality are listed below:

31 32 10.2.3.1 When the application software can include or affect a number and/or variety of system 33 elements, and responsibilities for application software design of such elements are split 34 among two or more entities, then a clear division of responsibility (DOR) is developed and 35 agreed upon by all entities, and the DOR is maintained throughout the course of 36 application software development activities.

37 38 10.2.3.2 Abstraction and modularity are used to control complexity in the application software 39 design.

40 41 10.2.3.3 The application software design method aids the expression of functions; information flow; 42 time and sequencing information; timing constraints; data structures and properties; 43 design assumptions and dependencies; exception handling; comments; ability to represent 44 structural and behavioral views; comprehension by entities who need to understand the 45 design; and verification and validation.

46 47 10.2.3.4 Testability and modifiability in the operations and maintenance phase of the 48 system lifecycle is considered during application software design.

DRAFT B - August 2020 1

2 3 10.2.3.5 The application software design method has features that support software 4 modification, such as modularity, information hiding, and encapsulation.

5 6 10.2.3.6 Application software design notations are clearly and unambiguously defined.

7 8 10.2.3.7 The application software design elements are simple to the extent practicable.

9 10 10.2.3.8 If a full variability language is used for implementing the application software design, 11 the design includes self-monitoring of control flow and data flow, and on failure 12 detection, appropriate actions are taken.

13 14 10.2.3.9 Application software elements of varying safety classifications shall all be treated as the 15 highest safety classification unless adequate independence between elements of 16 different safety classifications is justified.

17 18 10.2.3.10 When a pre-existing application software element is used to implement a system function, 19 it meets the SDOs in Section 10.

20 21 10.2.3.11 When the digital equipment consists of pre-existing functionality that is configured via 22 data to meet application-specific requirements, the applied configuration design is 23 consistent with the design of the equipment. Methods are used to prevent errors during 24 design and implementation of the configuration data using specified configuration data 25 structures.

26 27 10.3 Application Software Architecture Design Quality 28 29 10.3.1 Goals 30 31 The safe design objectives for application software architecture design quality are intended to 32 achieve the following goals:

33 34

The application software architecture design is complete and correct with respect to 35 application software requirements 36 37

The application software architecture design supports freedom from intrinsic design faults 38 39

The method of expressing the application software architecture design promotes simplicity 40 and understandability 41 42

The application software architecture design promotes predictable behavior 43 44

The application software architecture design promotes verifiable and testable design 45 46

The application software architecture design promotes fault tolerance 47 48

The application software architecture design provides defense against common cause 49 failure from external events 50 51 10.3.2 Associated First Principles of Protection Against Software CCF

DRAFT B - August 2020 1

2

First Principle 6.1 - Software quality depends on complete and correct requirements, design 3 and implementation 4

5

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent 6 software defect 7

8

First Principle 6.3 - The effects of a software CCF can be reduced by design 9

10 10.3.3 Safe Design Objectives 11 12 Safe design objectives for achieving application software architecture design quality are listed below:

13 14 10.3.3.1 The application software architecture design uses an integrated set of techniques 15 necessary to meet the functional and performance requirements developed via the SDOs in 16 Section 10.1.

17 18 10.3.3.2 Application software architecture design is partitioned into elements or subsystems, and 19 information about each element or subsystem provides verification status and 20 associated conditions.

21 22 10.3.3.3 Application software architecture design determines hardware/software interactions 23 unless already specified by the system architecture.

24 25 10.3.3.4 Application software architecture design uses a notation that is unambiguously defined 26 or constrained to unambiguously defined features.

27 28 10.3.3.5 Application software architecture design determines the features needed for 29 maintaining the integrity of safety significant data, including data at rest and data in 30 transit.

31 32 10.3.3.6 Appropriate software architecture integration tests are specified.

33 34 10.4 Application Software Support Tool and Programming Language Quality 35 36 10.4.1 Goals 37 38 The safe design objectives for application software support tool and programming language quality are 39 intended to achieve the following goals:

40 41

Tools support the production of the application software and its required characteristics 42 43

Tool operation and functionality is clear 44 45

Tool output is correct and repeatable 46 47 10.4.2 Associated First Principles of Protection Against Software CCF 48 49

First Principle 6.1 - Software quality depends on complete and correct requirements, design 50 and implementation

DRAFT B - August 2020 1

2

First Principle 6.4 - Operating history can provide evidence of software quality 3

4 10.4.3 Safe Design Objectives 5

6 Safe design objectives for achieving application software tool and programming language quality are 7 listed below:

8 9 10.4.3.1 Application software is supported by on-line and off-line support tools. Off-line support 10 tools are classified in terms of their direct or indirect potential impacts to the application 11 software executable code.

12 13 10.4.3.2 An application software on-line support tool is an element of the system under design.

14 15 10.4.3.3 Application software off-line support tools are an element of development activities and 16 are used to reduce the likelihood of errors, and to reduce the likelihood of not detecting 17 errors. When off-line tools can be integrated, the outputs from one tool are suitable for 18 automatic input to a subsequent tool to minimize the likelihood of human error.

19 20 10.4.3.4 Offline tools have specified behaviors, instructions, and any specified constraints when 1) 21 they can directly or indirectly contribute to the executable code, or 2) they are used to 22 support the test or verification of the design or executable code where errors in the tool 23 can fail to reveal defects.

24 25 10.4.3.5 Offline tools are assessed for the reliance placed on them and their potential failure 26 mechanisms that may affect the executable application software when 1) they directly 27 or indirectly contribute to the executable code, or 2) they are used to support the test or 28 verification of the design or executable code where errors in the tool can fail to reveal 29 defects.

30 31 10.4.3.6 Offline tool conformance to its documentation may be based on a combination of history 32 of successful use (in similar environments and for similar applications) and its validation.

33 34 10.4.3.7 Tools are validated with a record of their versions, validation activities, test cases, 35 results, and any anomalies.

36 37 10.4.3.8 When a set of tools can function by using the output from one tool as input to another 38 tool then the set is regarded as integrated and they are verified to ensure compatibility.

39 40 10.4.3.9 The application software design representation or programming language uses a 41 translator that is assessed for suitability at the point when development support tools are 42 selected, uses defined language features, supports detection of mistakes, and supports 43 the design method.

44 45 10.4.3.10 If SDO 10.4.3.9 is not fully demonstrated, then the fitness of the language and any 46 measures to address identified shortcomings is justified.

47 48 10.4.3.11 Programming languages for developing application software are used per a suitable set 49 of rules which specify good practice, prohibit unsafe features, promote 50 understandability, facilitate verification and validation, and specify code documentation 51 requirements.

DRAFT B - August 2020 1

2 3 10.4.3.12 When offline tools are used, the application software configuration baseline information 4 includes tool identification and version, traceability to the application software 5 configuration items produced or affected by the tool, and the manner in which the tool was 6 used, when 1) the tool can directly or indirectly contribute to the executable code, or 2) the 7 tool is used to support the test or verification of the design or executable code where errors 8 in the tool can fail to reveal defects.

9 10 10.4.3.13 Offline tools are under configuration management to ensure compatibility with each other 11 and the system under design, and only qualified versions are used, when 1) the tool can 12 directly or indirectly contribute to the executable code, or 2) the tool is used to support 13 the test or verification of the design or executable code where errors in the tool can fail to 14 reveal defects.

15 16 10.4.3.14 Qualification of each new version of an offline tool may be demonstrated by qualification 17 of an earlier version if the functional differences will not affect compatibility with other 18 tools, and evidence shows that the new version is unlikely to contain significant faults.

19 20 10.5 Application Software Detailed Design and Development Quality 21 22 10.5.1 Goals 23 24 The safe design objectives for application software detailed design and development quality are 25 intended to achieve the following goals:

26 27

The application software detailed design and development is complete and correct with 28 respect to application software requirements developed per Section 10.1 29 30

The application software detailed design and development demonstrates freedom from 31 intrinsic design errors 32 33

The method of expressing application software detailed design promotes understandability 34 35

The application software detailed design demonstrates predictable behavior 36 37

The application software detailed design is verifiable and testable 38 39

The application software detailed design demonstrates fault tolerance / fault detection 40 41 10.5.2 Associated First Principles of Protection Against Software CCF 42 43

First Principle 6.1 - Software quality depends on complete and correct requirements, design 44 and implementation 45 46

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent 47 software defect 48 49

First Principle 6.3 - The effects of a software CCF can be reduced by design

DRAFT B - August 2020 1

2 3 10.5.3 Safe Design Objectives 4

5 Safe design objectives for achieving application software detailed design and development quality are 6 listed below:

7 8 10.5.3.1 Information items that describe application software requirements, architecture design, 9 and validation planning are completed prior to application software detailed design and 10 implementation activities and are used to inform the detailed design and its 11 implementation.

12 13 10.5.3.2 The application software is modular, testable, and modifiable.

14 15 10.5.3.3 For each major element or subsystem identified in the application software architecture 16 design produced via the SDOs provided in Section 10.2.3, further refinement into 17 application software modules is based on partitioning, and modules are designed in sets 18 suitable for integration and integration testing at the software and system levels.

19 20 10.5.3.4 Application software integration tests and software/hardware integration tests ensure 21 conformance to the requirements produced under the SDOs in Section 10.1.

22 23 10.6 Application Software Implementation Quality 24 25 10.6.1 Goals 26 27 The goals for application software implementation quality are as follows:

28 29

The method of expressing the application software implementation is readable, 30 understandable, and testable.

31 32

The application software implementation is performed using the results of SDO 10.4.3.11.

33 34

The application software implementation satisfies the design resulting from the SDOs 35 provided in Section 10.5 36 37 10.6.2 Associated First Principles of Protection Against Software CCF 38 39

First Principle 6.1 - Software quality depends on complete and correct requirements, design 40 and implementation 41 42 10.6.3 Safe Design Objectives 43 44 Safe design objectives for achieving application software implementation quality are listed below:

45 46 10.6.3.1 Each application software module is reviewed against the goals listed above.

47 48 10.6.3.2 When an application software module is produced by an automatic tool, the SDOs 49 provided in Section 10.4 are demonstrated.

DRAFT B - August 2020 1

2 3 10.6.3.3 When an application software module consists of reused pre-existing software, SDO 4 10.2.3.10 is demonstrated.

5 6 10.7 Application Software Module Test Quality 7

8 10.7.1 Goals 9

10 The goals for application software module test quality are as follows:

11 12

Completeness of module testing with respect to the application software design 13

Correctness of module testing with respect to the application software design specification 14

Module testing is repeatable 15

The module testing configuration is precisely defined 16 10.7.2 Associated First Principles of Protection Against Software CCF 17 18

First Principle 6.1 - Software quality depends on complete and correct requirements, design 19 and implementation 20 21 10.7.3 Safe Design Objectives 22 23 Safe design objectives for achieving application software module test quality are listed below:

24 25 10.7.3.1 Each application software module is verified (as specified via SDO 10.4.3.5) to perform 26 its intended function and does not perform unintended functions.

27 28 10.7.3.2 Application software module testing results are documented.

29 30 10.7.3.3 If an application software module test is not successful, corrective actions are specified.

31 32 10.8 Application Software Integration Test Quality 33 34 10.8.1 Goals 35 36 The goals for application software integration test quality are as follows:

37 38

Completeness of integration testing with respect to the application software design 39

Correctness of integration testing with respect to the application software design specification 40

Integration testing is repeatable 41

The integration testing configuration is precisely defined 42 10.8.2 Associated First Principles of Protection Against Software CCF

DRAFT B - August 2020 1

2

First Principle 6.1 - Software quality depends on complete and correct requirements, design 3 and implementation 4

5 10.8.3 Safe Design Objectives 6

7 Safe design objectives for achieving application software integration test quality are listed below:

8 9 10.8.3.1 Using the results of activities performed under SDO 10.5.3.4, application software 10 integration testing is performed using specified test cases, and test data; in a specified and 11 suitable environment; with specified acceptance criteria.

12 13 10.8.3.2 Application software integration tests demonstrate correct interaction between all 14 application software modules and/or application software elements/subsystems.

15 16 10.8.3.3 Application software integration testing information includes whether test acceptance 17 criteria have been met, and if not, the reasons why such that corrective actions are 18 specified.

19 20 10.8.3.4 During application software integration, any module changes are analyzed for extent of 21 1) impact to other modules and 2) rework of activities performed under prior SDOs.

22 23 10.9 System Integration Quality 24 25 10.9.1 Goals 26 27 The goals for I&C system integration and test quality are as follows:

28 29

Application software and system hardware are combined in a mutually compatible manner 30

System integration is complete and correct with respect to design specifications 31

System integration is repeatable 32

The integrated system configuration is precisely defined 33 10.9.2 Associated First Principles of Protection Against Software CCF 34 35

First Principle 6.1 - Software quality depends on complete and correct requirements, design 36 and implementation 37 38

First Principle 6.2 - Concurrent triggering conditions are required to activate a latent 39 software defect 40 41

First Principle 6.3 - The effects of a software CCF can be reduced by design 42 10.9.3 Safe Design Objectives 43 44 Safe design objectives for achieving system integration and test quality are listed below:

DRAFT B - August 2020 1

2 3 10.9.3.1 Application software is integrated with the system hardware in accordance with 4 SDO 10.9.3.2.

5 6 10.9.3.2 Using the results of activities performed under SDO 10.5.3.4, system integration testing is 7 performed using specified test types, test cases, and test data; in a specified facility with a 8 suitable environment; using specified software and hardware integration instructions; 9 and with specified acceptance criteria.

10 11 10.9.3.3 System integration testing information includes whether test acceptance criteria have 12 been met, and if not, the reasons why such that corrective actions are specified. During 13 application software integration, any module changes are analyzed for extent of 1) impact 14 to other modules and 2) rework of activities performed under prior SDOs.

15 16 10.10 System Validation Quality 17 18 10.10.1 Goals 19 20 The goals for system validation quality in the context of application software functions are as follows:

21 22

The integrated system complies with the requirements developed via activities under the 23 SDOs provided in Section 10.1 24 25

System validation is complete and correct with respect to design specifications 26

System validation is repeatable 27

The validation configuration is precisely defined 28 10.10.2 Associated First Principles of Protection Against Software CCF 29 30

First Principle 6.1 - Software quality depends on complete and correct requirements, design 31 and implementation 32 33 10.10.3 Safe Design Objectives 34 35 Safe design objectives for achieving system validation quality in the context of application software 36 functions are listed below:

37 38 10.10.3.1 System validation procedural and technical steps are specified in order to demonstrate 39 the application software meets the requirements produced via activities performed under 40 the SDOs in Section 10.1.

41 42 10.10.3.2 System validation information includes a chronological record of activities; the validated 43 functions; tools and equipment used; results; and any anomalies - including the reasons 44 why so that corrective actions are specified.

45 46 10.10.3.3 For application software, system testing is the primary method of validation, and the 47 system is tested by exercising inputs; exercising expected conditions (both normal and 48 abnormal);

DRAFT B - August 2020 1

2 3 and exercising hazards that require system action (as identified via activities performed 4 under SDO 10.1.3.2). Analysis, modeling, and simulation may supplement system testing.

5 6 10.10.3.4 Tools used for system validation meet the SDOs provided in Section 10.4.

7 8 10.10.3.5 System validation results demonstrate 1) all application software functions required via 9 activities performed under the SDOS in Section 2.1 are met correctly, 2) the application 10 software does not perform unintended functions, 3) test case results information for 11 later analysis or assessment, and 4) successful validation, or if not, the reasons why.

12 13 10.11 Application Software Verification Quality 14 15 10.11.1 Goals 16 17 The goals for application software verification quality are as follows:

18 19

Verification is complete and correct with respect to the results of activities performed under 20 the SDOs in Sections 10.1 and 10.3 through 10.9, unless such results are already demonstrated 21 via validation activities under the SDOs in Section 10.10 22 23

Verification is repeatable 24

The verification configuration is precisely defined 25 10.11.2 Associated First Principles of Protection Against Software CCF 26 27

First Principle 6.1 - Software quality depends on complete and correct requirements, design 28 and implementation 29 30 10.11.3 Safe Design Objectives 31 32 Safe design objectives for achieving application software verification quality are listed below:

33 34 10.11.3.1 Application software verification activities are specified: selection of strategies and 35 techniques; selection and utilization of tools; evaluation of results; and corrective 36 action controls.

37 38 10.11.3.2 Evidence of application software verification activities is recorded, including verified 39 application software configuration items; information used during verification; and the 40 adequacy of results from activities conducted under prior SDOs, including 41 compatibilities between prior activities.

42 43 10.11.3.3 Application software functional and performance requirements produced via activities 44 under the SDOs in Section 10.1 are verified against the I&C system requirements that are 45 identified via SDO 10.1.3.

46 47 10.11.3.4 The results of activities performed under the SDOs in Sections 10.2 through 10.6 are 48 verified to ensure conformance to the requirements produced via activities performed 49 under the SDOs in Section 10.1, as well as completeness, consistency, and compatibility 50 between the

DRAFT B - August 2020 1

2 3 results of the activities performed under the SDOs within each Section, and the feasibility, 4 readability, and modifiability of the results produced under the activities of SDOs in each 5 section.

6 7 10.12 Protection Against Concurrent, Untested Triggering Conditions 8

9 10.12.1 Goals 10 11 The goals for protection against concurrent, untested triggering conditions in the context of application 12 software are as follows:

13 14

The number of latent defects in the application software are minimal via preceding SDOs 15

Plant and/or plant system conditions that can trigger potentially hazardous behavior in 16 an application software element are identified, then mitigated in the I&C system design 17 18

Concurrent, untested triggering conditions among I&C system elements that have 19 identical application software elements have no impact on those system elements 20 21 10.12.2 Associated First Principles of Protection Against Software CCF 22 23

First Principle 6.1 - Software quality depends on complete and correct requirements, design 24 and implementation 25 26

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

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

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

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

DRAFT B - August 2020 1

2 3 11 Assurance Case Development 4

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

11 12 12 References 13 14 1. 10 CFR Part 50, Appendix A, General Design Criteria for Nuclear Power Plants 15 16 2. 10 CFR Part 50, Appendix B, Quality Assurance Criteria for Nuclear Power Plants and 17 Fuel Reprocessing Plants 18 19 3. Regulatory Issue Summary (RIS) 2002-22, Supplement 1, Clarification on Endorsement of 20 NEI Guidance in Designing Digital Upgrades in I&C Systems, May 2018.

21 22 4. Draft Revision 8 (August 2020) to Branch Technical Position (BTP) 7-19, Guidance for 23 Evaluation of Defense in Depth and Diversity to Address Common Cause Failure due to Latent 24 Defects in Digital Systems 25 26 5. IEC 61508, Edition 2.0, 2010-04, Functional Safety of 27 Electrical/Electronic/Programmable Electronic Safety Related Systems 28 29 6. EPRI Report 30020011817, Final Report Dated July 2019; Safety Integrity Level (SIL) 30 Certification Efficacy for Nuclear Power 31 32 7. EPRI 2018 Technical Report 3002011816, Digital Engineering Guide, Decision Making 33 Using Systems Engineering 34 35 8. IEC 61513, Edition 2.0, 2011-08, Nuclear Power Plants - Instrumentation and Control 36 Important to Safety - General Requirements for Systems

DRAFT B - August 2020 1

2 Appendix A: Connection Between Software CCF First Principles and NRC 3 Regulatory Framework 4 This Appendix describes the relationship between the first principles of protection against software CCF 5 and the NRC regulatory framework. The first principles are defined in detail in Section 6. For each first 6 principle below the associated NRC regulatory requirements are identified.

7 8 Note that the regulations listed below may not necessarily apply to all applicants and licensees. The 9 applicability of the regulatory requirements is determined by the plant-specific licensing basis and any 10 proposed changes to the licensing basis associated with the proposed DI&C system under evaluation.

11 12 1. Software quality depends on complete and correct requirements, design, review, 13 implementation, and testing 14 15 a. Design quality depends on complete and correct requirements 16 17 Requirements quality for safety-related software should meet the following applicable regulatory 18 requirements in the following:

19 20

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

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

10 CFR Part 50, Appendix A General Design Criteria (GDC) 23 - GDC 1, Quality Standards and Records 24 - GDC 2, Design Basis for Protection Against Natural Phenomena 25 - GDC 4, Environmental and Dynamic Effects Design Basis 26 - GDC 13, Instrumentation and Control 27 - GDC 19, Control Room 28 - GDC 20, Protection System Functions 29 - GDC 21, Protection System Reliability and Testability 30 - GDC 22, Protective System Independence 31 - GDC 23, Protective System Failure Modes 32 - GDC 24, Separation of Protection and Control 33 - GDC 25, Protection System Requirements for Reactivity Control Malfunctions 34 - GDC 28, Reactivity Limits 35 36

10 CFR Part 50, Appendix B Quality Assurance 37 - Criterion III, Design Control 38 39 b. Implementation and testing quality depend on design quality and process discipline

DRAFT B - August 2020 1

2 3 Design quality for safety-related software must meet the regulatory requirements in:

4 5

10 CFR Part 50, Appendix A General Design Criteria (GDC) 6 - GDC 1, Quality Standards and Records 7

8

10 CFR Appendix B, Quality Assurance Criteria 9 - Criterion I Organization 10 - Criterion II Quality Assurance Program 11 - Criterion III Design Control 12 13 Process discipline for safety-related software must meet the regulatory requirements in:

14 15

10 CFR Part 50, Appendix A General Design Criteria (GDC) 16 - GDC 1, Quality Standards and Records 17 18

10 CFR Appendix B, Quality Assurance Criteria 19 - Criterion I Organization 20 - Criterion II Quality Assurance Program 21 - Criterion III Design Control 22 - Criterion V Instructions, Procedures, Drawings 23 - Criterion VI Document Control 24 - Criterion VII Control of Purchased Material, Equipment, and Services 25 - Criterion VIII Identification and Control of Materials, Parts, and Components 26 - Criterion XIII Handling, Storage and Shipping 27 - Criterion XIV Inspection, Test, and Operating Status 28 - Criterion XV Nonconforming Materials, Parts, or Components 29 - Criterion XVI Corrective Action 30 - Criterion XVII Quality Assurance Records 31 - Criterion XVIII Audits 32 33 Implementation and testing quality for safety-related software must meet the regulatory requirements 34 in:

35 36

10 CFR Part 50, Appendix A General Design Criteria (GDC) 37 - GDC 1 Quality Standards and Records 38 - GDC 21 Protection System Reliability and Testability

DRAFT B - August 2020 1

2

10 CFR Appendix B, Quality Assurance Criteria 3 - Criterion I Organization 4 - Criterion II Quality Assurance Program 5 - Criterion III Design Control 6 - Criterion V Instructions, Procedures, Drawings 7 - Criterion VI Document Control 8 - Criterion XI Test Control 9 - Criterion XVII Quality Assurance Records 10 11 2. Concurrent triggering conditions are required to activate a latent defect 12 13 a. A common defect depends on the quality and commonality of the software 14 15 Quality of the software is addressed in first principle 1. Commonality of software for safety-related 16 software must meet the regulatory requirements in:

17 18

10 CFR Part 50, Appendix A General Design Criteria (GDC) 19 - GDC 24, Separation of Protection and Control 20 21

10 CFR Appendix B, Quality Assurance 22 - Criterion III Design Control 23 24 b. A triggering condition depends on system conditions 25 26 There are no regulatory requirements for triggering conditions or systems conditions 27 28 c. A concurrent triggering condition depends on timing and commonality of system conditions 29 30 There are no regulatory requirements for concurrent triggers or timing. Commonality of system 31 conditions is addressed in first principle 2a.

32 33 3. The effects of a software CCF can be reduced by design 34 35 a. The plant systems or components affected by a software CCF can be limited by design 36 37 Limiting the impact of a software CCF on plant systems or components must meet the regulatory 38 requirements in:

39 40

10 CFR Part 50, Appendix A General Design Criteria (GDC) 41 - GDC 24, Separation of Protection and Control 42 43

10 CFR Appendix B, Quality Assurance

DRAFT B - August 2020 1

2

Criterion III Design Control 3 b. An I&C system can be designed to force a preferred state in the event of a software CCF 4

5 Forcing to a preferred state is a condition of quality and testing which are addressed in first principle 1.

6 7 c. Detection of an event or condition due to a software CCF provides an opportunity for 8 response and recovery 9

10 Detection of an event or condition due to a software CCF is related to quality and testing which are 11 addressed in first principle 1.

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

DRAFT B - August 2020 1

2 Appendix B: Assurance Case Development 3

4 The assurance case structure provided in this appendix was adopted from IEEE 15016-2. The assurance 5 case starts with a top-level claim for the system and uses a structured argument and evidence to 6 support the claim. Through multiple levels of subordinate claims, the structured argument connects 7 the top-level claim to the evidence.

8 9 The assurance case is constructed by connecting key elements, which include:

10 11

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

14 15

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

17 18

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

20 21 A simplified diagram of an assurance case is shown in Figure B-1.

22 Top Claim Supports Supports Sub-claim 1 Sub-claim 2 23 Supports Supports Argument Argument Is evidence for Is evidence for Evidence Evidence Figure B Simplified Assurance Case Structure

DRAFT B - August 2020 1

2 3 B.1 Assurance Case Claim Structure to Ensure Software CCF is Adequately Addressed 4

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

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

Revision as of 18:56, 22 February 2021 (view source) StriderTol (talk \| contribs) (StriderTol Bot insert)	Latest revision as of 19:12, 20 January 2022 (view source) StriderTol (talk \| contribs) (StriderTol Bot change)
(One intermediate revision by the same user not shown)
(No difference)

ML21050A090: Difference between revisions

Latest revision as of 19:12, 20 January 2022

Text

Subject:

Navigation menu

ML21050A090: Difference between revisions

Latest revision as of 19:12, 20 January 2022

Text

Subject:

Navigation menu

Search