ML103120727

DG-1210, (Proposed Revision 1, of RG 1.173),Developing Software Lifecycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants

ML103120727
Person / Time
Issue date:	08/09/2012
From:	Sturzebecher K NRC/RES/DE
To:
Orr MP 301-251-7495
Shared Package
ML103090097	List: ML103120727 ML103120737
References
DG-1210 RG-1.173, Rev. 1
Download: ML103120727 (14)

Text

U.S. NUCLEAR REGULATORY COMMISSION August 2012 OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 DRAFT REGULATORY GUIDE

Contact:

K. Sturzebecher (301) 251-7494 This regulatory guide is being issued in draft form to involve the public in the early stages of the development of a regulatory position in this area. It has not received final staff review or approval and does not represent an official NRC final staff position.

Public comments are being solicited on this draft guide (including any implementation schedule) and its associated regulatory analysis or value/impact statement. Comments should be accompanied by appropriate supporting data. Written comments may be submitted to the Rules, Announcements, and Directives Branch, Office of Administration, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; submitted through the NRCs interactive rulemaking Web page at http://www.nrc.gov; or faxed to (301) 492-3446. Copies of comments received may be examined at the NRCs Public Document Room, 11555 Rockville Pike, Rockville, MD. Comments will be most helpful if received by November 23, 2012.

Electronic copies of this draft regulatory guide are available through the NRCs interactive rulemaking Web page (see above); the NRCs public Web site under Draft Regulatory Guides in the Regulatory Guides document collection of the NRCs Electronic Reading Room at http://www.nrc.gov/reading-rm/doc-collections/; and the NRCs Agencywide Documents Access and Management System (ADAMS) at http://www.nrc.gov/reading-rm/adams.html, under Accession No. ML103120727. The regulatory analysis may be found in ADAMS under Accession No. ML103120737.

DRAFT REGULATORY GUIDE DG-1210 (Proposed Revision 1 of Regulatory Guide 1.173, dated September 1997)

DEVELOPING SOFTWARE LIFE-CYCLE PROCESSES FOR DIGITAL COMPUTER SOFTWARE USED IN SAFETY SYSTEMS OF NUCLEAR POWER PLANTS A. INTRODUCTION This guide describes a method that the staff of the U.S. Nuclear Regulatory Commission (NRC) considers acceptable for use in complying with NRC regulations on the development of software life-cycle processes for digital computer software used in the safety systems of nuclear power plants.

The regulatory framework that the NRC has established for nuclear power plants consists of a number of regulations and supporting guidelines applicable to the development of software life-cycle processes for digital computer software. In Title 10, of the Code of Federal Regulations, Part 50, "Domestic Licensing of Production and Utilization Facilities," (Ref. 1), paragraph 55a(a)(1) requires, in part 1 that systems and components be designed, tested, and inspected to quality standards commensurate with the safety function to be performed. Also in 10 CFR Part 50, Appendix A, General Design Criteria for Nuclear Power Plants, the General Design Criterion (GDC) 1, Quality Standards and Records, requires, in part, that quality standards be established and implemented to provide adequate assurance that systems and components important to safety will satisfactorily perform their safety functions. Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants, of 10 CFR Part 50 describes criteria that must be met by a quality assurance program for systems and components that prevent or mitigate the consequences of postulated accidents.

In particular, in addition to the systems and components that directly prevent or mitigate the consequences of postulated accidents, the Appendix B criteria also apply to all activities, including design, purchasing, installation, testing, operation, maintenance, or modification, that affect the safety-related functions of such systems and components.

DG-1210, Page 2 In 10 CFR 50.55a(a)(1), the NRC requires, in part, that systems and components be designed, fabricated, erected, tested, and inspected to quality standards commensurate with the safety function to be performed. The regulations in 10 CFR 50.55a(h)(1), the NRC requires that reactor protection and safety systems satisfy the criteria in Institute of Electrical and Electronics Engineers (IEEE) Standard (Std.) 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear Power Generation Stations, issued 1991 (including a correction sheet dated January 30, 1995) (Ref. 2), or the requirements in IEEE Std. 279, Criteria for Protection Systems for Nuclear Power Generating Stations, issued 1971 (Ref. 3). These criteria shall be part of the evaluation of the recognized quality codes and standards selected for their applicability, adequacy and sufficiency and shall be supplemented or modified as needed to assure the production of a quality product that will perform the required safety function. The guidance on the safety systems equipment employing digital computer software or firmware requires quality standards in the use of the project life cycle process.

