ML17268A331

D.4 Software Development Processes (First Draft) R2 - Clean R1

ML17268A331
Person / Time
Issue date:	09/21/2017
From:	Lynnea Wilkins Licensing Processes Branch (DPR)
To:
Wilkins L, NRR/DPR, 415-1377
Shared Package
ML17268A331	List: ML17268A331
References
Download: ML17268A331 (10)

Text

D.4 Software Development Processes The licensee should provide information to confirm that I&C safety system equipment will be designed, fabricated, erected, and tested to quality standards commensurate with the importance of the safety functions to be performed.

Applicable Requirements

1. 10 CFR 50.55a(h) requires compliance with IEEE Std 603-1991, including the correction sheet dated January 30, 1995, which is referenced in 10 CFR 50.55a(h)(2) and (3). This standard includes Section 5.3, Quality.

2. 10 CFR Part 50, Appendix A, GDC 1, Quality Standards and Records

3. 10 CFR Part 50, Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants Additional Review Criteria

1. Digital I&C safety systems should conform to the current version of the licensees approved Quality Assurance Program.

2. RG 1.152, Revision 3, endorses IEEE Std 7-4.3.2-2003, with identified exceptions and clarifications.

I&C Safety-System Development Processes The reviewer will confirm that the license amendment request discusses the framework that will be used to design and develop I&C safety systems. This framework should supplement the licensees overall QA program descriptions with specific system, hardware, and software development activities, including a description of the proposed development life cycles and management activities that will be implemented in the design and development of I&C safety systems.

The activities during the system life-cycle phasesdevelopment process are summarized as follows:

• Create the concepts on which the system design will be based.

• Translate these concepts into system requirements.

• Allocate system requirements to system elements (e.g., software, hardware, and humans).

• Implement the design into hardware and software functions.

• Integrate system elements such as software and hardware.

• Test unit functions and completed system to confirm that system requirements have been correctly implemented.

• Throughout the development processFor all phases, perform appropriate Human Factors Engineering for the human-system interface

• Throughout the development processFor all phases, analyze hazards and incorporate hazards into requirements.

• Throughout the development processFor all phases, review work products.

• Install the system such that it is ready to operate in the plant.

[ Since the software development may be performed by a vendor and not by the licensee; therefore, the interface between the licensee and vendor, and the method by which the quality of the vendor effort should be evaluated by the licensee is critical. Need to add discussion of review licensee oversight of the vendor software development program plans for implementation. The licensee should describe the interactions, standards, checks, and documentation associated with the oversight plan. ]

Using the acceptance criteria contained below, the reviewer will evaluate whether the proposed framework described in the license amendment request is adequate to deliver a high-quality I&C safety system. The licensee should identify which of the development activities are addressed as part of the development process defined for an NRC-approved digital I&C platform and those activities that are part of the application-specific software development process. The development activities that are part of the development process defined for NRC-approved digital I&C platform activities should not be re-evaluated; instead, the review should focus on the application-specific software development activities. If the licensee is using an NRC-approved development process for application development (e.g., software program manual), then this process should not be re-reviewed for the LAR.

1. System and Software Development Activities To confirm that a licensee has described measures that satisfy the requirements of Criterion III of 10 CFR Part 50 Appendix B, the reviewer will confirm that the license amendment request provides a description of input information, life-cycle activities, and output information necessary to develop I&C safety systems, in accordance with applicable regulatory guidance and the design bases, along with a description of the use of industry standards, including international standards.

The development of I&C safety systems should progress according to a defined life cycle, which is part of the overall system framework. Although the staff has not recommended a particular life-cycle model, the reviewer will confirm that the license amendment request (LAR) contains a description of life-cycle activities and tasks, including inputs and outputs that will be implemented in the development of the proposed I&C safety system. The LAR should also describe the analysis, review, and test activities that will be implemented. The licensee may choose among many different life-cycle models for system, hardware, software, and human factors engineering development. Generally, these models differ in the timing of the various activities and tasks used to produce a high-quality product, but such activities and tasks must be undertaken.

