SOFTWARE PROGRAM MANUAL FOR TELEPERM XS SAFETY … · This safety evaluation (SE) documents the staff’s review of the AREVA NP Software Program Manual for TELEPERM XS Safety Systems

ENCLOSURE 1

SAFETY EVALUATION BY THE OFFICE OF NEW REACTORS AND

THE OFFICE OF NUCLEAR REACTOR REGULATION

AREVA NP TOPICAL REPORT ANP-10272

SOFTWARE PROGRAM MANUAL FOR TELEPERM XS™ SAFETY SYSTEMS

1.0 INTRODUCTION By letter dated December 21, 2006, Nuclear Regulatory Commission (NRC) Agencywide Document Access and Management System (ADAMS) Accession No. ML063610098, AREVA NP submitted Topical Report ANP-10272, Revision 0, (ADAMS Accession No. ML063610100), “Software Program Manual for TELEPERM XS Safety Systems Topical Report,” to the NRC for review. As a result of numerous requests for information and response submittals by the applicant as well as discussions, meetings and basis information audits, in support of the Safety evaluation development, AREVA NP submitted a revised draft Revision 1 of the Software Program Manual (ADAMS Accession No. ML091950258) on April 7, 2009, Revision 2 (ADAMS Accession No. ML101390467) on May 7, 2010, and Revision 3 (ADAMS Accession No. ML103000076) on October 22, 2010. AREVA NP requested that NRC issue a safety evaluation report which approves the use of the Software Program Manual (SPM) to support digital safety instrumentation and control (I&C) system upgrades at operating nuclear power plants and digital safety systems for new nuclear power plants. The SPM is a high-level planning document setting forth the guidelines, restrictions, requirements, program measures, and framework for developing software lifecycle plans intended for the development of TELEPERM XS (TXS) project-specific application software. The SPM is to be used in conjunction with the NRC-approved TELEPERM XS system as described in Siemens Topical Report EMF-2110(NP)(A), “TELEPERM XS: A Digital Reactor Protection System,” Revision 1 (ADAMS Accession No. ML003732662). This safety evaluation (SE) documents the staff’s review of the AREVA NP Software Program Manual for TELEPERM XS Safety Systems Topical Report, Revision 3. The SPM specifies plans for implementing a structured software life cycle process for application software development. Since the application software has not been submitted for review or inspection, and the application software is different in each project-specific application, the staff’s evaluation does not include the review of the outputs of the life cycle process. The evaluation is limited to the planning phases of a software life cycle. Likewise, the staff’s evaluation does not include the review of the project-specific instances of the plans identified in the topical report, but does consider AREVA NP’s concept and commitment for development of those plans. The staff understands that the plans outlined in this SPM will be put into effect via implementing procedures which will incorporate generic and project-specific planning activities. These implementing procedures are to be made available to the NRC so conformance to the SPM can be verified. This confirmatory review may be performed as an audit or as an inspection activity.

- 2 -

Software plans developed on a project-specific basis, in compliance with the conditions set forth in the SPM, and satisfying the Application Specific Action Item (ASAI) will be considered by the NRC to have been developed in a high-quality manner consistent with a level of safety commensurate with the importance of the safety functions accomplished as described herein. When using the TELEPERM XS platform for plant-specific safety applications, applicants may use the SPM for developing and implementing the application software. Any exception taken from the SPM, or this safety evaluation, shall be identified in any application or topical report referencing the SPM. Such exceptions shall be subject to review by the NRC. Because this topical report and the TXS topical report are generic, licensees and combined license (COL) applicants must describe in detail how they propose to use the TXS design and application software in plant-specific applications and must address all ASAIs listed in Section 4.0 of this evaluation. SPM Appendix C provides a description of the secure development and operational environment design features and controls that govern the development of both the TXS system software and the TXS application software. SPM Appendix C also addresses the measures established to ensure the integrity and reliability of the TXS system and application software from the Concepts Phase through the Retirement Phase to protect against non-malicious events in accordance with the guidance provided by NRC Regulatory Guide (RG) 1.152, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants,” Revision 2. The SPM Appendix C is addressed in this safety evaluation’s Appendix A. This report has been reviewed for, and is applicable to, applications for new reactors and license amendment requests for operating reactors involving the use of the TXS platform for digital safety systems. 2.0 REGULATORY EVALUATION 2.1 Regulatory Criteria The following regulatory requirements are applicable to the review of the Software Program Manual. • 10 CFR 50.55a(a)(1) requires, in part, that systems and components be designed,

tested, and inspected to quality standards commensurate with the safety function to be performed.

• 10 CFR 50.55a(h), “Protection and Safety Systems,” requires compliance with Institute of Electrical and Electronics Engineers (IEEE) Standard (Std) 603-1991, “IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations,” and the correction dated January 30, 1995.

o Clause 5.6.3 of IEEE Std 603-1991 requires safety system to be designed such that credible failures in and consequential actions by other systems will not prevent safety systems from performing their intended safety functions.

- 3 -

o Clause 5.9 of IEEE Std 603-1991 requires the design to permit the administrative control of access to safety system equipment. These administrative controls shall be supported by provisions within the safety systems, by provision in the generating station design, or by a combination thereof.

• 10 CFR Part 50, Appendix A, General Design Criteria (GDC) 1,”Quality Standards and Records,” requires, in part, that systems and components important to safety be designed, fabricated, erected, and tested to quality standards commensurate with the importance of the safety functions to be performed.

• 10 CFR Part 50, Appendix A, GDC 21 requires, in part, that protection systems must be designed for high functional reliability commensurate with the safety functions to be performed.

• 10 CFR Part 50, Appendix B, Criterion III, “Design Control,” requires, in part, that for safety-related Systems, Structures or components (SSCs), quality standards be specified and that design control measures shall provide for verifying or checking the adequacy of design.

• 10 CFR Part 50, Appendix B, Criterion V, “Instructions, Procedures, and Drawings,” requires, in part, that for safety-related SSCs, activities affecting quality shall be prescribed by documented…procedures…of a type appropriate to the circumstances….

• 10 CFR Part 50, Appendix B, Criterion VI, “Document Control,” requires, in part, that for safety-related SSCs, measures shall be established to control the issuance of documents which prescribe all activities affecting quality.

• 10 CFR Part 50, Appendix B, Criterion VII requires documented control of purchased material, equipment, and services for safety-related SSCs.

• 10 CFR Part 50, Appendix B, Criterion XI, “Test Control,” requires, in part, that a test program be established to demonstrate that safety-related systems and components will perform satisfactorily in service.

The following guidance documents are applicable to, and were utilized in support of, the review of the Software Program Manual. Regulatory Guides • RG 1.152, “Criteria for Use of Computers in Safety Systems of Nuclear Power Plants,”

Revision 2, November 2003.

• RG 1.168, “Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,” Revision 1, February 2004.

• RG 1.169, “Configuration Management Plans for Digital Computer Software Used in

Safety Systems of Nuclear Power Plants,” September 1997.

- 4 -

• RG 1.170, “Software Test Documentation for Digital Computer Software Used in Safety

Systems of Nuclear Power Plants,” September 1997. • RG 1.171, “Software Unit Testing for Digital Computer Software Used in Safety Systems

of Nuclear Power Plants,” September 1997. • RG 1.172, Software Requirements Specifications for Digital Computer Software Used in

Safety Systems of Nuclear Power Plants,” September 1997. • RG 1.173, “Developing Software Life Cycle Processes for Digital Computer Software

Used in Safety Systems of Nuclear Power Plants,” September 1997. Branch Technical Position • Branch Technical Position (BTP) 7-14, “Guidance on Software Reviews for Digital

Computer-Based Instrumentation and Control Systems.” Industry Standards • IEEE Std 7-4.3.2-2003, “Application Criteria for Programmable Digital Computer

Systems in Safety Systems of Nuclear Power Generating Stations,” as endorsed by RG 1.152.

• IEEE Std 730-2002, "Software Quality Assurance Plans," as referenced in BTP 7-14. • IEEE Std 828-1990, "Software Configuration Management Plans," as endorsed by

RG 1.169. • IEEE Std 829-1983, "Software Test Documentation," as endorsed by RG 1.170,

"Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants."

• IEEE Std 830-1993, "Guide for Software Requirements Specifications," as endorsed by

RG 1.172. • IEEE Std 1012-1998, "IEEE Standard for Software Verification and Validation Plans," as

endorsed by RG 1.168, Revision 1. • IEEE Std 1028-1997, "IEEE Standard for Software Reviews and Audits," as endorsed by

RG 1.168, Revision 1. • IEEE Std 1042-1987, "IEEE Guide to Software Management," as endorsed by

RG 1.169.

- 5 -

• IEEE Std 1074-1995, "IEEE Std. for Developing Software Life Cycle Processes," as endorsed by RG 1.173.

2.2 Method of Review The staff used the guidance in Regulatory Guides and BTP 7-14 to review the software life cycle plans in the Software Program Manual. 2.3 PRECEDENTS The NRC approved a License Amendment Request for replacement of an analog Reactor Protection System and Engineered Safeguard Protective System with a digital computer-based TXS system at Oconee Units 1, 2, and 3. Part of that safety evaluation included the review of AREVA NP operating instructions and plant-specific artifacts that comprise a software program manual. Previously approved equipment and processes, where applicable, are referenced in this safety evaluation. 3.0 TECHNICAL EVALUATION 10 CFR Part 50.55a(a)(1) requires, in part, that systems and components be designed, tested, and inspected to quality standards commensurate with the safety function to be performed. 10 CFR Part 50, Appendix A, "General Design Criteria for Nuclear Power Plants," Criterion 1, "Quality Standards and Records," requires, in part, that a quality assurance program be established and implemented in order to provide adequate assurance that systems and components important to safety will satisfactorily perform their safety functions. 10 CFR Part 50, Appendix B, "Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants," describes criteria that a quality assurance program for systems and components that prevent or mitigate the consequences of postulated accidents must meet. In particular, besides the systems and components that directly prevent or mitigate the consequences of postulated accidents, the criteria of Appendix B also apply to all activities affecting the safety-related functions of such systems and components as designing, purchasing, installing, testing, operating, maintaining, or modifying. In 10 CFR Part 50, Appendix B, many of the criteria contain requirements closely related to software life cycle activities. Criterion I, "Organization," describes the establishment and execution of a quality assurance program. Criterion II, "Quality Assurance Program," states, in part, that activities affecting quality must be accomplished under suitably controlled conditions, which include assurance that all prerequisites for a given activity have been satisfied. This criterion also calls for taking into account the need for special controls and processes to attain the required quality. Criterion III, "Design Control," states, in part, that measures must be established for the identification and control of design interfaces and for coordination among participating design organizations. Criterion XV, "Nonconforming Materials, Parts, or Components," requires measures to be established to control materials, parts, or components that do not conform to requirements in order to prevent their inadvertent use or installation. Finally, Criteria VI, "Document Control," and XVII, "Quality Assurance Records," provide for the control of the issuance of documents, including changes thereto, that prescribe

- 6 -

all activities affecting quality and provide for the maintenance of sufficient records to furnish evidence of activities affecting quality. NUREG-0800, Standard Review Plan (SRP), BTP 7-14, “Guidance on the Software Reviews for Digital Computer-Based Instrumentation and Control Systems,” provides an acceptable way to meet the regulations cited. The staff reviewed the Software Program Manual in accordance with BTP 7-14. Acceptability of software for safety system functions is dependent upon (1) confirmation that acceptable plans were prepared to control software development activities as described in BTP 7-14, B.3.1, (2) evidence that the plans were followed in an acceptable software life cycle as described in BTP 7-14, B.3.2, and (3) evidence that the process produced acceptable design outputs as described in BTP 7-14, B.3.3. The SPM only addresses the first item, the planning phase. This SE instructs applicants referencing Topical Report NAP-10272 to make available specified information. The meaning of the term “make available,” however, depends on the type application referencing the topical report, as follows: A licensee requesting amendment of an existing operating license will make available the identified information by including it in the application. An applicant for certification of a standard design will make available the identified information by proposing ITAAC that address it. Similarly, an applicant for a COL will make available the identified information by (1) proposing ITAAC that addresses it or by referencing a certified design that does so and (2) addressing any remaining COL action items identified in connection with the topical report in a referenced design certification. A COL holder will ultimately address the information through the process of closing the associated ITAAC. BTP 7-14, A.3.1, describes three software planning characteristics: management, implementation, and resource. Management characteristics are significant to the management of the project activities. Implementation characteristics describe the work necessary to achieve the purpose of the planning documents. Resource characteristics describe the material resources necessary to carry out the work defined in the planning document. The SPM was reviewed against these planning characteristics. 3.1 Design Considerations The TXS platform is a distributed, redundant computer system. It consists of three or four independent redundant data-processing paths or channels, each with two or three layers of operation and running asynchronous with respect to each other. Layers of operation include signal acquisition, data-processing, and actuation signal voting. The TXS platform uses microprocessor-based digital equipment, operating system software, and plant-specific application software to perform safety-related I&C system functions at nuclear power plants. A full description of the TXS platform may be found in the original TXS topical report and safety evaluation (ADAMS Accession No. ML003732662). Application software is developed for project-specific applications of the TXS platform. Software implements plant-specific I&C control and logic functions, and is hardware dependent. Software will be developed using the Specification and Coding Environment (SPACE) tool, which translates functional diagrams into American National Standards Institute (ANSI) C code. Before application software can be loaded onto a TXS platform, it must be compiled for TXS

- 7 -

use. The TXS Software Program Manual describes the conditions and objectives to develop application software. SPM Figure 3-2 shows the scope of the TXS: A Digital Reactor Protection System Topical Report and the TXS Software Program Manual Topical Report. The former encompasses platform system software and hardware, and the latter, application software. 3.2 Software Life Cycle Planning Process for Application Software Digital I&C safety systems must be designed, fabricated, installed, and tested to quality standards commensurate with the importance of the safety functions to be performed. The development of safety system software should progress according to a formally defined software life cycle. Implementation of an acceptable software life cycle provides the necessary software quality. BTP 7-14, Section B.2.1 lists twelve software life cycle plans:

B.3.1.1 Software Management Plan B.3.1.2 Software Development Plan B.3.1.3 Software Quality Assurance Plan B.3.1.4 Software Integration Plan B.3.1.5 Software Installation Plan B.3.1.6 Software Maintenance Plan B.3.1.7 Software Training Plan B.3.1.8 Software Operations Plan B.3.1.9 Software Safety Plan B.3.1.10 Software Verification and Validation Plan B.3.1.11 Software Configuration Management Plan B.3.1.12 Software Test Plan

BTP 7-14, Section B.3.1 describes the acceptance criteria used for reviewing the 12 software plans of the Software Program Manual. 3.2.1 Software Management Plan The Software Management Plan (SMP) describes the management aspects of the software development project. BTP 7-14, Section B.3.1.1 describes acceptance criteria for software management plans. RG 1.173 endorses IEEE Std 1074-1995, “IEEE Standard for Developing Software Life Cycle Processes.” IEEE Std 1074-1995 describes, in terms of inputs and outputs, a set of processes and constituent activities that are commonly accepted as comprising a controlled and well-coordinated software-development process. While the standard specifies activities that are to be performed and their inter-relationships, it does not specify acceptance criteria for determining whether the activities themselves are properly designed. Therefore, IEEE Std 1074-1995 is to be used in conjunction with guidance from appropriate regulatory guides and standards. IEEE Std 1074-1995, Chapter 3, “Project Management Process,” describes an acceptable approach for software project management. It states that project management processes are “the processes that initiate, monitor, and control software projects throughout the software life cycle.”

- 8 -

Software Program Manual, Chapter 3 is the Software Management Plan. AREVA NP states that all design work, products, and services provided for a TELEPERM XS project are performed to the requirements of AREVA NP Quality Management Manual, and that the TELEPERM XS application software is also developed according to the requirements of the Software Program Manual. SPM Section 3.4 lists the hierarchy of documents that control application software development: AREVA NP Quality Management Manual; the SPM; Operating Instructions used to implement software plans, and project-specific plans for Software Quality Assurance; Software Safety; Software Configuration Management; Software Verification and Validation; and Software Operation and Maintenance. AREVA NP states that for each TELEPERM XS project, the Project Manager develops and approves a Project Plan, which details the project controls plan, overall project quality plan, project human resources plan, project communication plan, project risk management plan, project procurement/contract management plan, and the project close out plan. The staff finds the planning documentation, when implemented properly, is adequate to meet the guidance for project management. SPM Section 3.2 states that the AREVA NP Quality Management Manual provides the basic organizational structure that controls software quality, and that a specific organization is described in the Project Plan for that specific project. AREVA NP provides a typical project organization and describes quality assurance, management, and technical roles. SPM Section 3.3 lists and describes the role of Project Manager, Project Engineer, Technical Manager, Software Supervisor, Lead Software Designer, I&C Engineers, test group, training group, and quality assurance group. 10 CFR Part 50, Appendix B, Criterion I, requires that persons and organizations performing quality assurance functions report to a management level such that sufficient authority and organization freedom exist, including sufficient independence from cost and schedule limitations. Quality assurance functions include verifying, such as checking, auditing, and inspection, that activities affecting the safety-related functions have been correctly performed. Criterion III imposes an independence requirement for the verification, validation and checking of the adequacy of the design, requiring that those who perform the verification and checking be a person other than those who performed the design. RG 1.168 endorses IEEE Std 1012-1998 as an acceptable method to comply with the independence requirement. To satisfy the guidance in RG 1.168, AREVA NP states that it will maintain the independence of the Verification and Validation (V&V) group from the design organization and the independent reporting relationships for the Quality Assurance organization. SPM Figure 3-4 reflects these separation and reporting relationships. Also, SPM Section 3.3.9 states the V&V group has sufficient authority and resources, and is technically, managerially, and financially independent from the design organizations, The staff finds the independence, as AREVA NP has committed to in the Software Management Plan, is adequate to comply with regulation. BTP 7-14, Section B.3.1.1.2 states that SMP project management data should be systematically collected and analyzed to determine the effectiveness of project management. SPM Section 3.5 describes AREVA NP’s approach to problem reporting, which “handles hardware and software component problems, nonconformances, verification and validation and testing anomalies, reporting of defects and noncompliance in accordance with 10 CFR Part 21