This regulatory guide endorses the guidance in IEEE Std. 1074-2006, IEEE Standard for Developing a Software Project Life Cycle Process, issued 2006 (Ref. 4), with the exceptions stated in the regulatory positions, as an method acceptable to the NRC staff for complying with NRC regulations to promote high functional reliability and design quality in software used in safety systems.1 In particular, the method is consistent with the previously cited GDC in Appendix A to 10 CFR Part 50 and the criteria for quality assurance programs in Appendix B to 10 CFR Part 50 as they apply to software development processes. The criteria of Appendices A and B apply to systems and related quality assurance processes, and the requirements also extend to the software elements if those systems include software.

The NRC issues regulatory guides to describe methods that the staff considers acceptable for use in implementing specific parts of the agencys regulations, to explain techniques that the staff uses in evaluating specific problems or postulated accidents, and to provide guidance to applicants. However regulatory guides are not substitutes for regulations and compliance with them is not required. The information provided by this regulatory guide is also in the Standard Review Plan, NUREG-0800, Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants: LWR Edition, Chapter 7, Instrumentation and Controls, (Ref. 5). The NRC staff uses the NRC Standard Review Plan to review 10 CFR Part 50 and 10 CFR Part 52, Licenses, Certifications, and Approvals for Nuclear Power Plants, (Ref. 6) license applications.

This regulatory guide contains information collection requirements covered by 10 CFR Part 50 and 10 CFR Part 73 that the Office of Management and Budget (OMB) approved under OMB control numbers 3150-0011 and 3150-0002, respectively. The NRC may neither conduct nor sponsor, and a person is not required to respond to, an information collection request or requirement unless the requesting document displays a currently valid OMB control number. This regulatory guide is a rule as designated in the Congressional Review Act (5 U.S.C. 801-808). However, OMB has not found it to be a major rule as designated in the Congressional Review Act.

B. DISCUSSION

=

Background===

The use of industry consensus standards is part of an overall approach to meet the requirements in 10 CFR Part 50 when developing safety systems for nuclear power plants. A licensees compliance with these standards does not guarantee that it will meet regulatory requirements. However, the licensees 1

The term safety systems is synonymous with safety-related systems. The GDC in Appendix A to 10 CFR Part 50 cover systems, structures, and components important to safety. However, the scope of this regulatory guide is limited to safety systems, which are a subset of systems important to safety.

DG-1210, Page 3 compliance with these standards does ensure that it will incorporate practices accepted within various technical communities into the development and quality assurance processes used to design safety systems. These practices are based on past experience and represent industry consensus on approaches used for the development of such systems.

This regulatory guide refers to software incorporated into the instrumentation and control systems covered by Appendix B to 10 CFR Part 50 as safety system software. For safety system software, the development of software requires the use of a carefully planned and controlled development process that incorporates the best available approaches to the various aspects of software engineering. A number of consensus standards provide guidance on implementing currently accepted approaches to specific software engineering activities such as software requirements specification, software testing and documentation, software verification, validation, reviews and audits, or software configuration management. A carefully planned and controlled software development effort should incorporate these specific activities into an orderly process within the software life cycle, including pre-software and post-software development processes. This regulatory guide addresses the subject of designing software life-cycle processes appropriate for the development of safety system software.

The following criteria in Appendix B to 10 CFR Part 50 contain requirements closely related to software life-cycle activities. These listed Criterions are only part of and not the entire requirement:

Criterion I, Organization, requires, in part, the establishment and execution of a quality assurance program.

Criterion II, Quality Assurance Program, requires, in part, that activities affecting quality are accomplished under suitably controlled conditions that take into account the need for special controls and processes to attain the required quality.

Criterion III, Design Control, requires, in part, that measures be established for the identification and control of design interfaces and for coordination among participating design organizations.

Criterion VI, Document Control, requires, in part, that all documents that prescribe activities affecting quality, such as instructions, procedures, and drawings, be subject to controls that ensure that authorized personnel review documents, including changes, for adequacy and approve them for release.

Criterion VII, Control of Purchased Material, Equipment, and Services, requires, in part, that measures are established to ensure that purchased material, equipment, and services, whether purchased directly or through contractors and subcontractors, conforms to the procurement documents.