The reviewer will confirm that the licensee has described a life-cycle model that includes processes appropriately tailored and relevant to its particular development project and digital technology to implement the activities listed below.

A sample of software development documents that are available for audit during the license amendment request review should be reviewed to confirm that that the life cycle activities are being effectively implemented. The development documentation expected to be available during the NRC review of the LAR should be discussed during a Phase 0 meeting, using the framework in Enclosure B.

A. Plant Safety Analyses and I&C System and Software Safety Analyses

i. To meet Clause 4 of IEEE Std 603-1991, this information should be consistent with the plant safety analysis provided in the plants final safety analysis report. Changes to the

plant safety analysis associated with the I&C system modification should be described in the LAR and demonstrate acceptability to the changes to the plant design basis.

ii. As part of the software safety analyses, the license amendment request should define a software integrity level (SIL) scheme to quantify software criticality, as defined in the endorsed IEEE Std 1012-2004. A criticality analysis should be performed to determine the SIL of the software necessary to accomplish each safety function. Software that implement auxiliary features or self-diagnostics Ffunctions that may be of a lower safety classification SILs that support a system safety function should have a SIL consistent be reclassified towith the highest SIL assigned for the hardware module where the software is installednecessary for that function.

B. I&C System Requirements

i. I&C system requirements should be developed that describe the identification, development, documentation, review, approval, and maintenance of I&C system requirements. It should include the elements described in Section D.2.

ii. The I&C system requirements should include, at a minimum, the need for system and software safety analyses throughout the life cycle; functions and capabilities of the I&C system during operations; system boundaries; safety classification; safety functional properties and additional features not performing a safety function; customer-requested features; interfaces (e.g., safety, non-safety, security, and human-system); operations and maintenance measures, including intended fault identification, testing, calibration, and repair; design constraints; qualification requirements; hazards analysis (HA) results; and restrictions and constraints placed on the system to ensure compatibility with other plant systems.

iii. All identified system requirements should be analyzed, reviewed, approved, baselined, updated as necessary, and placed under configuration management (CM).

iv. A means for requirements traceability should be developed, documented, tracked, and maintained. The requirements traceability documentation should provide bidirectional traceability (from requirements to system validation testing) for all system requirements.

v. The completed I&C system requirements should be used as input to the ongoing I&C system design activity.

C. I&C System Architecture

i. An I&C system architecture should be developed, based on a defined methodology that provides all necessary I&C functions needed to ensure safe plant operation. It should include the elements described in Section D.2.

ii. The I&C system architecture should be documented, baselined, updated as necessary, and placed under CM.

iii. The completed I&C system architecture should be used as input to the ongoing I&C system design activity.

D. I&C System Design

i. A detailed design of the I&C system that conforms to the I&C system design basis should be developed and recorded in an I&C system design description, based on the architectural design. It should include the elements described in Section D.2.

ii. The I&C system design should be described and identify, at a minimum, system elements such as allocation of functions to hardware, software, human-system interfaces; automatic and manual functions; interrelationship between components; and interface design.

iii. The I&C system design should demonstrate traceability of the system requirements to the design.

iv. I&C system safety analyses should be reviewed to identify hardware, software, or human-system interfaces that have the potential to cause a hazard or is credited to eliminate or mitigate and thus control hazards.

v. The I&C system design should be analyzed, reviewed, approved, baselined, updated as necessary, and placed under CM.

vi. Bidirectional traceability should be established among the I&C system design description, the I&C system architecture, and the I&C system requirements.

vii. The completed I&C system design should be used as input to the ongoing I&C system design activity.

E. Software Requirements

i. Software requirements should be developed to document the functions to be performed by the software.

ii. The software requirements should be analyzed, reviewed, approved, baselined, updated as necessary, and placed under CM. Software requirements should be baselined before initiating software design.

iii. The software requirements should be derived from and traceable to the system design, I&C system architecture, and system requirements.

iv. The independent verification and validation (V&V) team should develop the System V&V test plans.

v. The completed software requirements should be used as input to the ongoing I&C system design activity.

F. Software Design