- 9 -

as well as customer suggestions and potential product improvements.” AREVA NP utilizes its Corrective Action Program to identify and correct conditions adverse to safety and quality. SPM Section 3.5.2 describes the AREVA NP Open Items Process where “identified issues or Open Items are documented, and the organization responsible for the design evaluates and resolves them. Open items are collected in a project-specific database as they are identified.” AREVA NP states, “the Open Items database is the source of software quality metrics and is reviewed periodically by management to infer the effectiveness of the Software Quality Assurance (QA) program.” The staff finds such database tool, when implemented properly, is a way to measure the effectiveness of the software development process since data are systematically collected and analyzed. SPM Section 3.1.4 describes the scope of the SPM relative to BTP 7-14. The software activities that the SPM addresses are reviewed in this safety evaluation. Whereas the software activities that are the responsibility of the applicant or licensee are not reviewed as part of the scope of this Topical Report, those activities are to be addressed as applicant specific action items – this is listed in respective software planning sections and in the limitation and conditions of this safety evaluation. Per BTP 7-14, Sections B.3.2 and B.3.3, the applicant or licensee is to make available implementation activities and design outputs so that the staff can evaluate if the software management plan has been followed. This is ASAI 4.1. The SPM only addresses the vendor software planning processes for a TXS-based system. For all activities in which the applicant or licensee assumes responsibility within a given project (including vendor oversight) information is to be made available for the staff’s evaluation against NRC requirements and guidance. This is ASAI 4.2. Per BTP 7-14, Section B.3.1.1.1, the applicant or licensee is to provide an overview of a particular system within which the software will reside. Per BTP 7-14, Section B.3.1.1.2, the applicant or licensee is to provide the approach to be followed for recording the rationale for key decisions made in specifying, designing, implementing, procuring and assessing the software. Per BTP 7-14, Section B.3.1.1.3, the applicant or licensee is to provide necessary information so staff can evaluate the adequacy of budget and personnel for quality assurance, software V&V groups to ensure that they have sufficient resources to support a high quality design effort. Per BTP 7-14, Section B.3.1.1.3, the applicant or licensee is to make sure each member of the management and technical teams have the necessary experience or training to perform their duties. Per BTP 7-14, Section B.3.1.1.4, the applicant or licensee is to demonstrate that there is proper oversight of the vendors who will be developing the application software. This is ASAI 4.3. Per IEEE Std 1074-1995, Section 3.1.6, the applicant or licensee is to address the retirement phase of the software life cycle. This is ASAI 4.4. In summary, the staff finds the software management plan, when implemented properly, will establish the organization and authority structure for the application software development, the procedures to be used, and the relationships between major activities. The staff finds that the management structure provides for adequate project oversight, control, reporting, review, and

- 10 -

assessment and, therefore, the SMP satisfies IEEE Std 1074-1995, in terms of software project management. The staff finds that the software management plan adequately addresses the planning aspect of BTP 7-14, Section B.3.1.1, and is therefore acceptable. 3.2.2 Software Development Plan The Software Development Plan (SDP) describes the plan for technical project development. BTP 7-14, Section B.3.1.2 describes acceptance criteria for software development plans. RG 1.173 endorses IEEE Std 1074-1995 as providing an acceptable approach to software development processes. BTP 7-14 states that the SDP should clearly state tasks of each life cycle, and state the life cycle inputs and outputs. The review, verification and validation of those outputs should be defined. SPM Chapter 4 is the Software Development Plan. In order to provide compliance with IEEE Std 1074-1995, Clause 2.4, a software life cycle model must be selected to support the management of the project. SPM Section 4.3 states that the classic waterfall model is chosen as the software life cycle model for software development since nuclear safety requirements are generally well-known and stable at the time of project implementation. The waterfall model, as discussed in IEEE Std 7-4.3.2-1993, Annex E, assumes that each phase of the life cycle is completed in sequential order from requirements definition to the retirement phase. The staff does not determine which software life cycle model to use, but finds the AREVA NP choice acceptable since the waterfall model is better suited for projects with known requirements and where few changes to requirements are anticipated. Since AREVA NP selected an acceptable software life cycle model, the SDP satisfies IEEE Std 1074-1995, Clause 2.4. BTP 7-14, Section B.3.1.2.4 asks the applicant to state which tasks are a part of each life cycle, and state the life cycle inputs and outputs. SPM Section 4.3 lists project phases for TXS software applications: (1) Elaboration of the Quotation; (2) Project Start-Up; (3) Basic Design; (4) Detailed Design; (5) Manufacturing; (6) System Integration and Testing; (7) Installation and Commissioning; and 8) Final Documentation. SPM Table 4-1 provides a description of the inputs, tasks, processes, outputs, and results associated with each TXS project phase. As an example, SPM Table 4-1 describes Phase 1, Elaboration of Quotation, where AREVA NP receives the customer specification, processes it, and provides a proposal to the customer. In SPM Appendix A, AREVA NP mapped the SPM to the set of life cycle activities in IEEE Std 1074-1995. Accordingly, the applicant has addressed the identification of software life cycle activities. SPM Section 4.4 discusses the AREVA NP software classification scheme. SPM Table 4-3 compares the AREVA NP software integrity schemes with that of IEEE Std 1012-1998. The table is partially duplicated as follows:

- 11 -

Level IEEE Std 1012-1998 Scheme AREVA NP Scheme

4 Selected function affects critical performance of the system. Criticality: HIGH

Software that directly controls safety related components or systems which are necessary to ensure: •The integrity of the reactor coolant pressure boundary •The capability to safely shut down the reactor and maintain it in a safe shutdown condition

•The capability to prevent or mitigate the consequences of an accident that could result in potential offsite exposure in excess of 10 CFR Part 100 guidelines

3 Selected function affects important system performance. Criticality: MAJOR

Software which does not meet the definition of Level 4, however: •Is used to perform engineering design or performance calculations for safety related structures, systems, or components

•Is used to perform a function, which is significant to safety or supports a safety-related structure, system, or component

2 Selected function affects system performance, but workaround strategies can be implemented to compensate for loss of performance. Criticality: MODERATE

Software which does not meet the definition of Level 4 or Level 3, however: •Is used to support Technical Specification compliance, Safety Parameter Display System compliance, plant security, station emergency response support, or referred to in the Final Safety Analysis Report

•Directly controls or performs engineering designing or performance calculations for non-safety-related structures, systems, or components, or systems essential to plant operation

•Is important to comply with regulatory requirements / commitments as required by law and where failure to operate as expected may have indirect effect on nuclear plant safety

1 Selected function has noticeable effect on system performance but only creates inconvenience to the user if the function does not perform in accordance with requirements. Criticality: LOW

Software which does not meet the definition of Level 4, Level 3, or Level 2. Level 1 software is important to the continued operation of the plant and whose failure to perform as expected will not affect nuclear safety. Such software may control balance of plant systems, trend or perform analysis of plant operational data, or provide operation or maintenance information in support of decisions regarding plant activities. Level 1 software may also generate output that verifies compliance with regulations unrelated to nuclear safety such as state, local, and environmental laws.

0 A software integrity Level 0 may be assigned if there are no consequences associated with a software error that may occur in the system. For software integrity Level 0, no verification and validation tasks are implemented.

Software which cannot be categorized as Level 4, Level 3, Level 2, or Level 1. This level is used to show a classification process has been performed.

- 12 -

IEEE Std 1012-1998 does not mandate the use of the software integrity scheme referenced in the standard; software integrity levels denote a range of software criticality values necessary to maintain risks within acceptable limits. SPM Section 4.4 states that all application software on the safety processors and the Monitor and Service Interface is classified as Software Integrity Level (SIL) of 4 or SIL-4; this is based on the fact that TXS system is classified as Class 1E as defined by IEEE Std 603-1991. AREVA NP states that a criticality analysis determines the appropriate SIL classifications and assigns the classifications in accordance with the guidance of IEEE Std 1012-1998. Criticality analysis is discussed in the Software Safety Plan section of this evaluation. The staff finds the alternate software integrity level scheme acceptable since it is similar to IEEE Std 1012-1998, and the scheme is used to establish the minimum V&V tasks. IEEE Std 1012-1998, Clause 1.6 states that the mapping of the software integrity level scheme and the associated minimum V&V tasks shall be documented in the Software Verification and Validation Plan. SPM Section 11.9 describes the verification and validation methods for concept phase, requirements phase, design phase, implementation phase, and test phase. Also identified are the associated verification and validation tasks with software integrity level. For example, during the requirements phase, a software requirements traceability analysis is performed for SIL-4 and SIL-3. SPM Section 4.3 also states that AREVA NP takes exception to the source code commenting part of IEEE Std 1074-1995, Clause 5.3.4. Comments are normally embedded in the source codes to aid software developers to better understand the rational or logic. For TXS, source codes are automatically generated without comments by the SPACE tool. Instead, AREVA NP plans to document code comments in the Software Design Description (SDD) and in the Application Software Code Document (ASCD). As a result, software developers debugging applications will have to refer to an external source (SDD, ASCD) since comments are not directly embedded in the source code. Since source code comments are captured in another document, the staff finds the alternative approach acceptable. BTP 7-14, Section B.3.1.2.4 provides guidance for software tools, and references IEEE Std 7-4.3.2-2003, Clause 5.3.2, which states, in part, that software tools used to support software development processes and verification and validation processes shall be controlled under configuration management. To confirm the software tools are suitable for use, the clause further states either a test tool validation program shall be developed to provide confidence that the necessary features of the software tool function as intended or the software tool shall be used in a manner such that defects not detected by the software tool will be detected by V&V activities. SPM Section 4.2 discusses development support tools that are used to facilitate TXS application software development. The staff does not determine which software tools are used; however, the use of software tools should adhere to IEEE Std 7-4.3.2-2003, Clause 5.3.2. Examples include, but are not limited to, adequate training for software developers to use the tools, testing to verify the outputs of the tools, and configuration management of the version of the tools being used. IEEE Std 7-4.3.2-2003 also states that software tools shall be used in a manner such that defects not detected by the software tool will be detected by the V&V activities. The outputs of software tools should undergo the V&V process as defined in the Software Verification and Validation Plan (SVVP), in SPM Section 11. In this safety evaluation, the staff has not reviewed or approved any of the software tools. In the safety evaluation of TELEPERM XS Topical Report, the staff approved the use of SPACE tool, stating that this tool for designing and assembling safety-related applications has the

- 13 -

capability and safeguards to ensure that the implementation of the application programs can be successfully accomplished on a plant-specific basis. It should be noted that SPACE is not a safety-related application, and SPACE was not developed to the equivalent standards for safety-related software. Therefore, as stated in IEEE Std 7-4.3.2-2003, Clause 5.3.2, outputs from the SPACE tool are to undergo V&V as defined in the SVVP (SPM Section 11). SPACE tool provides a graphical programming interface to create, maintain, and debug application software for the TXS system. SPACE code generators are used to interpret the contents of the specification database and to automatically generate C programming language code for each function diagram. The development team creates graphical diagrams within the SPACE coding environment which are similar to functional diagrams used to describe the desired system operation. The design team then uses the SPACE tool to automatically generate equivalent ANSI C code which can be compiled for use on the TXS platform. Integration of software components (functions blocks) occurs with the use of the SPACE tool and the automatic generation of code. Integration of the software with the hardware occurs at the system test stage. BTP 7-14, Section B.3.1.2.4 asks the applicant to list industry standards and guidance to which the Software Program Manual will adhere. SPM Table 3-1 lists the industry standards endorsed by the NRC as well as other industry standards used by AREVA NP for the TELEPERM XS Application Software development process. For reference, the table is partially duplicated as follows: Standard NRC Endorsement SPM Section Addressing Standard IEEE Std 379-2000 RG 1.53 Software Safety Plan IEEE Std 352-1987 NOT ENDORSED Software Safety Plan IEEE Std 577-1976 NOT ENDORSED Software Safety Plan IEEE Std 603-1991 RG 1.153 Software Development Plan

Software Safety Pan IEEE Std 730-2002 NOT ENDORSED Software Quality Assurance Plan IEEE Std 828-1990 RG 1.169 Software Quality Assurance Plan

Software Configuration Management Plan IEEE Std 829-1983 RG 1.170 Software Development Plan

Software Quality Assurance Plan Software Test Plan

IEEE Std 830-1993 RG 1.172 Software Development Plan Software Quality Assurance Plan

IEEE Std 1008-1987 RG 1.171 Software Development Plan Software Test Plan

- 14 -

Standard NRC Endorsement SPM Section Addressing Standard

IEEE Std 1012-1998 RG 1.168 Software Management Plan Software Development Plan Software Integration Plan Software Verification and Validation Plan Software Test Plan

IEEE Std 1028-1997 RG 1.168 Software Quality Assurance Plan IEEE Std 1042-1987 RG 1.169 Software Configuration Management Plan IEEE Std 1063-2001 NOT ENDORSED Software Development Plan IEEE Std 1074-1995 RG 1.173 Software Development Plan

Software Maintenance and Operations Plan

IEEE Std 1228-1994 NOT ENDORSED Software Safety Plan IEEE Std 7-4.3.2-2003 RG 1.152 Software Management Plan

Software Quality Assurance Plan Software Verification and Validation Plan Software Configuration Management Plan

In SPM Appendix A, AREVA NP maps its TXS project phases to set of life cycle activities as defined in IEEE Std 1074-1995. In SPM Table 4-1, AREVA NP has identified the tasks for each phase as well as the inputs and outputs for each phase. The license/applicant is to make available the implementation and design activities for software development phase as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1. In summary, the project manager ensures that the design, verification and validation, and QA activities are conducted in accordance with this SPM and the AREVA NP Projects Manual. SPM Section 3.5.1 identifies the AREVA NP corrective action program to promptly identify and correct conditions adverse to safety and quality. SPM Section 3.5.3 handles the discrepancies identified during design review and audits. As such, there exists oversight to ensure that development process will be followed and any deviation will be discovered in time to take corrective action. The SDP adequately addresses the software development planning activities of BTP 7-14, as described above, and based on the AREVA NP commitment to IEEE Std 1074-1995; the staff finds the SDP acceptable. 3.2.3 Software Quality Assurance Plan BTP 7-14, Section B.3.1.3 provides guidance in evaluating a Software Quality Assurance Plan (SQAP). The SQAP shall comply with the requirements of 10 CFR Part 50, Appendix B, and the applicant’s overall QA program. 10 CFR Part 50, Appendix B states that the applicant shall be responsible for the establishment and execution of the quality assurance program. The applicant may delegate the work of establishing and executing the quality assurance program, or any part thereof, but shall retain responsibility for the quality assurance program. The SQAP would typically identify which QA procedures are applicable to specific software processes, identify particular methods chosen to implement QA procedural requirements, and augment and supplement the QA program as needed for software. IEEE Std 7-4.3.2-2003, Clause 5.3.1, which is endorsed by RG 1.152, provides guidance on software quality assurance.

- 15 -

IEEE Std 7-4.3.2-2003, Clause 5.3.1, states, “Computer software shall be developed, modified, or accepted in accordance with an approved software QA plan consistent with the requirements of IEEE/Electronic Industries Association (EIA) Std 12207.0-1996,” and that, “Guidance for developing software QA plans can be found in…IEEE Std 730-1998.” SPM Chapter 5 is the Software Quality Assurance Plan. SPM Section 5.1 indicates the Software Quality Assurance Plan conforms to the guidance of IEEE Std 7-4.3.2-2003, Clause 5.3.1 and SQAP conforms to IEEE Std 730-2002, which is an update to IEEE Std 730-1998. IEEE Std 730-2002, Page (iii), states this standard is consistent with IEEE/EIA 12207.1-1997, Clause 6.20, and obviates the need for Annex A of the 1998 version of the standard. In addition to eliminating Annex A of the 1998 version of this standard, minor structural changes have been made to conform to the current IEEE Standards Style Manual. IEEE Std 730-2002, Section 4.1 asks for listings of software items covered by the SQAP and the intended use of the software. SPM Section 5.1 lists the following software elements that are produced in the QA process: Test plans, cases, procedures or report; review and audit results; problem reports and corrective action documentation; software configuration management plans; software verification and validation plans; software safety plans; design documents; and application code. IEEE Std 730-2002, Section 4.3 asks for descriptions of organization, tasks, and responsibilities. SPM Section 5.2 states that the Technical Manager maintains the Software Quality Assurance Plan, and is responsible for ensuring that all project work is performed in accordance with the applicable QA processes and procedures. The V&V group manager ensures the Software Verification and Validation Plan and test documentation have been followed. Lastly, the QA group performs the audit activities and verifies the implementation of the QA measures. Additional roles and responsibilities are described in SPM Section 3.3. IEEE Std 730-2002, Section 4.4 asks for identification of documentation governing the development, verification and validation, use, and maintenance of the software, and which documents are to be reviewed or audited for adequacy. IEEE Std 730-2002, Section 4.4.2 lists the minimum documentation: Software Requirements Description (SRD); Software Design Description; Verification and Validation Plans; Verification Results Report and Validation Results Report; User Documentation; Software Configuration Management Plan; and other applicable documentation. SPM Section 4.5 describes software development documentation. SPM Section 11.13 describes V&V reports. SPM Section 13.6 describes Validation Test Documents. SPM Section 5.3 states the documentation for each project is produced and independently reviewed and takes into consideration the acceptance criteria for design outputs in BTP 7-14, Section B.3.3. IEEE Std 730-2002, Section 4.5 asks for identification of standards and conventions used, and how conformance to these items is monitored and assured. SPM Section 5.7 provides a reference to the regulations, regulatory guidance, and industry standards used. SPM Section 3.6 lists industry standards endorsed by the NRC and other industry standards used by AREVA NP for the TXS Application Software development process. SPM Section 3.5 describes the problem reporting process which is also used as a metric to measure software quality. IEEE Std 730-2002, Section 4.6 asks for the software reviews to be conducted; schedule; how the software reviews will be accomplished; and any further necessary actions. At minimum, the following software reviews will be conducted: Software Specifications Review (SSR);