Criterion XV, Nonconforming Materials, Parts, or Components, requires, in part, that measures are established to control materials, parts, or components that do not conform to requirements in order to prevent their inadvertent use or installation.

Criterion XVII, Quality Assurance Records, requires, in part, that sufficient records be maintained so that data that are closely associated with the qualification of personnel, procedures, and equipment are identifiable and retrievable.

DG-1210, Page 4 Description of Change The original version of this regulatory guide endorsed IEEE Std. 1074-1995. With the refocus on the life-cycle planning activities, which is the initiation task in devising a software project life cycle, the IEEE Std. 1074-2006 version realigns the original set of planning activities in to one activity group and adds a new section called Determine Security Objectives. In response to this new section, the Regulatory Guide 1.173 has also added a new Subsection Part C, 1, d, Secure Analysis, and acknowledges that planning for security and confirming the security accreditations is necessary and part of a secure analysis.

However, to meet criteria of IEEE Std. 603-1991 and 10 CFR 50, the development of digital safety system software requires a secure development and operational environment (SDOE) be provided, Regulatory Guide 1.152 provides specific guidance concerning the establishment of SDOEs. It should be noted that any material submitted in support of cyber security will not be reviewed as part of SDOE review.

Applicants should be aware that other NRC requirements and guidance may lead to specific cyber security controls during the software development process and/or the inclusion of security features in or around digital safety systems; however, a licensees adherence to the provisions of 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks, (Ref. 7) will be evaluated per regulatory programs specific to that regulation and in accordance with the applicant's NRC-approved cyber security plan. IEEE Std. 1074-2006 is not endorsed in this regulatory guide as being appropriate for compliance with 10 CFR 73.54.

There are other activities that have been added to the new IEEE Std. 1074-2006 version such as:

A.1.2.9 Plan Release Management, A.1.3.6 Close Project, A.2.3 Software Importation Activity Group of activities, and A.3.3.4 Manage Software Release, which are all supported activities to this Regulatory Guide 1.173.

Other alterations to the original have been made where the IEEE Std. 1074-1995, Clause 3.3, Software Quality Management Process was dropped from the 2006 version. The applicant and licensee should refer to Regulatory Guide 1.28 Quality Assurance Program Criteria (Ref. 8) for more information on this topic. The other process section, Verification and Validation Process, was removed from the IEEE Std. 1074-1995 version and transformed to a peer and/or technical review set of activities in the new Annex A.5.1, Evaluation Activity Group. In any lifecycle frame the developer should always provide review, audit, and test milestones for the software project. However, this does not alleviate the applicant or licensee from performing a formal software V&V, technical reviews, or audits to meet general quality and reliability requirements in GDC 1 or GDC 21, Protection System Reliability and Testability, of Appendix A to 10 CFR Part 50, as well as Criterion II, III, XI, and XVIII of Appendix B. Additional information and guidance for performing a software V&V can be found in Regulatory Guide 1.168 Verification, Validation, Reviews and Audits for Digital Computers Software Used in Safety Systems of Nuclear Power Plants (Ref. 9).

This revision to Regulatory Guide 1.173 has added a clarification statement to highlight one of the existing planning activities in IEEE Std. 1074-2006. This statement is found under Part C.4.d.,

System Transitions and states all changes to safety systems must be evaluated using the criteria specified in 10 CFR 50.59. If the change is outside the scope of 10 CFR 50.59 then it must be submitted for review as a licensing amendment request.

DG-1210, Page 5 Related Guidance In terms of inputs, development, verification or control processes, and outputs, IEEE Std. 1074-2006 describes a set of processes and constituent activities that are commonly accepted as comprising a controlled and well-coordinated software development process. It describes interrelationships among activities by defining the source activities that produce the inputs and the destination activities that receive the outputs. The standard specifies activities that the software will perform and their interrelationships. It does not specify complete acceptance criteria for determining whether the activities themselves are properly designed. Therefore, the standard should be used in conjunction with guidance from other appropriate regulatory guides, standards, and software engineering literature. IEEE Std. 1074-2006 can be used as a basis for developing specific software life-cycle processes that are consistent with regulatory requirements, as applied to software, for controlling and coordinating the design of safety system software.

Software development processes are intimately related to system development processes. The system design phase allocates system safety requirements to hardware, software, and human elements.