i. The software design decomposes the software requirements to document the design and implementation of software components, modules, and units used to implement the I&C system. A software unit is the highest element in the software hierarchy. Software units are comprised hierarchically of software components and software modules. Commented [MB1]: IEEE 1008 uses units made of modules.

IEEE 1012 speaks of components and modules. IEEE 1012 has a NOTE 1The terms module, component, and unit are often ii The software design should be developed and define the detailed design for each used interchangeably or defined to be subelements of one another software element of the system and how the software components, modules, and units in different ways depending upon the context. The relationship of are to be constructed. these terms is not yet standardized.

iii. The software design should document, at a minimum, the methods by which software components, modules, and units will be refined into lower levels, including software modules to allow coding, compiling, and testing; and the division of the software into a set of interacting components, modules, and units, including the description of those components, modules, and units their interfaces, and dependencies, in a structured fashion.

iv. The software design and implementation should incorporate applicable software requirements from the previous phase.

v. Relationship between component(s), and software module(s), and software unit(s) should be established.

vi. The software design should demonstrate adequate coverage of all software requirements and should not contain any unnecessary functions. For predeveloped digital platforms, preexisting software (e.g., operating system software) may contain features that are not used (or not configured for use) in a specific I&C system. In those instances, unless otherwise demonstrated as part of the platform qualification, the licensee should identify those unused capabilities, evaluate whether those functions may affect performance of the safety function, and identify any compensatory measures taken.

vii. The documented acceptance and use of support software and tools (e.g., code generating tools, compilers, assemblers, operating systems, coverage analyzers, automated test tools, traceability tools, simulators, and emulators) should be consistent with the guidance in IEEE Std 7-4.3.2-2003, as endorsed in RG 1.152, Revision 3.

viii. Code change requests and modifications should be documented and controlled.

ix. The software design should be analyzed, reviewed, approved, baselined, updated as necessary, and placed under CM.

x. The independent verification and validation (V&V) team should develop the System V&V test designs.

xi. The completed software design should be used as input to the ongoing I&C system design activity.

G. Software Implementation

i. The software implementation process should define the criteria for testing each software components, modules, and unit and the test procedures and data for testing each software components, modules, and unit.

ii. The software implementation process should describe the translation of the detailed design into code in the selected programming language.

iii. The code should be capable of executing the safety design features and methods developed during the software design process.

iv. The use of documented coding rules, guidelines, methods, standards, and other applicable criteria should be defined and enforced. The coding rules and standards

should facilitate understanding, analysis, review, testing, and readability of the implemented code.

v. The code should be designed to facilitate understanding, analysis, review, testing, and readability.

vi. The correct implementation of software requirements in each software module and in each software component, module, and unit should be verified to ensure accuracy and conformance with design requirements.

vii. Software unit (or component) testing should be performed as software is developed to ensure it satisfies design requirements. The primary testing methods and standards, test cases used, test coverage, and test results should be documented, controlled, and maintained.

viii. Test documentation structure should be defined.

ix. The software implementation activities should be traceable to the software design, I&C system architecture, and system requirements.

xi. The independent verification and validation (V&V) team should develop the System V&V test procedures xii. The completed software implementation should be used as input to the ongoing I&C system design activity.

H. Software Integration

i. A software integration process should be developed to describe the methods for integrating software components and modules into software units. Aggregates of components and modules tested during implementation should be integrated into a software unit, in accordance with the integration process.

ii. Critical elements of software integration should include, but are not limited to identifying software components, modules, and units for integration; defining and implementing the integration environment; managing interfaces; and identifying item integration sequences.

iii. As-coded software items should reflect the design documentation.

iv. Software component (or unit) testing should be conducted to verify that software requirements have been adequately implemented for this phase stage of the software life cycledevelopment.

v. The software integration results should be documented, analyzed, reviewed, approved, updated as necessary, and placed under CM.

vi. The software integration results should be derived from and traceable to the software design, I&C system architecture, and I&C system requirements.

vii. The completed software integration should be used as input to the ongoing I&C system design activity.

I. I&C System Testing

i. A system test plan should document the integration and testing of all software items, hardware, manual processes, and other system interfaces that constitute the I&C system, consistent with the architectural design.