- 16 -

Architecture Design Review (ADR); Detailed Design Review (DDR); Verification and Validation Plan Review; Functional Audit; Physical Audit; In-Process Audits; Managerial Reviews; Software Configuration Management Plan Review; Post-Implementation Review; and User Documentation Review (UDR). IEEE Std 1028-1997, endorsed by RG 1.168, provides guidance acceptable to the staff for carrying out software reviews for management reviews, technical reviews, inspections, walk-throughs, and audits. SPM Section 5.4 states software reviews are conducted in accordance with IEEE Std 730-2002 and IEEE Std 1028-1997. SPM Sections 5.4 and 5.5 describe the above minimum software reviews and audits and type of reviews used as defined in IEEE Std 1028-1997. SPM Section 5.5 states software audits conform to the guidance of IEEE Std 1028-1997 except where the guidance conflicts with the administrative requirements in the AREVA NP Quality Management Program Manual (e.g., audit meeting and reporting protocols, placement of signatures, use of coversheets, and location of reference sections, etc.). The staff finds this acceptable since administrative deviations are minor. SPM Section 5.5.1, “In-Process Audits,” did not mention audits or reviews for code generated from the SPACE tool. Instead, independent verification inspections and reviews will be performed by the Verification and Validation Group. To ensure a high-quality software development life cycle process, software audits are to be performed by the QA organization. IEEE Std 730-2002, Section 4.7 asks to identify all tests not included in the software verification and validation plan and to state the methods to be used. SPM Section 5.6 describes the Application Software Integration Test Plan and the Application Software System and Acceptance Test Plan. The goal of Application Software Integration Test Plan is to ensure all functionality defined in the Software Design Description is tested. The goal of the Application Software System and Acceptance Test Plan is to ensure that the functional requirements of the System Requirements Specification and Software Requirements Specification are tested. SPM Section 5.6.1 states that testing activities conform to guidance of IEEE Std 829-1983, which specifies the form and content of individual test documents. AREVA NP plans to implement test plans, test specifications including test procedures, and test report documentation. IEEE Std 730-2002, Section 4.8 asks to describe practices and procedures to be followed for reporting, tracking, and resolving problems, and to state specific organizational responsibilities concerned with implementation. SPM Section 5.8 states AREVA NP has a problem reporting program to document and process the anomalies and discrepancies. SPM Section 3.5 describes the problem reporting process used to handle hardware and software component problems, nonconformance, verification and validation and testing anomalies, reporting of defects and noncompliance in accordance with 10 CFR Part 21 as well as customer suggestions and potential product improvements. SPM Section 3.5.1 describes the AREVA NP Corrective Action Program, which is to identify and correct conditions adverse to safety and quality and to provide a means for customer notification of these conditions. Audit findings identified by Nuclear Procurement Issues Committee (NUPIC) are resolved through the AREVA NP Corrective Action Program. SPM Section 3.5.2 describes the Open Item Process in which identified issues are documented in a project specific database. The Open Items database is used as a software quality metric to measure effectiveness of the software QA program. Open Items that involve conditions adverse to quality and safety are entered into the Corrective Action Program. The Open Items that result in a modification to the software are processed under the change control procedures described in the Software Configuration Management Plan. The V&V Group verifies and validates the implementation of Open Item solutions if the Open Item is associated with software or a hardware/software issue. AREVA NP states that the Open Item database does satisfy the record keeping requirements of

- 17 -

10 CFR Part 50, Appendix B. SPM Sections 3.5.3, 3.5.4, and 3.5.5 describe how discrepancies identified during design reviews and audits, testing, and verification and validation, respectively, may constitute Open Items. SPM Section 3.5.6 states discrepancies identified after the release to the customer is to be handled in accordance with the AREVA NP Quality Management Manual and Corrective Action Program. AREVA NP and the customer examine the discrepancies for the impact on safety systems. IEEE Std 730-2002, Section 4.9 asks for identification of software tools, techniques, and methods used to support SQA processes. SPM Section 5.9.1 identifies the software tools and their intended use. SPM Section 5.9.1.1 discusses the methodology for generating the Software Requirements Specification, and makes a commitment to conform to IEEE Std 830-1993, as endorsed by RG 1.172. The Software Design group ensures that the software design incorporates the customer specification requirements, functional requirements, and software requirements. The V&V group traces the customer requirements from the System Requirements Specification (SysRS) through the System Description Document (SysDD) and incorporation into the Software Requirements Document (SRS). IEEE Std 7-4.3.2-2003, Section 5.3.1.1 states the use of software quality metrics shall be considered throughout the software life cycle to assess whether software quality requirements are being met. SPM Section 5.9.2 states software quality metrics are used throughout the software life cycle to assess the effectiveness of the software QA program. Software and design errors are recorded as Open Items during each phase of the development. AREVA NP commits to conforming to IEEE Std 7-4.3.2-2003. IEEE Std 730-2002, Section 4.10 asks for methods and facilities to be used to (1) identify the media for each intermediate and deliverable computer work product and the documentation necessary for storing the media, including the copy and restore process, and (2) protect media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. SPM Section 5.10.1 describes access control for the project database, and that the Software Supervisor is responsible for data backup procedures, schedules, and archiving. IEEE Std 730-2002, Section 4.10 asks for provisions for assuring that software provided by suppliers meets established requirements. SPM Section 5.11.1 states contracts with third party suppliers will include provisions of the SQAP. IEEE Std 730-2002, Section 4.11 asks for identification of the SQA documentation to be retained, methods and facilities to be used to assemble, file, safeguard, and maintain this documentation, and designate the retention period. SPM Section 5.12 states documents produced during the project are stored in the AREVA NP Records Management System. IEEE Std 730-2002, Section 4.13 asks for identification of training activities necessary to meet the needs of the SQAP. SPM Section 5.13 states design and V&V personnel are trained on the provisions of the SPM in accordance with AREVA NP training procedures. IEEE Std 730-2002, Section 4.14 asks for methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portions of the software life cycle covered by the SQAP. SPM Section 5.14 states the Program Manager identifies and assesses the technical, schedule, and regulatory risks of the project. SPM Section 5.15 states the V&V group performs an independent risk analysis at each phase of the V&V activities, and provides

- 18 -

the recommendation regarding the continuation into the next phase based on the software quality metrics. AREVA NP makes a commitment to conform to IEEE Std 7-4.3.2-2003, Clause 5.3.6 regarding software project risk management. The staff finds this acceptable. IEEE Std 730-2002, Section 4.15 asks for a glossary of terms unique to the SQAP. SPM Section 2 provides a list of definitions used in the SPM. IEEE Std 730-2002, Section 4.16 asks for SQAP change procedure and history. If the implementing procedures associated with a licensee’s application referencing the SPM results in a departure from the SPM, the application must justify the departure. Similarly, COL applicants are required to address implementing procedure changes to the NRC-approved SPM (ANP-10272-A). The staff review does not include the outputs of the software life cycle process, such as specific test plans. While the SPM may describe a high-quality process and controls commensurate with the demands of safety at nuclear power plants, the quality and safety of application software will rely heavily on the quality and coverage of test plans executed during the software life cycle process. The effort put in to the development of those test plans is paramount to ensuring the quality of the resultant application software. The staff reviewing applications referencing the AREVA NP SPM should take this into consideration, should conduct audits of the outputs of the various SPM plans and verifying that applicants have incorporated appropriate coverage and rigor into their test plans. The applicant or licensee is to make available implementation and design outputs as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1. 10 CFR Part 50, Appendix B, allows applicants or licensees to delegate the work of establishing and executing the Quality Assurance program, but applicants/licensees shall retain overall responsibility and shall determine if the quality of the software is sufficient. Applicants orlicensees referencing this topical report is to make available a Software Quality Assurance Plan. This is ASAI 4.2. In summary, the SQAP describes the process by which AREVA NP manages software and documentation throughout the software development life cycle, and the SQAP conforms to IEEE Std 730-2002. The Technical Manager maintains the SQAP, and is responsible for ensuring all project work is performed in accordance with the QA processes and procedures, as indicated by AREVA NP Quality Management Manual. Software reviews are performed in accordance with IEEE Std 730-2002 and IEEE Std 1028-1997. Software, In-Process, Physical, Functional, and Software Process Audits are performed in accordance with IEEE Std 1028-1997. The AREVA NP risk management process (risk identification, analysis and prioritization, response development, and risk monitoring and control) conforms to IEEE Std 7-4.3.2-2003, Clause 5.3.6. The SQAP adequately addresses the software quality planning activities of BTP 7-14, and based on the commitment of AREVA NP to IEEE Std 730-2002, the staff finds the SQAP acceptable. 3.2.4 Software Integration Plan BTP 7-14, Section B.3.1.4 provides guidance in evaluating a Software Integration Plan (SIntP). IEEE Std 1074-1995, Clause 5.3.7, which is endorsed by RG 1.173, provides an acceptable approach to an integration plan. Clause 5.3.7 states that during the plan integration activity, the software requirements and the software design description are analyzed to determine the order

- 19 -

of combining software components into an overall system. In addition, Clause 5.3.7 states that the integration planned information shall be coordinated with the test planned information as describe in IEEE Std 1074-1995, Clause 7.1. BTP 7-14, Section B.3.1.4.1 asks for a description of the software integration process and the software integration organization. SPM Chapter 6 is the Software Integration Plan. SPM Section 6.0 lists the three stages for the TXS integration process: TXS Platform Integration; project-specific Application Software integration; and project-specific hardware and software integration. SPM Section 6.1 states the integration of the generic TXS platform is the responsibility of AREVA NP GmbH. SPM Section 6.2 states the integration of the Application Software with the SPACE engineering tool is the responsibility of the Software Design Group, and the purpose of testing is to establish that the project-specific Application Software Function Blocks and Function Diagrams have been properly integrated, based on the project-specific system architecture and software design description. SPM Section 6.2 also states that Application Software Integration Testing is performed in accordance with the Software V&V Plan to conform to IEEE Std 1012-1998 validation measures. SPM Section 6.3 states the project-specific hardware and software integration is the responsibility of the Software Design Group. The physical integration of the Application Software with the project-specific TXS hardware occurs during the Factory Acceptance Test preparation stage, when the project-specific Application Software is loaded on the TXS processors. The integration effort is implemented with a project-specific Software Generation and Download Procedure. Project-specific Hardware and Software Integration Testing is performed in accordance with the Software Test Plan as described in SPM Section 13. The V&V Group is responsible for the software integration validation testing. BTP 7-14, Section B.3.1.4.2 asks for a set of indicators used to determine success or failure of the integration effort. SPM Section 3.5.2 describes the Open Item Process used to document identified issues. SPM Section 11.12 describes the metrics used by the Verification and Validation Group to measure effectiveness of the application software. AREVA NP considers the software development effective when the number of Open Items is trending down. The staff finds this approach acceptable since these metrics are used throughout the software life cycle, including the software integration phase. The applicant or licensee is to make available the implementation and design activities for software integration phase as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1. In summary, the Software Integration Plan describes the Application Software integration process and the TXS System hardware and software integration process. The plan also states which group is responsible for the integration activities. As set forth above, the Software Integration Plan adequately addresses the software integration planning activities of BTP 7-14, and the staff finds the Software Integration Plan acceptable. 3.2.5 Software Installation Plan An applicant referencing the SPM will need to address a Software Installation Plan as described in BTP 7-14, Section B.3.1.5. IEEE Std 1074-1995, Clause 6.1, endorsed by RG 1.173, provides an acceptable approach for software installation plans. IEEE Std 1074-1995, Clause 6.1.1 states an installation consists of the transportation and installation of the software system from the development environment to the target environment. It includes the necessary software modifications, checkout in the target environment, and customer acceptance. If a

- 20 -

problem arises, it must be indentified and reported. BTP 7-14, Section B.3.1.5.4 states that there should be approved procedures for software installation, for combined hardware and software installation, and systems installation. In addition, since the safety system is complex, there should be a controlled process to identify, correct, and document errors in the installation procedures. SPM Chapter 7 is the Software Installation Plan for a TELEPERM XS project to support Factory Acceptance Testing activities. However, as stated in SPM Section 7.0, the installation of the TELEPERM XS System in the plant environment is beyond the scope of the SPM. To support Factory Acceptance Testing activities, AREVA NP uses a project-specific TELEPERM XS Application Software Generation and Download Procedure as described in . SPM Section 7.1 SPM Section 7.1 states that the Software Design Group implements the Software Generation and Download Procedure, and that the Verification and Validation personnel can also install the software. SPM Section 7.1 also states that the Software Generation and Download Procedure is a configuration item controlled by the Software Configuration Management Plan. Therefore, any anomalies or issue with installation procedures are documented and corrected through the AREVA Open Items process. SPM Section 7.2 describes a process to verify that the correct version of the Application software has been loaded. In summary, the Software Installation Plan describes the Application Software installation process to support Factory Acceptance Testing activities. The plan states which group is responsible for the installation activity, states that a project-specific plan is under configuration control, and describes a process for software verification. As set forth above, the Software Installation Plan adequately addresses the software installation planning activities of BTP 7-14, and the staff finds the Software Installation Plan acceptable with regards to Factory Acceptance Testing activities. However, this Software Installation Plan does not address the installation of the TELEPERM XS System in the plant environment. Since the applicant or licensee assumes responsibility, including vendor oversight, for the software installation phase information necessary to address the criteria of BTP 7-14, Section B.3.1.5 is to be made available to the staff for evaluation. This will be evaluated through ASAI 4.2 and 4.11. 3.2.6 Software Maintenance Plan An applicant referencing the SPM will need to address a Software Maintenance Plan as described in BPT 7-14. Section B.3.1.6. IEEE Std 7-4.3.2-2003, Clause 5.4.2.3, endorsed by RG 1.152, provides guidance on maintenance and configuration management for commercially dedicated items. IEEE Std 1074-1995, Clause 6.3, endorsed by RG 1.173, provides an acceptable approach for software maintenance plans. IEEE Std 1074-1995, Clause 6.3.1 states a maintenance process is concerned with the resolution of software errors, faults, and failures; that the need for software maintenance initiates software life cycle changes. In SPM Chapter 8, AREVA NP states that the Software Maintenance Plan is not within the scope of the SPM, and that Software Maintenance Plan is to be addressed as a project-specific action item. Other than reading how AREVA NP may support the applicant or licensee with software maintenance, the staff did not review SPM Chapter 8. In summary, the Software Maintenance Plan is not within the scope of the Software Program Manual so a safety determination is not made for SPM Chapter 8. Since the applicant or

- 21 -

licensee assumes responsibility, including vendor oversight, for the software maintenance phase, relevant information is to be made available to the staff for evaluation. This is ASAI 4.2. An applicant or licensee is to make available for staff inspection, the processes that will be used for reporting software errors or anomalies to AREVA NP, to ensure that the Software Maintenance and Operations processes will be properly initiated as described in SPM Chapter 8. This is ASAI 4.6. The applicant or licensee is to make available, at minimum, project-specific procedures to address BTP 7-14, Section B.3.1.6. This is ASAI 4.11. 3.2.7 Software Training Plan An applicant referencing the SPM will need to address a Software Training Plan as described in BPT 7-14, Section B.3.1.7. IEEE Std 1074-1995, Clause 7.4, endorsed by RG 1.173, provides an acceptable approach to software training plans. IEEE Std 1074-1995, Clause 7.4.2 lists typical activities for this software life cycle activity: plan the training program, develop training materials, validate the training program, and implement the training program. If the licensee will be performing the digital system maintenance, the training plan(s) will be more involved, since additional knowledge is necessary to do maintenance. In SPM Chapter 9, AREVA NP states that the Software Training Plan is not within the scope of the SPM, and that Software Training Plan is to be addressed as a project-specific action item. Other than reading how AREVA NP may support the applicant or licensee with software training, the staff did not review Chapter 9 of the SPM. In summary, the Software Training Plan is not within the scope of the Software Program Manual, so a safety determination is not made for SPM Chapter 9. Since the applicant or licensee assumes responsibility, including vendor oversight, for the software training phase, relevant information is to be made available to the staff for evaluation. This is ASAI 4.2. The applicant or licensee is to make available, at minimum, project-specific plans that address BTP 7-14, Section B.3.1.7. This is ASAI 4.7. 3.2.8 Software Operations Plan An applicant referencing the SPM will need to address a Software Operations Plan as described in BTP 7-14, Section B.3.1.8. IEEE Std 1074-1995, Clause 6.2, endorsed by RG 1.173, provides an acceptable approach for software operations plans. IEEE Std 1074-1995, Clause 6.2.1 states an operation and support process involves user operation of the system and ongoing support. Support includes providing technical assistance, consulting with the user, and recording user support requests by maintaining a Support Request Log; thus the Operation and Support Process may trigger Maintenance Activities, which the Software Maintenance Plan should address. IEEE Std 1074-1995, Clause 6.2.3.2 states that the Installed Software System shall be utilized in the intended environment and in accordance with the operating instructions. In SPM Chapter 8, AREVA NP states that the Software Operations Plan is not within the scope of the SPM, and that Software Operations Plan is to be addressed as a project-specific action item. Other than reading how AREVA NP may support the software operation phase, the staff did not review SPM Chapter 8. In summary, the Software Operations Plan is not within the scope of the Software Program Manual, so a safety determination is not made for SPM Chapter 8 in this regard. Since the