The system integration and testing phases combine and test these elements. Consequently, a standard for software development processes is intimately related to system-level standards, such as IEEE Std. 7-4.3.2-2003, IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations, issued 2003 (Ref. 10), which Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants (Ref. 11), endorsed in January, 2006. IEEE Std. 1074-2006 describes a complete set of software life-cycle processes; however, its system-level view is a generic view from a software perspective. To use IEEE Std. 1074-2006 for developing safety system software, the system-level activities described in IEEE Std. 1074-2006 should be addressed within the context provided by regulation and by nuclear industry standards.

Examples of system-level issues from this context are (1) the need for software safety analyses as part of system safety evaluation and (2) the need for determining the acceptability of preexisting software for use in safety systems. Regulatory Guide 1.152; NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems, issued November 1993 (Ref. 12); and NUREG/CR-6263, High Integrity Software for Nuclear Power Plants: Candidate Guidelines, Technical Basis, and Research Needs, issued June 1995 (Ref. 13), contain general information on software safety activities and software life-cycle activities. The second area, the acceptability of preexisting software, is particularly important in the nuclear context and further guidance can be found in Regulatory Guide 1.152.

The software development process has several supporting regulatory guides to promote high functional reliability and design quality in the software used in safety systems. These guides include the following:

a.

Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,

b.

Regulatory Guide 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants (Ref. 14),

c.

Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants (Ref. 15),

d.

Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants (Ref. 16), and

DG-1210, Page 6

e.

Regulatory Guide 1.172, Software Requirement Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants (Ref. 17).

This regulatory guide is based on standards and describes methods acceptable for any safety system software and discusses the required life cycle activities. The applicant or licensee determines how the required activities will be implemented.

Other Codes and Standards This regulatory guide endorses the use of one or more voluntary consensus codes or standards developed by external organizations. These codes or standards may contain references to other codes or standards. These references should be considered individually. If a referenced standard has been incorporated separately into NRC regulations, licensees and applicants must comply with that standard as set forth in the regulation. If the referenced standard has been endorsed in a regulatory guide, the standard constitutes a method acceptable to the NRC staff for meeting a regulatory requirement as described in the specific regulatory guide. If a referenced standard has been neither incorporated into NRC regulations nor endorsed in a regulatory guide, licensees and applicants may consider and use the information in the referenced standard, if appropriately justified and consistent with current regulatory practice.

Harmonization with International Standards This regulatory guide endorses, in whole or in part, international consensus standards and reports produced by international organizations such as the Institute of Electrical and Electronic Engineers (IEEE).

The IEEE is a non-profit professional association dedicated to advancing technological innovation and excellence. It has more than 400,000 members in more than 160 countries and produces 30 percent of the world's literature in the electrical and electronics engineering and computer science fields including multiple tutorials and standards produced by its standardization committees.

Endorsement, in whole or in part, of international standards reduces the need for the development of unique NRC standards and is consistent with the agency goal of improved harmonization with international organizations.

C. STAFF REGULATORY GUIDANCE IEEE Std. 1074-2006 provides an approach that the NRC staff considers acceptable for meeting the requirements in 10 CFR Part 50 and the guidance in Regulatory Guide 1.152 as they apply to development processes for safety system software with the exceptions and additions listed in these regulatory positions. In this section of the guide, the cited criterion refers to Appendix A or B to 10 CFR Part 50 unless otherwise noted. The NRC staff will consider these exceptions and additions in its review of submittals from applicants and licensees.

1.

Clarifications Because IEEE Std. 1074-2006 was not written specifically for nuclear safety, the following clarifications apply to the standard:

DG-1210, Page 7

a.

Identification of Regulatory Requirements. Criterion III of Appendix B to 10 CFR Part 50 requires, in part, the establishment of measures to ensure that applicable regulatory requirements and the design bases for those structures, systems, and components to which Appendix B applies are correctly translated into specifications, drawings, procedures, and instructions. The descriptions of input information, life-cycle activity, and output information that are required by IEEE Std. 1074-2006 should identify applicable regulatory requirements, design bases, and related guidance.

b.