ii. System testing should consider all of the integrated software components, modules, and units that have successfully passed integration testing, as well as the software system itself, integrated with any applicable hardware systems.

iii. System testing should be conducted on a complete, integrated system to evaluate the systems performance of the I&C system requirements.

iv. The test plan should include tasks to integrate and test all software and hardware items, to prepare the test environment, to write test cases (inputs, outputs, and test criteria),

and to test interfaces to other systems.

v. System test results should be documented. Test results should be analyzed to verify that all I&C system requirements have been satisfied.

vi. Testing should demonstrate that hazards have been eliminated or controlled to an acceptable level of risk.

vii. Test discrepancies should be evaluated and resolved. Provisions should be available for appropriate regression testing following changes made to address discrepancies.

viii. The completed system test results should be used as input to the ongoing I&C system design activity.

J. I&C System Installation

i. A system installation plan should be developed that documents the methods by which the I&C safety system will be installed and connected to other plant systems.

ii. The system installation plan should describe, at a minimum, procedures for software installation, combined hardware/software installation, and systems installation; checks to ensure that the computer system is functional, that sensors and actuators are functional, that all cards are present and installed in the correct slots (when applicable), and that the communication system is correctly installed; and measures to confirm that the correct software versions (i.e., consistent with the versions used for final system testing) are installed on the correct I&C system.

iii. Acceptance testing should demonstrate that the installed system will perform the required safety function described in the systems design basis.

iv. Anomalies discovered during installation should be reported to the developer and resolved before placing the system into operation.

v. Software modifications during installation should be controlled.

vi. The completed system installation results should be documented.

2. Project Management Processes

The license amendment request should provide a description of the project management or organizational processes that will be employed by the QA program and used to define the projects organization, planning, execution, monitoring, control, and closure activities of the entire I&C safety system development effort.

The reviewer will confirm that the license amendment request describes the organizational and project management processes that address, at a minimum, the following:

A. Measures for the creation and implementation of plans to control the system development environment, including hardware, software, and human factors engineering in accordance with 10 CFR Part 50 Appendix B Criterion V, with the planning process resulting in a set of documents that will be used to control and oversee the development of system elements, including hardware and software B. Controls for identifying the project scope, determination of deliverables, lines of communication, formal and informal reviews, and interfaces with other internal and external organizations C. Provisions for the establishment, documentation, and maintenance of a schedule that considers the overall project, as well as interactions of milestones D. Provisions for risk management, including problem identification, impact assessment, and development of risk-mitigation plans for risks that have the potential to significantly affect system quality goals, with appropriate metrics for tracking resolution progress, with additional guidance on software-related project risk activities in Section 5.3.6 of IEEE Std 7-4.3.2-2003 E. Establishment of quality metrics throughout the life cycle to assess whether the quality requirements of IEEE Std 603-1991 are being met, with additional guidance in Section 5.3 of IEEE Std 7-4.3.2-2003 F. Adequate control of software tools to support system development and software verification and validation (V&V) processes, with additional guidance in Section 5.3.2 of IEEE Std 7 4.3.2-2003 G. Provisions for the documentation and resolution of problems and nonconformances found in the system elements H. Provisions for effective oversight of all life-cycle-related activities

3. Software Quality Assurance Processes RG 1.152, Revision 3, indicates, in part, that conformance with the recommendations of IEEE Std 7-4.3.2-2003 is a method acceptable for providing high functional reliability and fulfilling design requirements for digital I&C used in the safety systems of nuclear power plants (sEE IEEE Std 7-4.3.2-2003, Section 5.3.1).

The license amendment request should describe measures to satisfy the applicable requirements of Appendix B to 10 CFR Part 50 with respect to software QA. In particular, the license amendment request should describe how the elements of the software QA plan will be implemented throughout the system, software, hardware, and human factors engineering development life cycle.

4. Software Verification and Validation Processes RG 1.152, Revision 3, endorses IEEE Std 7-4.3.2-2003, subject to the positions and modifications identified in the RG. Sections 5.3.3 and 5.3.4 of IEEE Std 7-4.3.2-2003 provide guidance on V&V activities and independent V&V, respectively.