- 22 -

applicant or licensee assumes responsibility, including vendor oversight, for the software operations phase, relevant information is to be made available to the staff for evaluation in requesting authorization to use the SPM. This is ASAI 4.2. An applicant or licensee is to make available for staff inspection, the processes that will be used for reporting software errors or anomalies to AREVA NP, to ensure that the Software Maintenance and Operations processes will be properly initiated as described in SPM Chapter 8. This is ASAI 4.6. The applicant or licensee is to make available, at minimum, project-specific procedures to address BTP 7-14, Section B.3.1.8. This is ASAI 4.11. 3.2.9 Software Safety Plan BPT 7-14, Section B.3.19 provides guidance to evaluate software safety plans (SSP). The SSP should provide appropriate safety measures in the software requirements specification. The SSP should define the safety-related activities to be carried out for each set of life cycle activities, from requirements through operation and maintenance. The SSP should describe the boundaries and interfaces between the software safety organization and others. It should show how the software safety activities are coordinated with the development activities and the interactions between software safety organization and the software V&V organization. SSP should designate a single safety officer that has clear responsibility for the safety qualities and has clear authority to accomplish the goals of the safety requirements in the SRS design, and implementation of the software. SPM Chapter 10 is the Software Safety Plan. SPM Section 10.0 states software safety analysis activities occur during the basic design, detailed design, testing, and installation and commissioning phases. The software safety analyses ensure that (1) system safety requirements as specified in the SRS have been met correctly, (2) no new hazards have been introduced, (3) software elements that can affect safety are identified, (4) other software elements do not affect safety, and (5) safety problems and resolutions identified in these analyses are documented. SPM Section 10.2 states the Technical Manager is responsible for the execution of the Software Safety Plan and for ensuring that these analyses are completed in accordance with the plan with the exception of the V&V activities. Responsibilities of the Project Manager and Software Supervisor are discussed in SPM Section 10.2. SPM Section 10.3 discusses the various activities that comprise the Software Safety Analyses and the group that performs them. The V&V Group performs Verification and Validation Activities described in SPM Section 10.3.5, the Application Software Integration Testing described in SPM Section 10.3.9, and the Application Software System and Acceptance Testing described in SPM Section 10.3.10. The V&V Group also reviews design work associated activities. The Software Design Group performs Criticality Analysis described in SPM Section 10.3.3, Application Software Requirements Traceability Analysis described in SPM Section 10.3.4, Response Time Analysis described in SPM Section 10.3.7, and the Automatic Code Generation described in SPM Section 10.3.8. The Hardware Design Group performs Failure Modes and Effects Analysis as described in SPM Section 10.3.6, and the Response Time Analysis described in SPM Section 10.3.7. Safety analyses are to be provided for the staff evaluation. Accordingly, the applicant or licensee is to make available implementation and design outputs as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1. AREVA NP commits to IEEE Std 1228-1994 with the exception of the independent safety organization. SPM Section 10.2 states that there is not a separate safety organization, and that

- 23 -

the responsibility to produce a safe TELEPERM XS application is not separate from the responsibility to produce a quality or functional product. AREVA NP also states that the Technical Manager has overall responsibility for the Software Safety Plan, the Project Manager coordinates the implementation of software safety tasks, and various design and test groups perform the software safety analyses. Through the Technical Manager, the various groups commit to performing the necessary safety activities to determine the acceptability of the digital system. The staff finds the approach acceptable. SPM Section 10.3.2 states that the Diversity and Defense-in-Depth Analysis is performed during the Basic Design Phase to assess the adequacy of diversity afforded by the system design. The applicant or licensee is to perform the diversity and defense-in-depth analysis in accordance with the guidance of BTP 7-19, and provide the results for staff’s evaluation. This is ASAI 4.2. SPM Section 10.3.3 states the criticality analysis is performed during the Basic Design Phase to define the Software Integrity Level for all project specific software items. As stated in SPM Section 4.4, criticality values are high (SIL-4), major (SIL-3), moderate (SIL-2), and low (SIL-1). Verification and validation includes a verification task to verify the assigned SIL is appropriate. For example, application software running on safety processors is classified as SIL-4. SPM Section 10.3.6 identifies that a Failure Modes and Effects Analysis (FMEA) is performed during the Detailed Design Phase to examine the effects of random single failures on the ability of the safety system to perform its required safety functions. AREVA NP states the FMEA will conform to IEEE Std 379-2000 in order to satisfy the single-failure criterion requirement of IEEE Std 603-1991, Clause 5.1. AREVA NP commits to the guidance in IEEE Std 352-1987, Section 4.1 in performing the FMEA. AREVA NP states it will meet the reliability requirement of IEEE Std 603-1991, Clause 5.15, for those systems that have either quantitative or qualitative reliability goals set by the applicant or licensee. AREVA NP commits to performing reliability analyses to demonstrate reliability goals have been met by using IEEE Std 352-1987 and IEEE Std 577-1976. The applicant or licensee is to make available for audit or inspection material demonstrating that the V&V activities for the proposed project meet the objectives of the Software Safety Plan. The staff’s evaluation will be performed for the Software Safety Analysis Activities designated in SPM Section 10.3, and as outlined in BTP 7-14, Section B.3.1.9.2. This is ASAI 4.5. In summary, the Technical Manager is responsible for the execution of the Software Safety Plan, and the V&V, Software, and Hardware groups will perform software safety analyses. As stated above, software safety analyses are to be made available for staff’s evaluation as part of a project-specific application. The Software Safety Plan adequately addresses the safety planning guidance in BTP 7-14, and based on AREVA NP’s commitment to IEEE Std 1228-1994, the staff finds the Software Safety Plan acceptable. 3.2.10 Software Verification and Validation Plan BTP 7-14, Section B.3.1.10 provides guidance to evaluate a Software Verification and Validation Plan. RG 1.168, Revision 1, endorses IEEE Std 1012-1998 as providing methods acceptable for meeting the applicable regulatory requirements listed in Section 2 of this report.

- 24 -

BTP 7-14, Section B.3.1.10.1 states that management characteristics of the SVVP should exhibit purpose, organization, oversight, responsibilities, and risks. SPM Chapter 11 is the Software Verification and Validation Plan. SPM Section 11.1 states the purpose of the SVVP, and that V&V activities include the reviews and inspections, analyses, and tests of applicant software. SPM Section 11.3 states that the V&V group manager is responsible for approving and implementing the SVVP, and that the V&V group is technically, managerially, and financially independent from the design group. SPM Figure 3-4 shows a typical organization chart. AREVA NP states conformance to IEEE Std 1012-1998. However, AREVA NP is taking one exception to IEEE 1012-1998 in regard to using engineers from the design team to help with testing. SPM Section 11.2 states that matrixed personnel from the software and hardware design groups may be used to supplement the validation activities. The staff finds this matrixed personnel approach acceptable as long as these personnel report to the V&V manager for the duration of support, do not develop test documents for design they prepared, and do not test the modules that they designed. The staff finds that AREVA NP has satisfactorily addressed the management characteristics of the SVVP since the V&V group is able to function independently as stated in IEEE Std 1012-1998 and IEEE Std 7-4.3.2-2003, Clause 5.3.4. BTP 7-14, Section B.3.1.10.2 states that SVVP should exhibit implementation characteristics that include the measurements to determine the success or failure of the software V&V efforts and procedures to describe software review and strategy. SPM Section 3.5.4 states discrepancies identified during testing are recorded in a test discrepancy log and evaluated with the software engineering group to determine problem resolution. Problems captured in the test log are addressed using the Open Item process. SPM Section 3.5.2 describes the Open Item Process. AREVA NP Condition Reports are used to capture and track problems encountered during testing. SPM Section 5.14.2 states the V&V group will perform an independent risk analysis at each phase of the V&V activities, and document the findings in the V&V report for each phase. SPM Section 11.9 discusses the V&V process, and that the V&V group performs the activities and tasks drawn from IEEE Std 1012-1998 with some modifications. AREVA NP states that test tasks are modified to address generic TXS platform testing. The staff review of the test tasks modification is set forth in Software Test Plan section of this evaluation. Hazard analysis is discussed in the Software Safety Plan of this evaluation. SPM Section 11.9 discusses the V&V activities for each phase of the Software Life Cycle (SLC): concept, requirements, design, implementation, test, installation, and maintenance and operation. For example, SPM Section 11.9.1 discusses the concept phase V&V activity based on the SIL classification for each task: Concept Phase Documentation Evaluation; Criticality Analysis; Requirements Allocation Analysis; Traceability Analysis; Hazard Analysis; Risk Analysis; Security Assessment; and Concept Phase V&V Activity Summary Report. SPM Section 4.4 states a criticality analysis determines and assigns the appropriate software integrity levels: high, major, moderate, and low. The staff finds that AREVA NP has satisfactorily addressed the planning characteristics of the SVVP since V&V activities are planned for each phase of the SLC and reports will be prepared for each phase providing analysis and detailing issues. BTP 7-14, Section B.3.1.10.3 states SVVP should include methods and tools used to carry out V&V tasks and industry and company standards to be followed by the V&V organization. SPM Section 11.9 discusses the Verification and Validation Methods. In SPM Section 11.7, AREVA NP made a commitment to define the tools used to perform or support V&V activities. SPM Section 5.9.1.5 lists tools that will be used: Software Requirements Traceability Matrix; TELEPERM XS software tools package; and test environment of the field test equipment.

- 25 -

The SPM makes mention of an NRC-approved testing tool, however, this testing tool has not been approved and is currently under staff review. AREVA NP states conformance to IEEE Std 1012-1998 and IEEE Std 7-4.3.2-2003, Clauses 5.3.1.1, 5.3.3, and 5.3.4. The applicant or licensee is to make available the implementation and design activities for software V&V phase as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1. In summary, the V&V group will be technically, managerially, and financially independent from the software design organizations. The V&V group performs the various software life cycle activities listed in IEEE Std 1012-1998 Table 1, which provides V&V task descriptions, inputs, and outputs for each life cycle process. V&V reports will be prepared for each software life cycle phase capturing analysis, risks, and issues. The Software Verification and Validation Plan adequately addresses the V&V planning guidance in BTP 7-14, Based on the AREVA NP commitment to meeting IEEE Std 1012-1998, with the exception cited above, and IEEE Std 7-4.3.2-2003, Clauses 5.3.1.1, 5.3.3, and 5.3.4, the staff finds the Software Verification and Validation Plan acceptable. 3.2.11 Software Configuration Management Plan BTP 7-14, Section B.3.1.11 provides guidance to evaluate the Software Configuration Management Plan, and states that IEEE Std 1074-1995, Clause 7.2 provides an acceptable approach to software configuration management. IEEE Std 1074-1995, Clause 7.2.1 states that software configuration management identifies the items in a software development project and provides both for control of the identified items and for reporting the status of such items to management to maintain visibility and accountability throughout the software life cycle. Examples of items to be controlled include, but are not limited to, code, documentation, plans, and specifications. BTP 7-14, Section B.3.1.11.1 asks for the definition of the responsibilities and authority of the Software Configuration Management (CM) organization. SPM Chapter 12 is the Software Configuration Management Plan. SPM Section 12.2 states that the Technical Manager has the overall responsibility for implementing the SCMP and that the Software Supervisor is assigned specific responsibilities for project configuration management activities. SPM Section 12.3.3 states the Software Librarian controls the Software Library, and is the only one who has access to the safety-related software. A set of software stored in the Software Library includes revisions of TXS System Software, TXS Application Software, TXS Gateway Software, and TXS Graphic Service Monitor Software. The staff finds the management activity acceptable since there is adequate oversight BTP 7-14, Section B.3.1.11.2 asks for implementation characteristics that the SCMP should exhibit including measurement, procedures, and record keeping. Measurement concerns a set of indicators used to determine the success or failure of the software CM activity. Procedures should be specified for identifying and naming configuration items, for synchronizing software code and documentation, for managing software libraries, for tracking problem reports, and for software tools used, among others. Record keeping concerns a description of the software CM record keeping provisions, and the SCMP should describe how configuration items are protected. SPM Section 12.4.3 states that software changes are initiated by entering an Open Item in the Open Items tracking system. Open Items are discussed in SPM Section 3. Changes to configuration items are recorded, approved, and tracked. The staff finds the Open Item process an acceptable way to measure the success or failure of a CM activity. SPM Section 12.4.1 states that the SCMP specifies the activities and conventions used for controlling

- 26 -

items and that each configuration item is labeled unambiguously. SPM Section 12.3.1 states the tracking system manages configuration items so revision history of each item is identifiable. The staff finds this acceptable in that the change management system preserves or protects each version of the configuration item. SPM Section 12.3.1 also lists the items to be controlled: code, version of support software used in development, libraries of software components essential to safety, code used in testing, databases and software configuration data. In SPM Section 12.2.2, AREVA NP states that the high-level configuration control board as defined in IEEE Std 1042-1987 applies to the TXS platform but is not applicable to TXS projects. The TXS platform deals with an integrated hardware and software suite, whereas TXS projects deal with project-specific application software using the SPACE tool. AREVA NP does intend to have a low-level configuration control board for each TXS project. The staff finds the alternate proposal of a low-level configuration control board acceptable since there will be a board that convenes to address application software changes. The applicant or licensee is to make available SCMP implementation and design outputs information as described in BTP 7-14, Sections 2.2 and 2.3. This is ASAI 4.1. The applicant or licensee is to make available for staff review a description of the applicant or licensee’s software configuration management programs for Installation, Checkout and Acceptance Testing, Operations, Maintenance, and Retirement Phases, as described in BTP 7-14. The staff will assess this activity to determine the adequacy of control measures, as applied to the safety-related software of the digital safety system being installed. This is ASAI 4.8. In summary, the SCMP provides a process to control software items through a software librarian, and it also provides a process to control software or documentation changes through a configuration control board. The Software Configuration Management Plan adequately addresses the guidance in BTP 7-14, and based on the AREVA NP commitment to meet IEEE Std 828-1990 and IEEE Std 1042-1987, the staff finds the Software Configuration Management Plan acceptable. 3.2.12 Software Test Plan BTP 7-14, Section B.3.1.12 provides guidance to evaluate a Software Test Plan. IEEE Std 829-1983, as endorsed by RG 1.170, provides an acceptable method for providing test documentation. IEEE Std 1008-1987, as endorsed by RG 1.171, provides an acceptable method for satisfying software unit test requirements. BTP 7-14, Section B.3.1.12.4 states the Software Test Plan (STP) should cover all testing done to the software, including unit testing, integration testing, factory acceptance testing, site acceptance testing, and installation testing. BTP 7-14, Section B.3.1.12.1 states that management characteristics of the STP should exhibit purpose, organization, responsibility, and security. SPM Chapter 13 is the Software Test Plan. SPM Section 13.1 states the approved generic TXS system provides the foundation for the project-specific Application Software System and Acceptance Testing. It also describes the project-specific tests which include configuration tests, tests of the interfaces to field signals and other I&C systems, failure behavior, and validation of performance data. SPM Section 11 describes the management and organization of the V&V group, which is responsible for testing.

- 27 -