Consistency. Various statements in IEEE Std. 1074-2006, such as: Section A.1.3.1 Manage Risk imply or state that life-cycle activities should be consistent with cost and schedule or that contingency actions may be taken to meet schedule or cost. All such activities and contingency actions should be consistent with, and justifiable in terms of, Criterion I of Appendix B, which requires that there be sufficient authority and organizational freedom, including sufficient independence from cost and schedule when those actions opposed to safety software quality are considered. The applicant or licensee is not relieved of the responsibility for ensuring reasonable assurance that activities selected can be conducted without endangering public health and safety.

c.

Commercial Software. In reference to all activities under Section A.2.2.3 Allocate System Requirements to IEEE 1074-2006 the Criterion III of Appendix B to 10 CFR Part 50 requires, in part, that measures be established for the selection and review for suitability of the application of materials, parts, equipment, and processes that are essential to the safety-related functions of the structures, systems, and components.

Criterion VII requires, in part, that measures be established to ensure that purchased material, whether purchased directly or through contractors and subcontractors, conforms to the procurement documents. If preexisting software (i.e., reusable software or commercial off-the-shelf software) is incorporated into a safety system developed under the method described by this regulatory guide, an acceptance process should be included at an appropriate point in the life-cycle model to establish the suitability of the preexisting software for its intended use. The acceptance process, its inputs, outputs, activities, preconditions, and postconditions should meet the applicable regulatory requirements and design bases for the safety system. Regulatory Guide 1.152 provides information on the acceptance of preexisting software. Although not specifically endorsed by any particular regulatory guide, additional detailed information on acceptance processes appear in Electric Power Research Institute (EPRI) TR-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications, issued October 1996 (Ref. 18).

d.

Secure Analysis. The NRC takes exception to the IEEE Std. 1074-2006s directions for appropriate security assurance level in Section A.1.1.5 Determine Security Objectives (Required). The planning activity is necessary and the applicant or licensee should refer to the following primary security objectives: (i) secure software development environment, and (ii) cyber security. Guidance for secure software development is available in Regulatory Guide 1.152, whereas guidance for cyber security is available in Regulatory Guide 5.71, Cyber Security Programs for Nuclear Facilities (Ref. 19).

e.

Definitions. The following definitions are used in this regulatory guide:

(1)

Accident. An unplanned event or series of events that result in death, injury, illness, environmental damage, or damage to, or loss of, equipment or property.

DG-1210, Page 8 (2)

Hazard. A condition that is a prerequisite to an accident.

2.

Compliance with IEEE Std. 1074-2006 Criterion II of Appendix B to 10 CFR Part 50 requires all activities affecting quality to be accomplished under suitably controlled conditions. Subclause 1.5, Conformance, of IEEE Std. 1074-2006 permits the elimination of some life-cycle activities, although compliance with the standard may not then be claimed. The NRC Staff position is that compliance with IEEE Std. 1074-2006 means that all mandatory activities are performed; the requirements described as shall are met; and all the inputs, outputs, activities, preconditions, and postconditions mentioned by IEEE Std. 1074-2006 are described or accounted for in the licensees or applicants life-cycle model. IEEE Std. 1074-2006 is an organizing standard that ensures that activities deemed important to software quality are performed and are related properly to one another; it does not provide detailed information on the implementation of specific life-cycle activities.

3.

Software Safety Analyses Criterion III of Appendix B to 10 CFR Part 50 requires, in part, that measures to ensure that applicable regulatory requirements and the design basis are correctly translated into specifications, drawings, procedures, and instructions. To ensure that safety system software development is consistent with the defined system safety analyses, an additional activity group, Software Safety Analysis Activity Group, is necessary. This activity group will include additional activities beyond those specified in IEEE Std. 1074-2006.

Planned and documented software safety analysis activities should be conducted for each phase of the software development life cycle. Therefore, these analyses should be identified in the licensees or applicants life-cycle model, including the following input information, activity descriptions, and output information:

a.

Input Information. Input information necessary to support software safety analyses includes (1) regulatory requirements and guidance, (2) system safety analysis information, (3) information from previous phases for the software safety analysis, (4) design information from previous and current system and software phase activities, and (5) established baseline SDOE objectives.

b.

Activity Description. The analyses should ensure that (1) system safety requirements have been correctly addressed, (2) no new hazards have been introduced, (3) software elements that can affect safety are identified, (4) there is evidence that other software elements do not affect safety, (5) safety problems and resolutions identified in these analyses are documented, (6) there are developed threat model(s) for the safety software product(s), (7) system software architecture(s) are explored for known and potential SDOE vulnerabilities and their impact, and (8) SDOE accreditation is confirmed.