RG 1.168, Revision 2, endorses IEEE Std 1012-2004 and IEEE Std 1028-2008, with the exceptions stated in the regulatory positions. The licensee should demonstrate it meets the intent of RG 1.168. It is acceptable for a licensee to adapt V&V programs activities and tasks to reflect important process differences, technology differences, and exceptions related to the use of integrated design environment tools. Security vulnerability assessments performed for RG 1.152, Revision 3, should replace security analyses described in IEEE Std 1012-2004 Section 5 and Tables 1 and 2.

It is important to note that IEEE Std 1028-2008 describes requirements for systematic software reviews; however, it does not establish the need to conduct specific reviews. The licensee is not expected to demonstrate compliance to IEEE Std 1028-2008, but should define which reviews in the software development process are systematic software reviews.

The V&V process defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A V&V process, used for the application-specific software that is NRC-approved (e.g., software program manual) should not be reevaluated.

5. Software Configuration Management Processes RG 1.152, Revision 3, endorses IEEE Std 7-4.3.2-2003, subject to the positions and modifications identified in the RG. IEEE Std 7-4.3.2-2003, Section 5.3.5, provides criteria for software CM.

RG 1.169, Revision 1, endorses IEEE Std 828-2005 as an acceptable method for meeting NRC regulation (10 CFR Part 50 Appendix A GDC 1 and Appendix B), subject to the positions and modifications identified in the RG, as they apply to the maintenance and control of appropriate records of software development activities. The licensee should demonstrate it meets the intent of RG 1.169.

The software CM process defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A CM process, used for the application-specific software that is NRC-approved (e.g.,

software program manual) should not be reevaluated.

6. Other Software Development Process Guidance The licensee should describe the use of the software development process guidance listed below or the use of alternative industry standards (e.g., International Electrotechnical Commission standards). The licensee should describe how the development process activities meet the intent of NRC guidance. A complete mapping of literal compliance with each clause in the software standards is not required.

RG 1.173, Revision 1, endorses IEEE Std 1074-2006 as an acceptable method for meeting NRC regulation for software development processes), subject to the positions and modifications identified in the RG. The licensee should demonstrate it meets the intent of RG 1.173. The

software development process defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A software development process, used for the application-specific software that is NRC-approved (e.g., software program manual) should not be reevaluated.

RG 1.172, Revision 1, endorses IEEE Std 830-1998 as an acceptable method for meeting NRC regulation for developing a software requirements specification, subject to the positions and modifications identified in the RG. The licensee should demonstrate it meets the intent of RG 1.172. Ranking requirements for importance or stability for safety systems are not necessary, since unnecessary requirements should not be imposed in safety systems. The software requirements development process defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A software requirements development process, used for the application-specific software that is NRC-approved (e.g., software program manual) should not be reevaluated.

RG 1.171, Revision 1, endorses IEEE Std 1008-1987 as an acceptable method for meeting NRC regulation for unit testing, subject to the positions and modifications identified in the RG as an acceptable method for meeting NRC regulation for unit testing. The licensee should demonstrate it meets the intent of RG 1.171. The software testing defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A software testing process, used for the application-specific software that is NRC-approved (e.g., software program manual) should not be reevaluated.

RG 1.170, Revision 1, endorses IEEE Std 829-2008 as an acceptable method for meeting NRC regulation for test documentation, subject to the positions and modifications identified in the RG as an acceptable method for meeting NRC regulation for test documentation. The licensee should demonstrate it meets the intent of RG 1.170. It is acceptable for a licensee to adapt test documentation to reflect important process differences, technology differences, exceptions related to the use of integrated design environment tools. IEEE Std 829 allows test documents to be combined or eliminated. The software test documentation defined for an NRC-approved digital I&C platform should not be re-evaluated; instead, the review should focus on the application-specific software development activities. A test documentation process, used for the application-specific software that is NRC-approved (e.g., software program manual) should not be reevaluated.

Implementation The staff has accepted the content of this section of the ISG as an alternative method for evaluating software development for safety systems to ensure compliance with the NRCs regulations for promoting high functional reliability and design quality in software used in safety systems.