BTP 7-14, Section B.3.1.12.2 states that implementation STP characteristics should exhibit measurement, procedures, and record keeping. Open Item metrics were discussed previously. SPM Section 13.2 describes the four testing activities discussed in IEEE Std 1012-1998: Component Testing, Integration Testing, System Testing, and Acceptance Testing. SPM Table 13-1 highlights generic TXS testing and project-specific testing for each of the four testing activities. Component Testing includes units and source code modules. SPM Section 13.3 discusses Application Software Integration Testing, which is to demonstrate that functional requirements of the software detailed design are properly implemented in the SPACE project database. SPM Section 13.3 makes mention of an NRC-approved testing tool, however, this testing tool has not been approved and is currently under separate staff review. SPM Section 13.4 discusses Hardware and Software Integration Testing, which is to demonstrate that project-specific TXS System has been configured correctly and operating properly. SPM Section 13.5 discusses the Application Software System and Acceptance Test, which is to demonstrate that functional requirements of the SysRS and SRS are validated. SPM Section 13.7 discusses test reporting. The applicant or licensee is to make available STP implementation and design outputs information as described in BTP 7-14, Sections 2.2 and 2.3. This is ASAI 4.1. SPM Section 13.5.1.2 states TXS hardware failure tests are defined by AREVA NP and the applicant or licensee. For all activities in which the applicant or licensee assumes responsibility within a given project information should be submitted for staff review against NRC requirements and guidance. This is ASAI 4.2. In summary, the STP covers Component Testing, Integration Testing, System Testing, and Acceptance Testing as described in IEEE Std 1012-1998. Test documentation will conform to IEEE Std 829-1983. The Software Test Plan adequately addresses the test planning guidance of BTP 7-14, Section B.3.1.12, and based on AREVA NP’s commitment to meeting IEEE Std 829-1983 and IEEE Std 1008-1987, the staff finds the Software Test Plan acceptable. 3.2.13 Summary On the basis of the review of AREVA NP software development process for application software, the staff concludes that the SPM specifies plans that will provide a quality software lifecycle process and that these plans commit to documentation of lifecycle activities that will permit the staff and others to evaluate the quality of the design features upon which the safety determination will be based. Since the application software has not yet been developed, the staff’s assessment does not include the review of the software life cycle implementation or design outputs, but rather the review is limited to the evaluation of the process. In other words, evidence that the plans were followed in an acceptable software life cycle and that the process produced acceptable design outputs is the subject of project-specific licensing reviews and approvals. For the software life cycle implementation and software life cycle design outputs, BTP-7-14, Sections B.2.2 and B.2.3 list the relevant documentation that would normally be reviewed. As such, the applicant or licensee is to make available the implementation and design outputs of the software lifecycle process as described in BTP 7-14, Sections B.2.2 and B.2.3. This is ASAI 4.1.

- 28 -

The SPM only addresses the vendor software planning processes for a TXS-based system. For all activities in which the applicant or licensee assumes responsibility within a given project (including vendor oversight) information is to be made available. This is ASAI 4.2. 3.3 Appendix C – TELEPERM XS Software and Secure Development and Operational

Environment Features RG 1.152, Revision 2 provides a method that the NRC finds acceptable for complying with Commission regulations (i.e., 10 CFR Part 50, Appendix A, GDC 21; 10 CFR Part 50, Appendix B, Criterion III; and IEEE Std 603-1991, Clauses 5.6.3 and 5.9) for promoting high functional reliability, design quality, and a secure development and operational environment (SDOE) for use of digital computers in safety systems of nuclear power plants. By committing to RG 1.152, Revision 2 in the SPM, the development of the TELEPERM XSTM (TXS) system and the TXS-specific application software is evaluated to the criteria for securing the development process and providing reliable secure operational environment features within the design for the identified life cycle phases. Appendix A of this Safety Evaluation provides a separate assessment of the Teleperm XS Software and SDOE features and forms the basis for the following conclusions as well as ASAI 4.11 identified in Section 4.0 of this evaluation. The staff concludes that: 1. The concepts of ensuring confidentiality, integrity, and availability, in conjunction with the

physical and logical access control features within the TXS platform, satisfy the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2. (2.1.1.1)

2. The application specific secure operational environment features identified for the preliminary design concepts is acceptable to address the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2. (2.1.1.2)

3. The identified vulnerabilities in Annex 2, Section 4.0 of Appendix C to the SPM is adequate to address the potential for unintended or unauthorized modifications to the TXS platform during its developmental phases. The vulnerabilities identified and the implicit measures included in the design to address these vulnerabilities through the various life cycles have been identified. Therefore, the staff has determined that the applicant has met Regulatory Position 2.1 of RG 1.152 for the TXS platform. (2.1.2.2)

4. Based on the platform development policy to prohibit remote access to the development networks, and the exclusion of remote access capabilities from the TXS platform design the applicant has satisfied the portion of the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2 to not allow remote access to the safety system. (2.1.3.1)

5. The development process adequately prevents unauthorized modifications to the TXS application software from remote locations and therefore adequately addresses the criterion in Regulatory Position C.2.1 of RG 1.152, Revision 2 to prevent remote access to safety systems. (2.1.3.2)

6. The system secure operational environment functional requirements and the external interfaces requirements provide measures sufficient to protect the TXS platform against inadvertent operator actions or undesirable behavior of connected systems during

- 29 -

operations to address the criterion within Regulatory Position C.2.2.1 of RG 1.152, Revision 2. (2.2.1.1.1)

7. The V&V requirements for the TXS platform have adequately addressed the criterion within Regulatory Position C.2.2.1 of RG 1.152, Revision 2 by providing that design feature requirements intended to maintain a secure operating environment and ensure reliable system operation, and that adequate V&V has been performed on these design requirements. (2.2.1.2.1)

8. The description of the V&V process for the software requirements phase is adequate to ensure the correctness, completeness, accuracy, testability, and consistency of the TXS-specific application software secure operational environment requirements. (2.2.1.2.2)

9. Since the TXS platform does not use pre-developed or COTS software and that all software is specifically developed and controlled, the criterion pertaining to the use of pre-developed software and COTS systems is not applicable to the TXS platform. (2.2.1.3.1)

10. Since the SPM specifies that TXS-specific application software will not include any COTS software, the criterion pertaining to the use of pre-developed software and COTS is not applicable to TXS-specific application software. (2.2.1.3.2)

11. The measures identified in Annex 2, Section 4.1 of Appendix C to the SPM adequately prevents inadvertent, unintended, or unauthorized modifications to the TXS platform system during the requirements phase to address Regulatory Position C.2.2.2 of RG 1.152, Revision 2. (2.2.2.1)

12. T he measures identified in Annex 2, SPM Appendix C, Section 6.1 are adequate to prevent inadvertent, unintended, or unauthorized modifications to the TXS application software during the requirements phase to address Regulatory Position C.2.2.2 of RG 1.152, Revision 2. (2.2.2.2)

13. The secure operational environment configuration items included in the TXS system design provide adequate physical and logical access to the TXS system and control of TXS system services to address the Regulatory Position C.2.3.1 of RG 1.152, Revision 2. (2.3.1.1)

14. The developer’s procedures and processes for the TXS system are adequate to protect the design phase of the TXS system life cycle from unauthorized and unintended modifications, and to preclude undocumented code and other unwanted or undocumented functions, and have met Regulatory Position C.2.3.2 of RG 1.152, Revision 2. (2.3.2.1)

15. The TXS application software developer’s procedures and processes will adequately protect the design phase of the TXS-specific application software lifecycle from unauthorized and unintended modifications, and preclude undocumented code and other unwanted or undocumented functions, and has met Regulatory Position C.2.3.2 of RG 1.152, Revision 2. (2.3.2.2)

- 30 -

16. The developer has ensured that the transformation of secure operational environment design configuration items from the TXS system design specification are correct, accurate, and complete to address Regulatory Position C.2.4.1 of RG 1.152, Revision 2. (2.4.1.1)

17. The use of the SPACE tool is adequate to ensure that the function block code adequately translates to safety application software (i.e., ANSI C source code). (2.4.1.2)

18. The description of how the AREVA NP internal independent V&V will verify the effective implementation of secure operational environment design features is adequate. This V&V process will ensure the transformation of secure operational environment design configuration items from the TXS-Specific application design specifications is correct, accurate, and complete. (2.4.1.2)

19. The TXS System developer’s procedures and processes are adequate to protect the implementation phase of the TXS system from unauthorized and unintended modifications to the development environment and to the TXS system under development, and have met the criterion in Section 2.4.2 of RG 1.152, Revision 2. (2.4.2.1)

20. The TXS-specific application developer’s procedures and processes is adequate to protect the implementation phase of TXS-specific applications from unauthorized and unintended modifications to the development environment, including the development tools, and to the TXS application software under development, and have met the criterion in Section 2.4.2 of RG 1.152, Revision 2. (2.4.2.2)

21. Based on the validation of the secure operational environment design features during the integration and system testing of the TXS platform, the TXS platform secure operational environment design features meet the criteria of Section C.2.5.1 in RG 1.152, Revision 2. (2.5.1.1)

22. T he applicant’s commitments to perform project-specific TXS system integration and acceptance testing in which a licensee or license applicant implementing TXS-based project will validate specific system and software design measures for access control, key switches, physical location, and other secure operational environment features to be adequate. (2.5.1.2)

23. Based upon the standards and procedures in place for the testing phase of the TXS platform and the scope of the testing for the TXS platform, including testing of the hardware, software, and communications features, the staff finds that the applicant has adequately addressed Regulatory Position C.2.5.2 of RG 1.152, Revision 2. (2.5.2.1)

24. Based on the process and procedures that will be in place during the testing, including testing of the hardware, software, and communications interfaces, the applicant will adequately protect the testing phase of the TXS application software from unauthorized and inadvertent modifications. (2.5.2.2)

25. The applicant has met the requirements of 10 CFR Part 50, Appendix A; GDC 21; 10 CFR Part 50, Appendix B, Criterion III; and IEEE Std 603-1991, Clauses 5.6.3 and 5.9, as it relates to a secure development and operational environment and reliability of the TXS platform and TXS-specific application software. (3.0)

- 31 -

Cyber security to address malicious events is under the purview of 10 CFR 73.54, “Protection of Digital Computer and Communication Systems and Networks,” and thus has not been evaluated as part of this review. Conformance to 10 CFR 73.54 is the responsibility of COL applicants or licensees who choose to reference the SPM. 4.0 Limitations and Conditions An application may reference the approved AREVA NP Topical Report ANP-10272 provided the application satisfies the following conditions and limitations. The conditions and limitations are intended to ensure that all aspects of digital safety system are properly designed and implemented. The following information is to be submitted or made available for staff audit/inspection upon receipt of an application for a License Amendment, a Design Certification, or a Combined License when referencing or incorporating by reference, Topical Report ANP-10272 . The SPM and this Safety Evaluation provide the context and basis for the required additional information.

The following constitutes the list of Application-Specific Action Items:

4.1 The SPM only includes the Software Life Cycle Process Planning Documentation as outlined in SRP BTP 7-14, Section B.2.1. The plant-specific documentation outlined in SRP BTP 7-14, Sections B.2.2, “Software Life Cycle Process Implementation,” and B.2.3, “Software Life Cycle Process Design Outputs,” is to be made available for staff audit/inspection, for any application that references the SPM.

4.2 The SPM only addresses the vendor software planning processes for a TXS-based system. For all activities in which the applicant or licensee assumes responsibility within a given project (including vendor oversight) information is to be made available fto the staff.

4.3 Per BTP 7-14, Section B.3.1.1.1 the applicant or licensee is to provide an overview of a particular system within which the software will reside.

Per BTP 7-14, Section B.3.1.1.2, the applicant or licensee is to provide approach to be followed for recording the rationale for key decisions made in specifying, designing, implementing, procuring and assessing the software.

Per BTP 7-14, Section B.3.1.1.3, the applicant or licensee is to provide necessary information so staff can evaluate the adequacy of budget and personnel for quality assurance, software V&V groups to ensure that they have sufficient resources to support a high quality design effort.

Per BTP 7-14, Section B.3.1.1.3, applicant or licensee is to make sure each member of the management and technical teams have the necessary experience or training to perform their duties.

Per BTP 7-14, Section B.3.1.1.4, the applicant or licensee is to demonstrate that there is proper oversight of the vendors who will be developing the application software.

4.4 Per IEEE Std 1074-1995, Section 3.1.6, the applicant or licensee is to address the retirement phase of the software life cycle.

- 32 -

4.5 The applicant or licensee is to make available for audit/inspection material demonstrating that the V&V activities for the proposed project meet the objectives of the Software Safety Plan. The staff evaluation will be performed for the Software Safety Analysis Activities designated in SPM Section 10.3 and as outlined in SRP BTP 7-14, Section B.3.1.9.2.

4.6 An applicant or licensee is to make available for staff inspection the processes that will be used for reporting software errors or anomalies to AREVA NP, to ensure that the Software Maintenance and Operations processes will be properly initiated as described in SPM Chapter 8.

4.7 The applicant or licensee is to make available for staff inspection the project-specific training plan which ensures the training needs of the plant staff, including operators, I&C engineers and technicians, as specified by the project, are fully achieved.

4.8 The vendor aspects of Software Configuration Management are specified in SPM Chapter 11. An applicant or licensee is to make available a description of the applicant or licensee’s software configuration management programs for the Installation, Checkout and Acceptance Testing, Operations, Maintenance, and Retirement Phases, as described in BTP 7-14. The staff will assess this activity to determine the adequacy of control measures, as applied to the safety-related software of the digital safety system being installed.

4.9 Each applicant or licensee referencing the SPM will address secure operational environment items, consistent with RG 1.152, Revision 2, Items C.2.6 through C.2.9 for the installation, acceptance testing, operation/maintenance, and retirement phases.

4.10 An applicant or licensee referencing the SPM will address the software planning and development activities for the installation, maintenance, and operations phases of the software lifecycle, as described in BTP 7-14.

4.11 SPM Appendix C only includes the Secure Development and Operational Environment Life Cycle Planning Documentation for TXS-Specific Applications. The outputs of the Secure Development and Operational Environment Life Cycle Development Process for TXS-Specific Applications is to be made available for staff audit/inspection for any application that references the SPM. This includes:

a) The final vulnerability analysis that identifies the secure operational environment capabilities for TXS-specific applications.

b) Provisions pertaining to secure operational environment security functional performance requirements, external interfaces, qualification, human factors engineering, data definitions, documentation for the software and hardware, physical location, and remote access for TXS-specific applications.

c) Requirements for operations and maintenance to ensure system integrity are maintained for TXS-specific applications, including the TXS Service Unit, maintenance laptop, and the test machine.

- 33 -

d) Secure operational environment design configuration items for TXS-specific applications that will complement the secure operational environment design features in the TXS system software.

e) Implementation and configuration of secure operational environment features for TXS-specific applications to ensure that the secure operational environment design configuration item transformations from the application software design specification are correct, accurate, and complete.

f) Test results for the integration, system, and acceptance testing of TXS-specific applications.

5.0 CONCLUSIONS This safety evaluation discusses the acceptability of the AREVA SPM for use in developing software planning documents. 10 CFR 50.55a(a)(1), Quality Standards for Systems Important to Safety, is addressed by compliance with the codes and standards listed in the SRP. The SPM conforms to various codes and standards that are identified in BTP 7-14. Where deviations from codes and standards were taken, the staff reviewed the deviations and determined that the deviations were appropriate and acceptable. The staff concludes that the SPM is in compliance with this requirement. 10 CFR 50.55a(h) incorporates by reference IEEE Std 603-1991, which addresses quality criteria for safety-related digital systems used in nuclear power plants. IEEE Std 7-4.3.2-2003, which is endorsed by RG 1.152, Revision 2, provides guidance for meeting IEEE Std 603-1991 in regard to software systems. The staff finds that the SPM addresses the criteria in IEEE Std 7-4.3.2-2003 and, therefore, is in compliance with this requirement. 10 CFR Part 50, Appendix A, General Design Criteria 1, “Quality Standards and Records,” requires structures, systems, and components important to safety to be designed, fabricated, erected, and tested to quality standards commensurate with the importance of the safety functions to be performed. The staff finds that the SPM identified and conforms to appropriate quality standards. Therefore, the staff concludes that the SPM complies with this requirement. 10 CFR Part 50, Appendix B, “Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants,” provides criteria for quality assurance programs for design, fabrication, construction, and testing of structures, systems, and components of safety-related systems. The staff has reviewed the quality assurance aspects of the SPM and determined that the SPM complies with the applicable criteria of 10 CFR Part 50, Appendix B. Chapter 2 (Definitions) and Appendix B (Historical Information) of ANP-10272 were not reviewed. Based on the information provided and the review conducted, the staff concludes that the software lifecycle process and program measures presented within the SPM meet the relevant NRC regulatory requirements. The SPM is acceptable for safety-related application software development for use at nuclear power plants which utilize the TXS platform for digital safety systems, provided the plant-specific application demonstrates satisfactory resolution of the ASAIs listed in Section 4.0 of this report and any restrictions identified herein.

- 34 -

For the reasons set forth above, the staff finds ANP-10272 acceptable for referencing in a plant-specific application provided that the application demonstrates those limits and conditions addressed in Section 4 of this evaluation are met. In addition, the specific scope of the staff’s review, and acceptance of design aspects described in ANP-10272, is discussed in Section 3 of this evaluation. Principal Contributors for SPM review: Tung Truong NRO/DE, Richard Stattel NRR/DE Principal Contributor for SDOE review: Deanna Zhang NRO/DE Date: June 2011

- 35 -

LIST OF ACRONYMS

ASAI application-specific action item BTP Branch Technical Position CFR Code of Federal Regulations FAT factory acceptance testing I&C instrumentation and control IEEE Institute of Electrical and Electronics Engineers RAI request for additional information RG Regulatory Guide SCMP Software Configuration Management Plan SOMP Software Operations and Maintenance Plan SPM Software Program Manual SQAP Software Quality Assurance Plan SRP Standard Review Plan SSP Software Safety Plan SVVP Software Verification and Validation Plan V&V verification and validation

- 36 -

Safety Evaluation - Appendix A