These activities should be conducted according to a software safety plan that addresses the organization to perform the analyses, the responsibilities of its safety officer, the management of the software safety activities, and the analyses to be performed for each phase to address hazards and abnormal conditions and events.

c.

Output Information. The software safety analysis reports the information for the current phase activities. The licensee or applicant should use this information for the design

DG-1210, Page 9 activities of the current life-cycle phase, subsequent software safety analysis activities, the software configuration management process, and the verification and validation processes.

4.

New or Modified Safety System Software Criterion XV of Appendix B to 10 CFR Part 50 requires measures to be established to control materials, parts, or components that do not conform to requirements in an effort to prevent their inadvertent use or installation. The following clarifications should be made to IEEE Std. 1074-2006 with respect to the installation and operation of new or modified safety system software:

a.

Temporary Work-Around. In its overview discussion of the installation process, Section A.4.1 of Annex A to IEEE Std. 1074-2006 states, If a problem arises, it shall be identified and reported. If necessary, and possible, a temporary work-around may be applied. For the purposes of this regulatory guide, the term work-around is defined as a temporary change to either the software or its configuration that is made for the purpose of allowing the continuation of the installation activities and testing of parts of the software that are unaffected by the temporary change. A temporary work-around is not permitted in any safety system unless all software changes are performed in accordance with the software configuration controls and the changed software is checked in an off-line mode prior to installation.

b.

Installation. Installation of new or modified safety system software may be performed only when all functions affected by the software have been declared inoperable in accordance with the plant technical specifications. When software is involved, particularly for distributed software architectures, the determination of affected functions can depend on extremely subtle considerations. For example, two programs related to each other only through the use of a single data item might not be evident from the examination of architecture diagrams. As a minimum, all functions performed, in part, by a given software executable should be declared inoperable if the software executable, its configuration, or its operating platform is to be altered; interconnections of all types with other software, hardware, or human elements should also be examined. A disposition plan, rework procedures that conform to configuration control and verification and validation procedures agreed to under the licensing basis, and a resolution schedule should accompany any work-arounds used during installation (Section A.4.1.2 of IEEE Std. 1074-2006). Before affected functions may be declared operable (Section A.4.1.3 of IEEE Std 1074-2006), the currently approved software, under the control of configuration management, should be installed according to the procedures specified in the installation process. This ensures that the intended software is installed and that any work-arounds employed during the installation activities are removed. An interfacing / interconnected system must also be taken out of service and declared inoperable.

c.

Operation. Section A.4.2.1, Operate the System, of Annex A to IEEE Std. 1074-2006 requires the identification and reporting of anomalies, the conduct of reviews, and the performance of configuration control. Section A.4.3, Maintenance Activity Group, requires the software life cycle to be remapped and executed, thereby treating the Maintenance Activity Group as iterations of development. This process will produce revisions to software executables and configurations that may then be installed according to the installation process. Maintenance activities should conform to the configuration control and verification and validation procedures agreed to under the licensing basis.

DG-1210, Page 10

d.

System Transitions. The discussion in Section A.1.2.3, Plan System Transition, of Annex A to IEEE Std. 1074-2006 states that it is applicable only when an existing system (automated or manual) is being replaced with a new or revised system. However, all changes to safety systems must be evaluated using the criteria specified in 10 CFR 50.59.

If the change is outside the scope of 10 CFR 50.59 then it must be submitted for review as a licensing amendment request.

5.

Tailoring Software Criterion V, Instructions, Procedures, and Drawings, of Appendix B to 10 CFR Part 50 requires, in part, that activities affecting quality be prescribed by, and accomplished in, accordance with documented instructions, procedures, or drawings. Section A.4.1.2 of Annex A to IEEE Std. 1074-2006 permits data customer tailoring in the install software activity. Any tailoring of packaged software or data in the database at installation should be consistent with the packaged installation planned information of IEEE Std. 1074-2006. Criterion III requires, in part, that design changes be subject to design control measures commensurate with those applied to the original design. Tailoring that constitutes design changes, including configurations not part of the original system design, is not permitted unless such tailoring is subject to the full range of design and quality assurance measures applicable to the development of safety system software.

6.

Annexes IEEE Std. 1074-2006 contains the following six annexes (only the first annex is normative).

These annexes are listed here as sources of information; they have not received regulatory endorsement unless otherwise noted:

(1)

Annex A describes the detailed life-cycle activities that should be followed to conform to the standard. The annex provides normative guidance that enables effective application of the standard; therefore, the NRC endorses this annex with clarifications discussed in Part C of this Regulatory Guide.

(2)

Annex B provides a mapping example that demonstrates the mapping process presented in the body of the standard (Clause 4) without constraining the user to any specific methodologies or tools. Although this example provides the licensee with good advice, Annex B is not necessary to conform to the standard; therefore, the NRC does not endorse this annex.

(3)

Annex C gives a mapping template that may be used to assist project managers in identifying project-critical deliverables and in ensuring their completion as needed.

Although this template provides the licensee with good advice, Annex C is not necessary to conform to the standard; therefore, the NRC does not endorse this annex.

(4)

Annex D gives examples of software life-cycle models that the licensee may use to conform to the standard. The NRC does not endorse this annex because it provides examples only and contains no guidance.

(5)

Annex E gives a glossary of terms that are used in the standard. The NRC finds this information useful, but does not endorse this annex without further review.

DG-1210, Page 11 (6)

Annex F gives a bibliography of other standards that IEEE Std. 1074-2006 references.

The paragraph titled Other Codes and Standards, in Section B of this regulatory guide discusses the treatment of these standards.

D. IMPLEMENTATION The purpose of this section is to provide information on how applicants and licensees2 may use this guide and information regarding the NRCs plans for using this regulatory guide. In addition, it describes how the NRC staff complies with the Backfit Rule (10 CFR 50.109) and any applicable finality provisions in 10 CFR Part 52.

Use by Applicants and Licensees Applicants and licensees may voluntarily3 use the guidance in this document to demonstrate compliance with the underlying NRC regulations. Methods or solutions that differ from those described in this regulatory guide may be deemed acceptable if they provide sufficient basis and information for the NRC staff to verify that the proposed alternative demonstrates compliance with the appropriate NRC regulations. Current licensees may continue to use guidance the NRC found acceptable for complying with the identified regulations as long as their current licensing basis remains unchanged.

Licensees may use the information in this regulatory guide for actions which do not require NRC review and approval such as changes to a facility design under 10 CFR 50.59. Licensees may use the information in this regulatory guide or applicable parts to resolve regulatory or inspection issues.

This regulatory guide is not being imposed upon current licensees and may be voluntarily used by existing licensees.

If a licensee believes that the NRC is either using this regulatory guide or requesting or requiring the licensee to implement the methods or processes in this regulatory guide in a manner inconsistent with the discussion in this Implementation section, then the licensee may file a backfit appeal with the NRC in accordance with the guidance in NUREG-1409 and NRC Management Directive 8.4.

Use by NRC Staff During regulatory discussions on plant specific operational issues, the staff may discuss with licensees various actions consistent with staff positions in this regulatory guide, as one acceptable means of meeting the underlying NRC regulatory requirement. Such discussions would not ordinarily be considered backfitting even if prior versions of this regulatory guide are part of the licensing basis of the facility. However, unless this regulatory guide is part of the licensing basis for a facility, the staff may not represent to the licensee that the licensees failure to comply with the positions in this regulatory guide constitutes a violation.

If an existing licensee voluntarily seeks a license amendment or change and (1) the NRC staffs consideration of the request involves a regulatory issue directly relevant to this new or revised regulatory 2

In this section, licensees refers to licensees of nuclear power plants under 10 CFR Parts 50 and 52; and the term applicants, refers to applicants for licenses and permits for (or relating to) nuclear power plants under 10 CFR Parts 50 and 52, and applicants for standard design approvals and standard design certifications under 10 CFR Part 52.

3 In this section, voluntary and voluntarily means that the licensee is seeking the action of its own accord, without the force of a legally binding requirement or an NRC representation of further licensing or enforcement action.

DG-1210, Page 12 guide and (2) the specific subject matter of this regulatory guide is an essential consideration in the staffs determination of the acceptability of the licensees request, then the staff may request that the licensee either follow the guidance in this regulatory guide or provide an equivalent alternative process that demonstrates compliance with the underlying NRC regulatory requirements. This is not considered backfitting as defined in 10 CFR 50.109(a)(1) or a violation of any of the issue finality provisions in 10 CFR Part 52.