Technical Evaluation of ANP-10272P, Software Program Manual Appendix C TELEPERM XS Software and Secure Development and Operational Environment Features RG 1.152, Revision 2 provides a method that the NRC finds acceptable for complying with Commission regulations (i.e., 10 CFR Part 50, Appendix A, GDC 21, 10 CFR Part 50, Appendix B, Criterion III, and IEEE Std 603-1991, Clauses 5.6.3 and 5.9) for promoting high functional reliability, design quality, and a secure development and operational environment (SDOE) for use of digital computers in safety systems of nuclear power plants. SDOE in this context refers to protective actions taken against a predictable set of non-malicious acts (e.g., inadvertent operator actions, undesirable behavior of connected systems) that could challenge the integrity, reliability, or functionality of a digital safety system. RG 1.152, Revision 2 utilizes the waterfall life cycle phases to provide a framework for establishing digital safety system SDOE guidance, as well as criteria for acceptability, in the development of high quality safety systems. AREVA NP’s commitment to RG 1.152, Revision 2 in the SPM, provides assurance that the development of the TELEPERM XSTM (TXS) system and the TXS-specific application software will be evaluated to criteria which secure the development process and ensure reliable secure operational environment features within the design, for the following life cycle phases: • Concepts • Requirements1 • Design • Implementation • Test • Installation, Checkout, and Acceptance Testing • Operation • Maintenance • Retirement Cyber security to address malicious events is under the purview of 10 CFR 73.54, “Protection of Digital Computer and Communication Systems and Networks,” and thus has not been evaluated as part of this review. Compliance with 10 CFR 73.54 will be addressed by COL applicants or Licensees. 1. TXS SDOE Technical Evaluation This report only bases its regulatory findings on Regulatory Positions C.2.1 through C.2.5 (i.e., Concepts through Test Phases) of the development of the TXS system and the TXS-specific application software. In addition, since the application software has not been submitted for review or inspection, and application software is likely to be different in each project-specific application, the staff’s evaluation does not include the review of the outputs of the life cycle process, but is limited to the evaluation of the specified development processes. Likewise, the staff evaluation does not include the review of the project-specific portions of the SPM. As such, compliance with Regulatory Positions C.2.6 through C.2.9 of RG 1.152,

1 Unless otherwise specified, use of the word “requirements” in this document refers to software design specifications or software development provisions. Regulatory requirements will be specifically identified as such where they are discussed within this Safety Evaluation.

- 37 -

Revision 2 (i.e., Installation, Checkout, and Acceptance Testing; Operation; Maintenance; and Retirement phases) will be included as application-specific action items for applicants referencing the SPM in the development and implementation of the application software. The TXS platform was developed several years ago, and Topical Report, EMF-2110, “TELEPERM XS: A Digital Reactor Protection System,” Revision 1 (ADAMS Accession No. ML003732662),” was submitted and accepted by the NRC with a safety evaluation report in May 2000. A security evaluation for the TXS platform was not specifically conducted by the NRC when Topical Report EMF-2110 was reviewed due to the fact that RG 1.152 Revision 2, was not issued until January 2006. Although the platform was developed previously in Germany, security measures were in place during the TXS platform development. TXS-specific application software that references this SPM may be developed in a different AREVA NP location. As such, where relevant, this evaluation will address SDOE provisions for both the TXS platform and the design process of TXS-specific application software. 2.1 Concepts Phase 2.1.1 System Security Capabilities Regulatory Position C.2.1, “Concepts Phase,” of RG 1.152, Revision 2 specifies that the licensee and developer should identify safety system design features that should be implemented to establish a SDOE for the system. 2.1.1.1 TXS Platform Although the TXS platform was reviewed and accepted several years prior to the issuance of RG 1.152, Revision 2, the TXS platform design did incorporate several SDOE features in the design that apply to ensuring reliability of the system. SPM Appendix C, Section 6.1 states that a formal vulnerability analysis that identifies safety system security capabilities that should be implemented, as described in RG 1.152, Revision 2, was not performed for the TXS platform since RG 1.152, Revision 2 was not in effect at the time of the system development. However, key SDOE concepts were considered in the TXS System development as discussed in Topical Report, EMF-2110. These security concepts include: • Compliance with IEEE Std 603-1991, Clause 5.9, “Control of Access” • Faults in the non-safety related portions of the TXS System (i.e., TXS Service Unit and

Gateway) must not affect the operation of the safety-related portions of the system • Location of TXS equipment within a secure area • Development of safety-related software in a controlled environment In addition, SPM Appendix C, Section 2.0 states that the TXS System conforms to the design objectives of ensuring system confidentiality, integrity and availability. As applied to the TXS platform design, confidentiality, in the context of SDOE, is generally understood as ensuring that information is accessible only to those authorized to have access. Integrity, in the context of SDOE, is generally understood as ensuring that an unauthorized party cannot modify a system setup or the information saved in a system or transferred over a network. Availability, in the

- 38 -

context of SDOE, is generally understood as ensuring that a legitimate user can maintain access to information, a system, or a network. The SDOE capabilities of the TXS platform, which include physical and logical access controls, safety to non-safety isolation, and control of the various lifecycle activities, were derived from these security concepts. This includes prohibiting remote access to the TXS System. These SDOE capabilities identified were used to establish the SDOE requirements for the system hardware and software, which are addressed in Section 2.2.1 of this report. Even though the TXS platform was developed several years prior to the issuance RG 1.152, Revision 2, the staff’s review concludes that the concepts of ensuring confidentiality, integrity, and availability, in conjunction with the physical and logical access control features within the TXS platform, satisfy the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2 to identify safety system SDOE capabilities. 2.1.1.2 TXS-Specific Application Software The concepts identified for the TXS platform also apply to future TXS-specific application software. As stated in SPM Appendix C, Section 6.1, this includes preliminary design concepts for SDOE features, such as access controls, key switches, control room alarms, TXS equipment location, and TXS Gateway interfaces. The staff finds the secure operational environment features identified for the preliminary design concepts acceptable in addressing the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2 to identify safety system SDOE capabilities. However, the final secure operational environment analysis that supports the integrity and reliability capabilities for TXS-specific applications is to be made available for staff audit/inspection for any application that references the SPM. This is ASAI 4.11. 2.1.2 Identification of Lifecycle Vulnerabilities Regulatory Position C.2.1 of RG 1.152, Revision 2 also specifies that the licensee and developer should perform an assessment to identify the digital safety systems’ potential susceptibility to inadvertent access and undesirable behavior from connected systems over the course of the system’s lifecycle that could degrade the system’s reliable operation. This assessment should identify the potential challenges to maintain a secure operational environment for the digital safety system and the challenges to maintaining a secure development environment for the system’s development lifecycle phases. The results of the analysis should be used to establish design feature requirements (for both hardware and software) to establish a secure operational environment and protective measures that are required to maintain a secure development environment.

- 39 -

2.1.2.1 TXS Platform A formal assessment for the TXS platform design was not performed initially since the original development of the TXS platform was completed prior to the issuance of RG 1.152, Revision 2. In lieu of a formal assessment, the applicant provided an analysis of the vulnerabilities that would have been applicable to the development of the TXS platform. Annex 2, SPM Appendix C, Section 4.0 describes the following vulnerabilities that have been identified for the various life cycle phases of the TXS platform development. [ • • • • • • • • • • • • • • • ] The staff finds that the identified vulnerabilities of the TXS platform development, along with the services and interfaces with other systems, have been assessed from the concepts phase through the test phase. Specifically, given the development process of the TXS platform, these identified vulnerabilities correlate to the activities and outputs of all phases of the development process that can potentially be modified unintentionally or without authorization. Therefore, the staff finds that these vulnerabilities provide reasonable assurance that potential areas for unintended or unauthorized modifications to the TXS platform during its developmental phases have been identified. The vulnerabilities identified above were used to drive the SDOE controls for the system hardware and software development, which are described in Sections 2.2.2.1, 2.3.2.1, 2.4.2.1, and 2.5.2.1 of this report. Based on the staff review of the vulnerabilities identified and that the implicit requirements to address these vulnerabilities through the various life cycles are identified, the staff has determined that the applicant has met this criterion of Regulatory Position 2.1 of RG 1.152 for the TXS platform. 2.1.2.2 TXS-Specific Application Software In addition to the vulnerabilities identified for the TXS platform, Annex 2, SPM Appendix C, Section 6.0 identified the following postulated vulnerabilities that can occur during the various life cycle phases of the TXS-specific application software development.

- 40 -

[ •

•

•

•

•

•

•

•

•

• ] The staff finds that the applicant has adequately identified postulated vulnerabilities of the TXS-specific application software development process from potential unintended or unauthorized modifications. Specifically, given the development process of the TXS-specific application software, these identified vulnerabilities correlate to the activities and outputs of all phases of the development process that can potentially be modified unintentionally or without authorization. Therefore, the staff finds that these vulnerabilities provide reasonable assurance that potential areas for unintended or unauthorized modifications to the TXS-specific application software during its developmental phases have been identified. The vulnerabilities identified above were used to drive the secure operational environment design controls for the system hardware and software development, which are described in Sections 2.2.2.1, 2.3.2.1, 2.4.2.1, and 2.5.2.1 of this report. Based on the staff’s review that the vulnerabilities have been identified and that the implicit requirements to address these vulnerabilities through the various life cycles are identified, the staff has determined that the applicant has met this criterion of Regulatory Position 2.1 of RG 1.152 for TXS-specific application software.

- 41 -

2.1.3 Remote Access and One-way Communication Regulatory Position C.2.1 of RG 1.152, Revision 2 further states that remote access to the safety system should not be implemented. Computer-based safety systems may transfer data to other systems through one-way communication pathways. The acceptability of this criterion is evaluated by staff in conjunction with the bi-directional communications guidance provided in Digital Instrumentation and Controls (D I&C) Interim Staff Guidance (ISG) #4 – Highly Integrated Control Room-Communications Issues (HICRc). 2.1.3.1 TXS Platform As discussed in Topical Report, EMF-2110, within the TXS Platform, communication between the safety and other systems are not restricted to unidirectional. Bi-directional communication exists between the non-safety Service Unit and the TXS platform via the Monitoring and Service Interface (MSI). In addition, SPM Appendix C, Section 4.2.5 states that the special purpose maintenance laptop and test machine may also be used to access the platform processors; however, they must be locally attached into the X4.1 connector at the front of the SVE2 board, and are only used in special, non-operational situations. In addition, the MSI and gateway between the TXS system and non-safety systems, such as the service unit and gateway, can be configured for bi-directional configuration. Furthermore, Annex 1, SPM Appendix C, discusses the permanent connection between the TELEPERM XS Service Unit and TXS safety systems. The TXS platform was developed with no remote access as stated in SPM Appendix C, Section 4.2.6. In addition, SPM Appendix C, Section 5.1 affirms that it is a standard AREVA NP GmbH (i.e., the TXS platform development vendor) policy not to allow remote access to the development networks. Based on the TXS platform development policy to prohibit remote access to the development networks, and the exclusion of remote access capabilities from the TXS platform design, the staff finds the applicant has satisfied this portion of the criterion within Regulatory Position C.2.1 of RG 1.152, Revision 2 to not allow remote access to the safety system. However, since the platform design does not prohibit the use of bi-directional communication, the evaluation of the acceptability of bi-directional communication between the TXS system and non-safety system, including the acceptability of the MSI and the permanent connection of the Service Unit to TXS safety systems is not evaluated in this safety evaluation, as the subject is outside the scope of the SPM and will be reviewed as part of any application using the TELEPERM XS platform. In addition, the implementation of access controls and configuration management of the maintenance laptop during the operation/maintenance phase has not been evaluated in this safety evaluation. Each applicant or licensee referencing the SPM will address systems secure operational environment items consistent with Regulatory Positions C.2.6 through C.2.9 of RG 1.152, Revision 2 for the installation, acceptance testing, operation/maintenance, and retirement phases. This includes the implementation of access controls and configuration management of the maintenance laptop. This is ASAI 4.09 2.1.3.2 TXS-Specific Application Software As stated in SPM Appendix C, Section 4.2.2, the TXS system is allowed bi-directional communication with the TXS Service Unit to diagnose system alarms, monitor and test the TXS System, and to make parameter and software changes. In addition, SPM Appendix C,

- 42 -

Section 4.2.3 states that the TXS Gateway is designed to support two-way communication via the MSI to provide communications independence. SPM Appendix C, Section 4.2.5 states that the remote access capability was not implemented for the TXS System. For the development of TXS-specific application software, SPM Appendix C, Section C.5.2 states that “Standard AREVA NP Inc., policy does not allow remote access to the development server.” In addition, SPM Section C.5.2 identifies that the engineering server must be equipped with a SPACE license dongle, which is physically connected to the engineering server in order to access the SPACE Engineering Tool. All SPACE license dongles are controlled by the Software Configuration Management Plan. While the SPM states that remote access capability was not incorporated into the TXS platform and remote access cannot be provided through TXS-specific application software, an applicant or licensee who references the SPM will have to demonstrate that remote access is not included in the TXS-Specific application software to fully address this criterion of Regulatory Position C.2.1 of RG 1.152, Revision 2, to prohibit remote access to safety systems. This is ASAI 4.11. In addition, since remote access is prohibited to the development engineering servers and a special license dongle is required on the engineering servers to modify the application software, the staff finds that the development process is adequate to prevent unauthorized modifications to the TXS application software from remote locations. As such, the staff finds the development environment controls have adequately addressed the criterion in Regulatory Position C.2.1 of RG 1.152, Revision 2 to prevent remote access to the TXS safety systems. Since the SPM does not prohibit the use of bi-directional communication, the evaluation of the acceptability of bi-directional communication between the TXS system and non-safety system will need to be reviewed during the design and implementation of TXS-specific application software to address this portion of Regulatory Position C.2.1 of RG 1.152, Revision 2. As discussed in Section 2.1.3.1 of this report, the implementation of access controls and configuration management of the maintenance laptop during the operation/maintenance phase has not been evaluated in this safety evaluation. Licensees/applicants who reference the SPM will address this secure operational environment item, as specified in ASAI 4.09. 2.2 Requirements Phase 2.2.1 System Features 2.2.1.1 Secure Operational Environment Functional Performance Requirements Regulatory Position C.2.2.1 of RG 1.152, Revision 2 states, in part, that the licensees and developers should define the secure operational environment functional performance requirements and system configuration; interfaces external to the system; and the requirements for qualification, human factors engineering, data definitions, documentation for the software and hardware, installation and acceptance, operation and execution, and maintenance. 2.2.1.1.1 TXS Platform Although the TXS platform was developed prior to the issuance of RG 1.152, Revision 2, several of the system functional requirements established to protect the TXS safety functions can be applied to secure operational environment functional performance requirements. These requirements are based on the secure operational environment capabilities identified in the

- 43 -

“concepts phase,” as described in Annex 2, SPM Appendix C Section C-4.2 and Section 7, which include: • Communication independence, safety to non-safety system isolation, interference-free

communication.

• Access control attributes of confidentiality, integrity, and availability.

• Locking and monitoring of all cabinets containing safety-related equipment.

• Location of all TXS equipment in site protected areas. These requirements are enumerated in the access control requirements stated in Topical Report, EMF-2110, Sections 2.6.2 and 2.9.

• No dynamic memory allocation for on-line software.

• Asynchronous operating system for the TXS system

• Restriction of the modification of program code from only the TXS Service Unit. In addition, the following requirements have been established for the TXS platform for external interfaces, as described in Topical Report, EMF-2110 and Annex 2, SPM Appendix C, Section 7: • Enforce controls on the limited two-way communications between the TXS Service Unit

and the safety system processors through isolation barriers (i.e., MSI).

• Interference-free communication with all external interfaces through the MSI. The MSI is the only physical network connection that exists between the TXS safety function processors and non-safety systems.

• Filtering messages from the external interfaces. Given the system secure operational environment functional requirements and the external interfaces requirements for the TXS platform provided in SPM Appendix C and Topical Report, EMF-2110, the staff finds that the identified measures are sufficient to protect the TXS platform against inadvertent operator actions or undesirable behavior of connected systems during operations to address the criterion within Regulatory Position C.2.2.1 of RG 1.152, Revision 2, to define the secure operational environment functional performance requirements. However, the physical location of TXS-equipment will need to be addressed by an applicant or licensee who references the SPM, as specified in ASAI 4.09. 2.2.1.1.2 TXS-Specific Application Software The requirements stated above for the TXS platform are also applicable for TXS-specific application software. However, additional requirements pertaining to secure operational environment function performance, external interfaces, qualification, human factors engineering, data definitions, and documentation for the software and hardware may be generated based on the design and implementation of TXS-specific application software. This is ASAI 4.11. As specified in SPM Appendix C, Section 6.2, this includes provisions for access control, key

- 44 -