The NRC staff does not intend or approve any imposition or backfitting of the guidance in this regulatory guide. The NRC staff does not expect any existing licensee to use or commit to using the guidance in this regulatory guide, unless the licensee makes a change to its licensing basis. The NRC staff does not expect or plan to request licensees to voluntarily adopt this regulatory guide to resolve a generic regulatory issue. The NRC staff does not expect or plan to initiate NRC regulatory action which would require the use of this regulatory guide. Examples of such unplanned NRC regulatory actions include issuance of an order requiring the use of the regulatory guide, requests for information under 10 CFR 50.54(f) as to whether a licensee intends to commit to use of this regulatory guide, generic communication, or promulgation of a rule requiring the use of this regulatory guide without further backfit consideration.

Additionally, an existing applicant may be required to adhere to new rules, orders, or guidance if 10 CFR 50.109(a)(3) applies.

DG-1210, Page 13 REFERENCES4

1.

Code of Federal Regulations (CFR), Title 10, Energy, Part 50, Domestic Licensing of Production and Utilization Facilities.

2.

Institute of Electrical and Electronic Engineers (IEEE), Std. 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear Power Generation Stations, IEEE, Piscataway, NJ, 1991 (including a correction sheet dated January 30, 1995).5

3.

IEEE Std. 279-1971, Criteria for Protection Systems for Nuclear Power Generating Stations, IEEE, Piscataway, NJ, 1971.

4.

IEEE Std. 1074-2006, IEEE Standard for Developing a Software Project Life Cycle Process, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 2006.

5.

U.S. Nuclear Regulatory Commission (NRC), NUREG-0800, Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants: LWR Edition, Chapter 7, Instrumentation and Controls, NRC, Washington, DC, March 2007.

(http://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr0800/ch7/)

6.

CFR, Title 10, Energy, Part 52, Licenses, Certifications, and Approvals for Nuclear Power Plants.

7.

CFR, Title 10, Energy, Part 73, Protection of Digital Computer and Communication Systems and Networks.

8.

NRC, Regulatory Guide 1.28, Quality Assurance Program Criteria, NRC, Washington, D.C.

9.

NRC, Regulatory Guide 1.168, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

10.

IEEE Std. 7-4.3.2-2003, IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations, IEEE, Piscataway, NJ, 2003.

11.

NRC, Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

12.

NRC, NUREG/CR-6101, Software Reliability and Safety in Nuclear Reactor Protection Systems, NRC, Washington, DC, November 1993. (ADAMS Accession No. ML072750055) 4 Publicly available NRC published documents are available electronically through the Electronic Reading Room on the NRCs public Web site at http://www.nrc.gov/reading-rm/doc-collections/. The documents can also be viewed online or printed for a fee in the NRCs Public Document Room (PDR) at 11555 Rockville Pike, Rockville, MD; the mailing address is USNRC PDR, Washington, DC 20555; telephone 301-415-4737 or 800-397-4209; fax 301-415-3548; and e-mail pdr.resource@nrc.gov.

5 Copies of IEEE documents may be purchased from the Institute of Electrical and Electronics Engineers Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855 or through the IEEEs public Web site at http://www.ieee.org/publications_standards/index.html.

DG-1210, Page 14

13.

NRC, NUREG/CR-6263, High Integrity Software for Nuclear Power Plants: Candidate Guidelines, Technical Basis, and Research Needs, NRC, Washington, DC, June 1995. (ADAMS Accession No. ML063470590, ML063470593, and ML063600344)

14.

NRC, Regulatory Guide 1.169, Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

15.

NRC, Regulatory Guide 1.170, Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

16.

NRC, Regulatory Guide 1.171, Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

17.

NRC, Regulatory Guide 1.172, Software Requirement Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, NRC, Washington, DC.

18.

Electric Power Research Institute (EPRI) Topical Report TR-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications, EPRI, Palo Alto, CA, October 1996.6

19.

NRC, Regulatory Guide 5.71, Cyber Security Programs for Nuclear Facilities, NRC, Washington, DC.

6 Copies of EPRI documents may be obtained from the Electric Power Research Institute, 3420 Hillview Avenue, Palo Alto, CA 94304, telephone 650-855-2000 or online at http://my.epri.com/portal/server.pt.