switches, control room alarms, TXS equipment location, and TXS Gateway interfaces. This also includes the design and implementation of communications flow restrictions to meet communications independence requirements of IEEE Std 603-1991, Clause 5.6.3. IEEE Std 603-1991, Clause 5.6.3 requires safety system to be designed such that credible failures in and consequential actions by other systems shall not prevent the safety systems from performing their intended safety functions. In addition, provisions for operations and maintenance to ensure system integrity is maintained, including for the TXS Service Unit, maintenance laptop and the test machine, will be reviewed during the design and implementation of TXS-specific application software. This is ASAI 4.11. 2.2.1.2 SDOE Requirements V&V RG 1.152, Revision 2, Section 2.2.1 specifies that design feature requirements intended to maintain a secure operating environment and ensure reliable system operation should be part of the overall system requirements. Therefore, the verification and validation process of the overall system should ensure the correctness, completeness, accuracy, testability, and consistency of the system’s secure operational environment design feature and measures. 2.2.1.2.1 TXS Platform The TXS platform software verification and validation was reviewed and accepted by the NRC in the safety evaluation report for Topical Report, EMF-2110. As elaborated in Annex 2, SPM Appendix C, Section 3, the first development phase comprises the elaboration of a requirement specification or frame requirement specification according to the scope of the software component. During this phase all functional measures and boundary conditions to be met by the software component are stated and identified. The requirement specification phase is completed by a review, in which peer reviewers check whether the requirements are unambiguous, consistent, and complete. Based on the requirement specification, a design description or preliminary design description is elaborated. The design description phase is completed by a review that covers the internal consistency of the design description document and the transition from the requirements phase. The SDOE design features enumerated above in Section 2.2.1.1.1 of this report were implemented as part of the TXS platform design and have not been significantly changed to affect the conclusions made in the safety evaluation report for Topical Report, EMF-2110. Each design requirement must be precise and traceable to subsequent development phases. As such, the V&V requirements for the TXS platform have adequately addressed the criterion within Regulatory Position C.2.2.1 of RG 1.152, Revision 2 by providing design feature requirements intended to maintain a secure operating environment and ensure reliable system operation and having adequate V&V on these design requirements. 2.2.1.2.2 TXS-Specific Application Software SPM Appendix C, Section 6.2 the states that the independent V&V group performs a assessment activity that ensures the correctness, completeness, accuracy, testability, and consistency of the system SDOE design requirements for TXS-specific application software. In addition, Annex 2, SPM Appendix C, Section 5.0 states that the requirements phase comprises the elaboration of a TXS Application Software Requirements Specification (SRS) according to the project system and functional requirements. During this phase, all functional requirements and boundary conditions to be met by the project-specific TXS Application

- 45 -

Software are stated and identified. The independent V&V group performs the Software Requirements Phase Traceability Analysis to show forward and backward traceability among the requirements, design, implementation, and test documents. They also perform a Software Requirements Evaluation to verify that the Software Requirements Specification adequately defines the software requirements necessary to perform intended functions. The staff finds the description of the V&V process for the software requirements phase adequately ensures the correctness, completeness, accuracy, testability, and consistency of the TXS-specific application software SDOE design requirements. For a new application or amendment request, the staff will need to review the plant-specific documentation outlined in SRP BTP-7-14, Section B.2.2, “Software Life Cycle Process Implementation,” and BTP-7-14, Section B.2.3, “Software Life Cycle Process Design Outputs.” This review is necessary to ensure that the design and implementations of TXS-specific application software has conformed to independent V&V requirements per these criterion. It will also ensure that SDOE design requirements are part of the overall system requirements, and that adequate V&V has been performed on these design requirements within Regulatory Position C.2.2.1 of RG 1.152, Revision 2, as specified in ASAI 4.1. 2.2.1.3 Use of Pre-developed Software and Systems RG 1.152, Revision 2, Section 2.2.1 further states that requirements specifying the use of pre-developed software and systems (e.g., reuse software and commercial off-the-shelf systems (COTS)) should address the vulnerability of the safety system (e.g., by using pre-developed software functions that have been tested and are supported by operating experience). 2.2.1.3.1 TXS Platform As described in Topical Report, EMF-2110, the developer of the TXS platform did not use pre-developed or COTS software within the TXS safety system. All TXS system software used to develop the TXS platform was developed by AREVA NP. The staff finds that since the TXS platform does not use pre-developed or COTS software and that all software is specifically developed and controlled as defined in this SPM the criterion pertaining to the use of pre-developed software and COTS systems is not applicable to the TXS platform. 2.2.1.3.2 TXS-Specific Application Software SPM Appendix C, Section 6.2 [states that AREVA NP does not use COTS software in its TXS safety system]. All TXS System Software and development tools are purchased and received from AREVA NP GmbH. Each software package is developed utilizing the same processes described in Topical Report EMF-2110. The staff finds that since the SPM specifies that TXS-specific application software will not include any COTS software, the criterion pertaining to the use of pre-developed software and COTS is not applicable to TXS-specific application software.

- 46 -

2.2.2 Development Activities for the Requirements Phase Regulatory Position C.2.2.2 of RG 1.152, Revision 2 states, in part, that the development process should ensure the system does not contain undocumented code, and other unwanted and undocumented functions or applications. 2.2.2.1 TXS Platform As discussed above in Section 2.1.2.1 of this evaluation Annex 2, SPM Appendix C, Section 4.0 discusses possible vulnerabilities in the design process that may allow unintended modification to the TXS platform while under development during each phase of the development life cycle. This section also provides mitigation strategies implemented to prevent such unauthorized or unintended changes from occurring. [For the requirements phase, the applicant identified unauthorized changes of the requirements in the requirements specification phase as a potential vulnerability.] To mitigate vulnerabilities in the requirements phase, the Annex 2, SPM Appendix C, Section 4.1 provides a description of methods used to detect unauthorized changes to the system under development. [This section states that requirements are checked by at least one internal reviewer and by one independent assessor (as a part of qualification). As such, unauthorized modifications of requirements specifications would be detected and corrected. The peer review ensures that requirements for support of unneeded functionality are precluded from the TXS requirement specification.] The staff finds the measures identified in Annex 2, SPM Appendix C, Section 4.1 adequate to prevent inadvertent, unintended, or unauthorized modifications to the system during the requirements phase to address Regulatory Position C.2.2.2 of RG 1.152, Revision 2. Specifically, the staff finds the verification activities completed by the internal reviewer, and independent assessor, are sufficient to identify and mitigate any unauthorized modifications of the TXS platform requirements specifications. 2.2.2.2 TXS-Specific Application Software As discussed above in Section 2.1.2.2 of this report, Annex 2, SPM Appendix C, Section 6.0 discusses possible vulnerabilities in the design process that may allow unintended modification to the application software while under development during each phase of the development life cycle. This section also provides mitigation strategies implemented to prevent such unauthorized or unintended changes from occurring. [For the requirements phase, the applicant identified “unauthorized changes of the requirements” in the TXS application software requirements specification phase as a potential vulnerability.] To mitigate this vulnerability, Annex 2, SPM Appendix C, Section 6.1 provides a description of methods used to detect unauthorized changes to the system under development. This section states that the SRS is checked by at least one independent reviewer and by the independent V&V group. [Thus, the insertion of undetected requirements introducing vulnerability would be detected and corrected. The independent review assures that the software and secure development and operational environment requirements are correctly included and unauthorized functionality is not included.] The staff finds the measures identified in Annex 2, SPM Appendix C, Section 6.1 are adequate to prevent inadvertent, unintended, or unauthorized modifications to the TXS application software during the requirements phase to address Regulatory Position C.2.2.2 of RG 1.152, Revision 2. Specifically, the staff finds the verification activities performed by the independent

- 47 -

reviewer and V&V group are sufficient to identify and mitigate any unauthorized modifications of the TXS-specific application requirements specifications. 2.3 Design Phase 2.3.1 System Features 2.3.1.1 Secure Operating Environment Design Configuration items Regulatory Position C.2.3.1 of RG 1.152, Revision 2 states that the safety system secure operational environment design features identified in the system requirements specification should be translated into specific design configuration items in the system design description. The safety system secure operational environment design configuration items should address control over: 1) physical and logical access to the system functions

2) use of safety system services

3) data communication with other systems Design configuration items incorporating pre-developed software into the safety system should address how the pre-developed software will not challenge the secure operational environment for the safety system. In this phase, the safety system secure operational environment design requirements stated in Section 2.2.2 of this report are translated into design configuration items. 2.3.1.1.1 TXS Platform SPM Appendix C, Section C.4 provides a summary of the secure operational environment design configuration items that were implemented in the design of the TXS platform hardware and software. These design configuration items include: • Strict cyclic data transfer, using predefined messages with fixed package size and a

constant bus load, with checksum and message age monitoring.

• Strict cyclic processing between the TXS Gateway computer (safety side) and the TXS processors, via the MSI.

• TXS Gateway communication is designed with static memory structure using a linear, dual port memory software interface. Asynchronous communication between safety-portion and non-safety-portion of the TXS gateway.

• Integrity checks of the code installed on the Flash-Erasable Programmable Read-Only Memory (FEPROM) TXS processors to ensure damaged code is promptly identified and isolated

[

- 48 -

]

• Servicing of the safety system is performed only from the custom configured TXS Service Unit via the MSI with controlled access measures.

• Use of MSI to provide logical data isolation between TXS Service Unit and safety system processors and to ensure communications independence between the safety system and non-safety systems.

• Physical separation, electrical isolation, and communication independence between TXS system processors and external interfaces.

• [Logical access provided by use of login and passwords with capability to segregate access for personnel with different privilege levels assigned.

• Use of key switches, special cables with connectors, connector with a special enable pushbutton etc., to provide additional features to secure the operational environment with devices which can enable changes to the safety system.

• The TXS-platform does not include any pre-developed or COTS software.] The staff finds the secure operational environment design configuration items included in the TXS system design provide physical and logical access to the TXS system and control of TXS system services adequate to address t Regulatory Position C.2.3.1 of RG 1.152, Revision 2. The design configuration items ensure that only authorized personnel can gain access to the TXS platform within the operational environment, thus preventing any unintended and unauthorized modifications to the TXS system. For example, the logical access provided through the use of login and passwords prevents unauthorized users from accessing the service unit, and thus eliminates a pathway for unintended or unauthorized modifications to the TXS safety system. Data communication with other systems will be reviewed during the design and implementation of TXS-specific application software. 2.3.1.1.2 TXS-Specific Application Software SPM Appendix C, Section C.6.3 states that the design phase of a TXS project will address the specific design features which include the project-specific software and secure operational environment design requirements for access control, key switches, control room alarms, TXS equipment location, and TXS gateway interfaces. The TXS-application software will not include any pre-developed or COTS software. All software used for implementation is specifically developed for the TXS-specific application software The staff will need to review the design and implementation of TXS-specific application software to ensure that the application software provides adequate secure operational environment design configuration items to complement the secure operational environment design features in the TXS system software. This is ASAI 4.11. In addition, although the applicant committed to providing physical access control on cabinets and logical access control on the system, an applicant or licensee referencing the SPM will have to address the implementation of these controls during the installation, operations/maintenance, and retirement phase of the system lifecycle, as specified in ASAI 4.09.

- 49 -

2.3.2 Development Activities for the Design Phase Regulatory Position C.2.3.2 of RG 1.152, Revision 2 states that the developer should delineate the standards and procedures that will conform with the applicable design controls to ensure that the system design products (hardware and software) do not contain undocumented code, unwanted functions or applications, and any other coding that could adversely impact the reliable operation of the digital safety system. As discussed in Section 2.1.2 of this report, Annex 2, SPM Appendix C, Sections 4.0 and 6.0 identified that the key vulnerability to the design phase of both the TXS platform and TXS-specific application software development was unauthorized modifications to the preliminary or detailed design description documentation. If the developer’s procedures do not properly control the design process, the opportunity exists for unauthorized inclusion of additional features and/or the omission of intended features. The actions taken by the software developer to prevent unauthorized or unintended changes to the design are described below. 2.3.2.1 TXS Platform Based on the requirement specification, a design description or preliminary design description is elaborated according to the TXS Software Design Descriptions engineering procedure. A design description introduces design entities, design attributes, and the main implementation entities. Annex 2, SPM Appendix C, Section 4.2 describes the strategies used during the development process to prevent unauthorized and unintended changes to the design descriptions. [ ] Based on the design controls in place during the TXS System development process, the staff concludes that the developer’s procedures and processes for the TXS system are adequate to protect the design phase of the TXS system life cycle from unauthorized and unintended modifications, and to preclude undocumented code and other unwanted or undocumented functions, and has met Regulatory Position C.2.3.2 of RG1.152, Revision 2. Specifically, the staff finds the verification activities performed by the third party assessor are sufficient to identify vulnerabilities in the software code and to trace the software code to the requirements specifications. This ensures that undocumented or unwanted code is identified and mitigated. 2.3.2.2 TXS-Specific Application Software Annex 2, SPM Appendix C, Section 6.2 describes the strategies used during the development process to prevent unauthorized and unintended changes to the design descriptions. [

- 50 -

] Based on the design controls that will be applied to the development of the TXS-specific application development process, and the AREVA NP internal independent V&V process, as described above, the staff concludes that the TXS application software developer’s procedures and processes are adequate to protect the design phase of the TXS-specific application software lifecycle from unauthorized and unintended modifications, and to preclude undocumented code and other unwanted or undocumented functions, and has met Regulatory Position C.2.3.2 of RG 1.152, Revision 2. Specifically, the staff finds the verification activities performed by the independent V&V group are sufficient to identify vulnerabilities in the application software code and to trace the software code to the requirements specifications. This ensures that undocumented or unwanted code is identified and mitigated and that the intended functionality of the secure operational environment design features is properly verified. Based on the design controls that will be applied to the development of the TXS-specific application development process, and the AREVA NP internal independent V&V process, the staff concludes that the TXS application software developer’s procedures and processes will adequately protected the design phase of the TXS-specific application software lifecycle from unauthorized and unintended modifications, and to preclude undocumented code and other unwanted or undocumented functions, and has met Regulatory Position C.2.3.2 of RG 1.152, Revision 2. 2.4 Implementation Phase Regulatory Position C.2.4 of RG 1.152, Revision 2 states that the system design is transformed into code, database structures, and related machine executable representations during the implementation phase of the development life cycle. The implementation activity addresses hardware configuration and setup; software coding and testing; and communication configuration and setup. 2.4.1 System Features Regulatory Position C.2.4.1 of RG 1.152, Revision 2 states that the developer should ensure that the transformation of the secure operational environment design configuration items from the system design specification is correct, accurate, and complete. 2.4.1.1 TXS Platform SPM Appendix C, Section C.6.4 states that the highly deterministic behavior of the TXS System was a key development target for the TXS platform. Another information element in the development of the TXS System was a high quality development process. The development process for the qualified components of the TXS System platform included comprehensive V&V activities by the manufacturer, as well as by an external third party appraisal of the development and test results by the following test institutes:

- 51 -

German Reactor Safety Association (GRS), Institute for Safety Technology (ISTec), and Technischer Überwachungsverein (TÜV). The development process for the qualified components of the TXS System platform included comprehensive V&V activities by the manufacturer, as well as by an external third party appraisal of the development and test results by test institutes (GRS, ISTec, and TÜV). The V&V activities which are performed during development comprise: • Reviews of the development documentation and test specifications.

• Module tests of the vital software components: All possible branches within the function to be tested are executed in this process. The major part of the functionality of the software can be verified with this test. For software modifications, testing included a regression test and a test of the implemented modifications.

• Code inspections: A code inspection of the complete source code. For minor software modifications, these code inspections may be limited to the modified sections of the code.

• Functional tests of the software components: Component test are performed for all modified software components.

The modified software modules were subjected to an external, third party, qualification test by GRS, ISTec, and/or TÜV. The type test program was based on the following standards: • German Nuclear Safety Standards Commission (KTA) 3503, “Type Testing of Electrical

Modules of the Reactor Protection System,” November 1986. • International Electrotechnical Commission (IEC) 60880,”Software for Safety Systems in

Nuclear Power Stations,” 1986. A qualification certificate was issued by the test institute for each qualified software module demonstrating that the module was qualified by test to the specified requirements. The safety evaluation report for the Topical Report EMF-2110 evaluated the acceptability of the use of these safety standards for qualification of the TXS platform. This safety evaluation states that the (TXS) equipment qualification was performed through type testing according to German safety standards which were compared by the staff against the U.S. nuclear industry equipment qualification standards. Except for minor deviations between German and U.S. standards, the equipment qualification design was considered acceptable. Based on the above description of the design controls and the third party V&V process in place during the development of the TXS System, and the conclusions made in the safety evaluation for the TXS platform in Topical Report, EMF-2110, the staff finds that the developer has adequately ensured that the secure operational environment design configuration item transformations from the system design specification are correct, accurate, and complete to address Regulatory Position C.2.4.1 of RG 1.152, Revision 2. Specifically, the staff finds the software testing completed as part of the qualification of the TXS platform software is adequate to ensure that the design requirements have been correctly and completely implemented.

- 52 -

2.4.1.2 TXS-Specific Application Software SPM Appendix C, Section C.6.4 states that the use of the SPACE Engineering Tool to develop the project-specific application software is mandatory. The SPACE Engineering Tool Code Generator tools have been designed and qualified for the creation of safety application software (ANSI C source code). They include a variety of checks of the specification data and follow strict design rules for the generated code that meet IEC 60880 stipulations. In the SE for Topical Report EMF-2110, the staff found IEC 880-1986 standard to be acceptable. In the SPM, AREVA NP references IEC 880-1986 as IEC 60880-1986 as applied in that topical report. The naming convention for such standards has changed, however, and a new version of IEC 880-1986, which the NRC has not reviewed, is now designated as IEC 60880. In the SPM Topical Report, AREVA NP references IEC 880-1986 as IEC 60880-1986. It is nonetheless clear, in the context of the SPM Topical Report that AREVA NP is continuing to reference IEC-880-1986. The project-specific application software has to be generated entirely by means of these tools in order to ensure that all design rules and interfaces defined for TXS-specific application software functions are met. The use of the SPACE Engineering Tool eliminates the direct human interface with the application software source code. The implementation phase of a TXS project addresses the specific activities which translate the project-specific software and data secure operational environment design requirements for access control, key switches, control room alarms, TXS equipment location, and TXS Gateway interfaces into the project-specific hardware and application software. The AREVA NP internal independent V&V group verifies that the secure operational environment design requirements have been effectively implemented in the project-specific hardware and application software. The staff reviewed and approved the SPACE Engineering Tool as part of the evaluation completed for Topical Report, EMF-2110. Specifically, the safety evaluation report for this topical report states that the staff determined that the SPACE tool for designing and assembling safety-related applications has the capability and safeguards to ensure that the implementation of the application programs can be successfully accomplished on a plant-specific basis. Based on the evaluation of the SPACE tool in the SE on Topical Report EMF-2110, the staff finds the use of the SPACE tool adequate to ensure that the function block code adequately translates to safety application software (i.e., ANSI C source code). In addition, the staff finds the description of how the AREVA NP internal independent V&V process will verify the effective implementation of secure operational environment design requirements is adequate. This V&V process ensures that the transformation of these design configuration items from the system design specification are correct, accurate, and complete. However, applicants or licensees are to make available for audit/inspection, the output of the design and implementation of TXS-specific application software to verify that the transformation of secure operational environment design configuration items from the application software design specification are correct, accurate, and complete to address Regulatory Position C.2.4.1 of RG 1.152, Revision 2. This is ASAI 4.11. 2.4.2 Development Activities During Implementation Phase Regulatory Position C.2.4.2 of RG 1.152, Revision 2 states that the developer should implement SDOE procedures and standards to minimize and mitigate unauthorized or inadvertent modification to the developed system. The developer’s standards and procedures should include testing as appropriate, to address undocumented functions that might (1) allow unauthorized access or use of the system or (2) cause systems to behave other than as described in the TXS system requirements or in an unreliable manner. The developer should

- 53 -

account for hidden functions and vulnerable features embedded in the code, and their purpose and impact on the safety system. 2.4.2.1 TXS Platform The TXS platform was developed at the AREVA NP GmbH’s facility in Germany. SPM Appendix C, Section C.5.1 states that the TXS platform software development environment had physical and logical secure development environment features in place to prevent unauthorized access during the implementation phase. AREVA NP GmbH procedure FAW-1.7 (“Information Security”) was used for establishing secure development environment controls over the TXS platform implementation environment. The procedure controls in effect during the original design of the TXS System Software and Function Block library included the provisions for protecting the development networks and tools. [ •

•

•

•

•

•

• ] The information security measures have expanded since the submission of the Topical Report, EMF-2110. The information security measures in place at that time were described in Engineering Procedure FAW-1.7 were applicable to TXS activities. The information security measures for AREVA NP GmbH have been expanded to encompass all business activities. An AREVA NP GmbH corporate-wide procedure on information technology security incorporated all of the measures from FAW 1.7 and superseded that procedure. The procedure controls currently in effect for the TXS System Software and Function Block library include additional access control measures to provide a secure software development infrastructure. During a March 10 - 14, 2008, NRC inspection, the staff reviewed “security aspects during the development of the TXS operating system software and function block library software to determine whether AREVA NP has a secure software development infrastructure.” The aforementioned vendor corporate information security procedure (which superseded Engineering Procedure FAW 1.7) was reviewed. The procedure review included interviews with vendor staff. The inspectors reviewed information regarding “isolation of the development computers/network from the corporate network, access control and access rights to particular development computers, process for using purchased software, and physical access restrictions

- 54 -

to the development lab.” The inspection also verified implementation of secure development environment measures during a tour of the TXS platform development lab. The NRC inspection staff concluded that there were “no issues associated with the security controls used for the development of TXS software.” (Ref. 1) In addition to the protection of the development environment and development tools, Annex 2, SPM Appendix C, Section 3.0 describes additional configuration management controls to ensure that the TXS system software is developed with good coding practices. This includes adherence to a coding style guide as defined by the TXS Software Programming Guidelines engineering procedure to develop the source code. In addition, the source code and objects derived from the source code are administered with a Software Configuration Management (SCM) system. Access to the SCM is restricted to the software developers, and modifications to the files or directories are tracked. As was stated in Section 2.1.2 of this evaluation, the Annex 2, SPM Appendix C, Section 4.0 identified several vulnerabilities to the implementation phase of the TXS platform system development. [ • • • • • ] Annex 2, SPM Appendix C, Section 4 provides strategies employed during the development process to mitigate these vulnerabilities. These mitigation strategies are summarized below. [

- 55 -

] Based on the design controls and the V&V process in place during the TXS System development, the staff concludes that the TXS System developer’s procedures and processes are adequate to protect the implementation phase of the TXS system life cycle from unauthorized and unintended modifications to the development environment and to the TXS system under development, and have met the criterion in RG 1.152, Revision 2, Section 2.4.2. Specifically, the staff finds that the processes and procedures implemented at the AREVA NP GmbH facility for the development of the TXS platform prevent unauthorized access or use of the TXS system and preclude the system from behaving other than as described in the TXS system requirements. 2.4.2.2 TXS-Specific Application The implementation phase of the TXS Application Software Code includes engineering, generation, and download steps. The TXS source code is captured in function block diagrams that are associated with the SPACE development tool. Annex 2, SPM Appendix C, Section 5.0 states that the design documented in the SDD is implemented in the Engineering Database using the SPACE Engineering Tool and associated Function Block Library. The application

- 56 -

code is checked by a visual check of SPACE diagrams by an independent reviewer and engineering checks of the functionality in the simulation test environment. The C source code is generated and compiled using the SPACE Engineering Tool Code Generators in accordance with the project Software Generation and Download Procedure. The independent V&V group performs the Software Implementation Phase Traceability Analysis to show forward and backward traceability between the application software code (SPACE Function Diagrams) and the SDD. They also perform the Source Code and Source Code Documentation Evaluation to ensure that the software design is correctly translated into the Application Software Code. The TXS application software code and objects derived from the source code are administered in accordance with the Software Library and Control procedure. Access to the Software Library is restricted to software developers. The creation and modification of any files or directories are tracked. The TXS Application Software documentation is created, reviewed, and released in the Records Management System of AREVA NP. The documentation includes the Code Configuration Documents identifying the TXS Application Software Releases. Only read-only access is provided for released documents, even to the document owner. As was stated in Section 2.1.2 of this evaluation, the Annex 2, SPM Appendix C, Section 6.0 identified several vulnerabilities to the implementation phase of the TXS-Specific application software development. [ • • • • • • ] Additionally, Annex 2, SPM Appendix C, Section 6 also provides strategies employed during the development process to mitigate these vulnerabilities. These mitigation strategies are summarized below. [

- 57 -

- 58 -

] Based on the design controls and V&V process that will be applied during the TXS-specific application software development process, the staff concludes that the TXS-specific application developer’s procedures and processes are adequate, as described above, to protect the implementation phase of the TXS system life cycle from unauthorized and unintended modifications to the development environment, including the development tools, and to the TXS application software under development, and have met the criterion in RG1.152, Revision 2, Section 2.4.2. 2.5 Test Phase RG 1.152, Revision 2, Section 2.5 states that the objective of testing secure operational environment design features is to ensure that the system design requirements intended to ensure system reliability are validated by the execution of integration, system, and acceptance tests where practical and necessary. Testing includes system hardware configuration (including all connectivity to other systems, including external systems), software integration testing,

- 59 -

software qualification testing, system integration testing, system qualification testing, and system factory acceptance testing. 2.5.1 System Features 2.5.1.1 TXS Platform Integration and System Test were performed on the generic TXS System by ISTec and TÜV as part of the independent qualification process. SPM Appendix C, Section C.6.5 states that the following system characteristics relevant to the software and secure operational environment features were confirmed during the external qualification testing: • Processing and communication cycle times are not influenced by external process states

(measured signals, amount of alarms and monitored information).

• Mutually independent I&C functions are processed as specified according to their chronological order and their input signals.

• Mutually independent processing units do not affect each other regarding their operating modes and their time behavior. Processing units which exchange signals but are otherwise mutually independent have effects only on each other's time response within the limits of the engineered communication functions.

• Interference on cables with violation of the measuring range and input module failures are detected, marked as signal failures, and indicated. Signals detected as faulty are processed and indicated by the system components (RunTime Environment, I/O drivers, and function blocks) as defined in the specification.

• Transmission failures on TXS Ethernet (H1) and TXS Profibus (L2) busses are detected, processed, and indicated in accordance with the specification. Single message failures are tolerated by the system. Furthermore, on TXS Ethernet (H1) busses double message failures are tolerated.

• Sending and receiving processing units execute their functions asynchronously if no "expedited messages" are sent via serial bus links, with the exception of voter subunits monitoring each other. Note 3 in the SPM provides a description of expedited messages. These messages are only used when the modules are configured in a master-checker voting configuration, as described in Topical Report EMF-2110(NP)(A), “TELEPERM XS: A Digital Reactor Protection System,” Revision 1, Section 2.7.1.2.3. The NRC Safety Evaluation Report (SER) for EMF-2110(NP)(A), Section 2.1 notes that the master-checker synchronization is accomplished through the use of the K32 backplane bus interrupt (IRE). This interrupt is generated on a checker processor in order to start the current processing cycle of the checker. It is initiated by the master processor in conjunction with sending a trigger to the checker at the beginning of each processing cycle. The IRE interrupt is the means for controlling the necessarily synchronized processing cycles of a master/checker pair. The IRE interrupt is also used by the SVEx processor to trigger the protocol handler on the SCPx communication to send the new message out, as described in Section 2.9.3 of EMF-2110(NP)(A). The IRE interrupt is represented by the control flow line shown between the SVE1 and SCP2 processor in Topical Report EMF-2110(NP)(A), Figure 2.20. The IRE interrupt used to

- 60 -

trigger the checker processor is the expedited message discussed in Topical Report ANP-10272. The SER for Topical Report EMF-2110(NP)(A) states that the IRE interrupt is a hardware interrupt and that all hardware interrupts have been designed for strictly deterministic behavior. Thus, the SER for Topical Report EMF-2110 found the TXS design principle ensures that the sequence of processing executed for each expected situation can be deterministically established.

• Lost messages are treated like transmission errors.

• Single failures of active and passive hardware modules are detected and indicated corresponding to the implemented monitoring mechanisms (self-monitoring, monitoring of the communication, cabinet annunciation system).

• Fault propagation barriers are effective provided that no plant-specific fault suppression measures are engineered (for example status correction). Signal status is changed by the RunTime Environment as specified.

• The RunTime Environment behaves in the operating modes start-up, operation, parameterization, functional test, and diagnosis as specified. It changes between operating modes according to the specification.

• The RunTime Environment can be controlled by means of service requests.

• The user software can be loaded from a centralized unit using the network connections. This function can be deactivated by a hardware switch on the processing modules.

• Fail-safe behavior: Signals marked as faulty (ERROR and/or TEST status) are issued as 0 signals via output modules.

On completion of the external qualification test, a test certificate was issued by the independent expert for each qualified software component and a test report was written. The test certificate documents that the TXS System met the criteria listed above. In addition, AREVA NP GmbH performed fault injection testing on the TXS MSI to demonstrate that is an effective barrier from unauthorized data access from outside the inner security zone. Specifically, the test results showed that in the case of bidirectional exchange of data messages between the TXS Gateway and MSI, message interchange within the inner security zone cannot be affected by manipulation on the XS Gateways or communication links of the outer security zone. Additionally, the test results also showed that the MSI acts as an effective barrier to filter spurious messaging from the TXS Service Unit. The testing also demonstrates that the MSI in conjunction with the other TXS access control features (i.e., mode change release requirements and alarms) ensures that the TXS System provides access controls sufficient to prevent unauthorized modifications to the TXS system Based on the validation of system secure operational environment features during the integration and system testing of the TXS platform, the staff concludes that the TXS platform secure operational environment features meet the criteria of RG 1.152, Revision 2, Section C.2.5.1. This is supported by additional testing of the TXS MSI that demonstrates that the MSI is an effective barrier to unauthorized data access from outside the inner protected zone.

- 61 -

2.5.1.2 TXS-Specific Application Software SPM Appendix C, Section C.6.5 states that the test phase of a TXS project will validate that specific system and software design measures for access control, key switches, control room alarms, TXS XS equipment location, and TXS Gateway interfaces were properly implemented in the TXS System. In addition, the project-specific TXS system and acceptance tests are designed will validate the correct functionality of the integrated system. This integrated system includes: • User Interfaces • Hardware Interfaces • Software Interfaces • Communications Interfaces The testing methodology ensures that the software and secure operational environment measures and features have been designed and implemented correctly, including but not limited to external hardware connections (e.g., keys switches and alarms) and external communication pathways (e.g., TXS Gateway), and physical location of the system. The staff finds the applicant’s commitments to perform project-specific TXS system integration and acceptance testing in which TXS projects will validate specific system and software design measures for access control, key switches, physical location, and other secure operational environment features to be adequate. However, for new applications or license amendment the staff will need to review the results of these system and acceptance tests to fully address Regulatory Position C.2.5.1 of RG 1.152, Revision 2. This is ASAI 4.12. 2.5.2 Development Activities Regulatory Position C.2.5.2 of RG 1.152, Revision 2 specifies that the developer should configure and enable the secure operational environment design features correctly. The developer should also test the system hardware architecture, external communication devices, and configurations for unauthorized pathways and system integrity. Attention should be focused on built-in original equipment manufacturer features. 2.5.2.1 TXS Platform The TXS system module, component, and integration testing validates that the TXS system secure operational environment design features have been configured correctly. In addition, the external qualification tests provide independent validation of these design features as described above in Section 2.5.1 of this report. In addition, as was stated in Section 2.1.2 of this report, the Annex 2, SPM Appendix C, Section 4.0 identified several vulnerabilities to the test phase of the TXS system software development. [ • • • •

- 62 -

• ] Annex 2, SPM Appendix C, Section 4 provides strategies employed during the development process to mitigate these vulnerabilities. [ ]

- 63 -

Based upon the standards and procedures in place for the testing phase of the TXS platform and the scope of the testing for the TXS platform, as described above, including testing the hardware, software, and communications features, the staff finds that the applicant has adequately addressed Regulatory Position C.2.5.2 of RG 1.152, Revision 2. 2.5.2.2 TXS-Specific Application Software As stated above in Section 2.5.1 of this evaluation, the project-specific TXS system and acceptance tests are designed to validate the correct functionality of the integrated system. This integrated system includes: • User Interfaces • Hardware Interfaces • Software Interfaces • Communications Interfaces The testing methodology ensures that the software and secure operational environment measures and features have been designed and implemented correctly, including but not limited to external hardware connections and external communication pathways. In addition, as stated in Section 2.1.2 of this evaluation, Annex 2, SPM Appendix C, Section 4.0 identified several vulnerabilities to the test phase of the TXS application software development. [ • • ] Annex 2, SPM Appendix C, Section 4 provides strategies employed during the development process to mitigate these vulnerabilities. [ ] Based on the process and procedures that will be in place during the testing phase of the TXS application software and the scope of the testing for the TXS application, including testing the hardware, software, and communications interfaces, the staff finds that the applicant will adequately protect the TXS application software from unauthorized and inadvertent

- 64 -

modifications during the testing phase. However, as stated in Section 2.5.1 of this report, the staff will need to review the results of these system and acceptance tests to fully address Regulatory Position C.2.5.2 of RG 1.152, Revision 2. 3.0 Compliance with Regulations 10 CFR Part 50, Appendix A, GDC 21 requires, among other things, that protection systems (or safety systems) must be designed for high functional reliability commensurate with the safety functions to be performed. 10 CFR Part 50, Appendix B, Criterion III, requires, among other things, that quality standards must be specified and design control measures must be provided for verifying or checking the adequacy of design. 10 CFR 50.55a(h) requires that safety systems for nuclear power plants must meet the requirements stated in IEEE Std 603-1991, “Criteria for Safety Systems for Nuclear Power Generating Stations.” IEEE Std 603-1991, Clause 5.6.3 requires safety systems to be designed such that credible failures in and consequential actions by other systems will not prevent safety systems from performing their intended safety functions. In addition, IEEE Std 603-1991, Clause 5.9 requires the design to permit the administrative control of access to safety system equipment. These administrative controls shall be supported by provisions within the safety systems, by provision in the generating station design, or by a combination thereof. RG 1.152, Revision 2 provides a method that the NRC finds acceptable for complying with Commission regulations (i.e., 10 CFR Part 50, Appendix A, GDC 21, 10 CFR Part 50, Appendix B, Criterion III, and IEEE Std 603-1991, Clauses 5.6.3 and 5.9) for promoting high functional reliability, design quality, and a secure development and operational environment for use of digital computers in safety systems of nuclear power plants. SDOE in this context refers to protective actions taken against a predictable set of non-malicious acts (e.g., inadvertent operator actions, undesirable behavior of connected systems) that could challenge the integrity, reliability, or functionality of a digital safety system. Based on the satisfactory regulatory findings associated with the criteria in Regulatory Positions C.2.1 through C.2.5 of RG 1.152, Revision 2, as described above, the staff concludes that the applicant has met the requirements of 10 CFR Part 50, Appendix A, GDC 21, 10 CFR Part 50, Appendix B, Criterion III, and IEEE Std 603-1991, Clauses 5.6.3 and 5.9, as they relate to a SDOE and reliability of the TXS platform and TXS-specific application software. Additional application specific action items necessary to verify the design and implementation of the TXS project specific application software are summarized in Section 4.0 of this evaluation’s main body. Reference • Juan Peralta, U.S. Nuclear Regulatory Commission, Memorandum to Han-Joachim

Nisslein, QEM Liaison Officer, AREVA-NP GmbH, “NRC INSPECTION REPORT FOR AREVA-NP GmbH 99901371/2008-201, NOTICE OF VIOLATION, AND NOTICE OF NONCONFORMANCE,” May 7, 2008 (ADAMS Accession No. ML081190190).