ML081430003

License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2007-09, Supplement 3

ML081430003
Person / Time
Site:	Oconee
Issue date:	05/15/2008
From:	Baxter D Duke Energy Corp
To:	Document Control Desk, Office of Nuclear Reactor Regulation
References
Download: ML081430003 (19)

Text

DAVE BAXTER Vice President SEnergy.

Oconee Nuclear Station Duke Energy Corporation ON01 VP17800 Rochester Highway Seneca, SC 29672 864-885-4460 864-885-4208 fax dabaxter@dukeenergy. corn May 15, 2008 U. S. Nuclear Regulatory Commission Washington, D. C. 20555 Attention: Document Control Desk

Subject:

Duke Energy Carolinas, LLC Oconee Nuclear Station, Units 1, 2, and 3 Docket Numbers 50-269, 50-270, and 50-287 License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2007-09, Supplement 3 On January 31, 2008, Duke Energy Carolinas, LLC (Duke) submitted a License Amendment Request (LAR) to address replacement of the existing Oconee Nuclear Station (ONS) analog based Reactor Protective System (RPS) and Engineered Safeguards Protective System (ESPS) with a digital computer based RPS/ESPS. By letter dated April 24, 2008, the Nuclear Regulatory Commission (NRC) requested Duke to provide additional information associated with five issues.

Issue 4 stated that the LAR did not contain enough information to make a determination of acceptability of TELEPERM XS(TXS) system hardware, software, and procedure changes that have occurred since issuance of the approved TXS Topical Report and completion of the Oconee digital platform design.

Duke reviewed and evaluated the NRC Safety Evaluation (SE) for the AREVA TXS Topical Report and concluded that sufficient information on TXS system hardware, software and procedure changes was included in the LAR and other correspondence to address the conditions of the SE. The basis for this conclusion is as follows:

1) The SE for the TXS Topical Report approved the TXS design principles and development method;

2) NRC reviewed and audited the TXS configuration management and design change process during the Topical Report review; www.duke-energy cornm LO

U. S. Nuclear Regulatory Commission May 15, 2008 Page 2

3) There were no findings identified during a recent NRC inspection of the TXS Configuration Management and Design Change Process, and

4) The documents included with the LAR contain necessary information to evaluate TXS system changes.

Additional information on this rationale is provided in the Enclosure to further the NRC's understanding of Duke's position.

If there are any questions regarding this submittal, please contact Boyd Shingleton at (864) 885-4716.

Very truly yours, Dave Baxter, Vice President Oconee Nuclear Station

Enclosure:

Duke Response to Issue 4

U. S. Nuclear Regulatory Commission May 15, 2008 Page 3 cc:

Mvr. L. N. Gishan, Project Manager Office of Nuclear Reactor Regulation U. S.- Nuclear Regulatory Commission Mail Stop 0-14 H25 Washington, D. C. 20555 Mr. L. A. Reyes, Regional Administrator U. S. Nuclear Regulatory Commission - Region HI Atlanta Federal Center 61 Forsyth St., SW, Suite 23T85 Atlanta, Georgia 30303 Mr. Andy Hutto Senior Resident Inspector Oconee Nuclear Station S. E. Jenkins, Manager Division of Radioactive Waste Management Bureau of Land and Waste Management Department of Health and Environmental Control 2600 Bull Street Columbia, SC 29201

U. S. Nuclear Regulatory Commission May 15, 2008 Page 4 Mr. Dave Baxter affirms that he is the person who subscribed his name to the foregoing statement, and that all the matters and facts set forth herein are true and correct to the best of his knowledge.

Dave Baxter, ice President Oconee Nuclear Site Subscribed and sworn to me:

ýA C244 Date I 5~ 2e~c'7 Notary Public My Commission Expires:.

6?

Date /

SEAL

U. S. Nuclear Regulatory Commission May 15, 2008 Page 5 bcc:

w/enclosure R. W. Cornett B. R. Loftis B. M. Thomas J. L. Abbott B. G. Davenport J. E. Burchfield C. E. Curry L. F. Vaughn P. M. Stovall D. B. Coyle E. L. Anderson R. L. Gill - NRI&A R. D. Hart - CNS K. L. Ashe - MNS R. V. Gambrell D. C. Richardson M. E. Bailey NSRB, EC05N ELL, ECO50 File - T.S. Working BWOG Tech Spec Committee (5)

ONS Document Management

TSC 2007-09, Supplement 3 May 15, 2008 Page I Enclosure NRC Issue 4 In the LAR, Section 2.7 of Enclosure 1 identifies various TXS system hardware, software, and development procedure changes. Those changes are listed and explained in Tables 2-3, 2-4, and 2-5. The differences are between the approved TXS topical report and the Oconee digital platform design. The LAR does not contain enough information for the staff to reach a determination of the acceptability of these deviations. Therefore the staff needs information to make an acceptability determination.

LIC-101 provides framework for processing license amendment (and other licensing actions, where applicable) and states: "If a licensee in their application or the NRC staff during its review identifies a deviation from the process or limitations associated with a topical report, the staff should address the deviation in its SE for the plant-specific license amendment application. To address deviations from approved topical reports, the SE for the subject amendment should identify the limitation or condition, evaluate the proposed deviation against appropriate regulatory criteria, and specifically explain why the deviation is acceptable (or not acceptable)"

Response to NRC Issue 4:

Background

Duke included Section 2.7 of Enclosure 1 to the LAR' in consideration, of a specific request by NRC staff. During meetings and telephone conversations held in 2006 and 2007 between Duke and NRC staff to determine what needed to be included in the LAR, NRC staff requested Duke identify the differences between the TELEPERM XS (TXS) System that existed at the time of the Safety Evaluation (SE) for the Topical Report and the TXS System to be installed at Oconee.

The TXS platform, design principles, configuration management and design change process were approved by the NRC in the Safety Evaluation (SE)2 for the Topical Report. Changes made since then were made using the approved configuration management and design change process.

As such, Duke does not consider the differences listed in Section 2.7 as deviations from the approved TXS Topical Report. Rather, these differences are a result of changes made to take advantage of advancements in technology and increased processing power that have occurred since the TXS Topical Report was approved. Duke evaluated and addressed these differences as part of the Duke design change process for the RPS/ESPS modification and performed the actions required by the SE for an applicant when requesting NRC approval of installation of a TXS System listed in Section 6.0 of the SE. In the LAR, Duke provided the information addressing the applicable plant specific action items of Section.6.0 as indicated in Table 1-1 of.

1

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 Introduction Issue 4 indicates that the LAR does not contain enough information to make a determination of acceptability of TXS system hardware, software, and procedure changes that have occurred since issuance of the approved TXS Topical Report and completion of the Oconee digital platform design. NRC staff has requested Duke to provide additional information to allow it to make an acceptability determination.

Duke reviewed and evaluated the NRC Safety Evaluation (SE) for the AREVA TXS Topical Report and concluded that sufficient information on TXS system hardware, software and procedure changes was included in the LAR and other correspondence to address the conditions of the SE. The basis for this conclusion is as follows:

1) The SE for the TXS Topical Report approved the TXS design principles and development method;

2) NRC reviewed and audited the TXS configuration management and design change process during the Topical Report review;

3) There were no findings identified during a recent NRC inspection of the TXS Configuration Management and Design Change Process;

4) The documents included with the LAR contain necessary information to evaluate TXS system changes; and

5) The key TXS development process changes described below.

Additional information on this rationale is provided below to further the NRC's understanding of Duke's position.

1. The SE for the TXS Topical Report approved the TXS design principles and development method The TXS SE states that the Topical Report was focused on the design processes under which the TXS hardware and software are produced, tested, and qualified. The SE for the TXS Topical Report approves the TXS design principles and development methods. These TXS design principles and methods are explicitly described throughout the SE for the TXS topical report. Specifically; 2

Enclosure TSC 2007-09, Supplement 3 May 15, 2008

• Use of the four system building blocks Pages 1 and 2 of the SE identify the "TXS system architecture basic building blocks" as follows:

1. System hardware - The TXS selected hardware platform uses a processing computer module, which includes random access memory for the execution of programs; flash erasable programmable read only memory for storing program code; and electrical erasable programmable read only memory for storing application program, data.

2. System software - The TXS consists of a set of quality-controlled software components. The execution of the software centers on the operating software system which was developed by Siemens, specifically for the TXS systems. The operating system communicates with the platform software, and application software. The platform software includes the runtime environment program that provides a unified environment for execution of the function diagram modules.

3. Application software - The application software performs the plant-specific TXS safety-related functions using function block modules which are grouped into function diagram modules. The application software is generated by SPACE tools which use the qualified software modules from, the function block library to construct a specific application.

4. SPACE tool - The SPACE (specification and coding environment) tool is an engineering system that is used to implement the requirements of plant-specific I&C features.

Each of the building blocks is described by the staff in a generic manner. The use of these system building blocks is a TXS system design principle that is clearly identified and approved by the SE.

Equipment qualification methods Page 2 of the SE states:

"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 3.

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 deviations between German and U.S. standards, the equipment qualification design was considered to be acceptable."

The TXS design method for equipment qualification is approved by the SE, contingent on an applicant demonstrating closure of action item 1 on page 52 of the SE.

Operating system software development process, including verification and validation (V&V) methods.

The following statements appear on Page 46 of the SE:

"On the basis of its review of the software processes used throughout the software life cycle, and on the basis of its audit of software development documentation, the staff concludes that the software development process used at Siemens is acceptable.

The independent verification and validation (IV&V) process for the Siemens TXS is consistent with the IV&V process described in IEEE 1012-1998...

The staff concludes that the Siemens IV&V effort is sufficiently independent in personnel, management, and financial resources...

On the basis of its review of the Siemens engineering procedures and the results of its audit of Siemens software development processes, the staff concludes that Siemens has an acceptable software development methodology and follows this methodology consistently in developing safety-related software. The staff also determines that SPACE (specification and coding environment) 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."

The TXS software development process for operating system software, application software development tools, and function block library development, including V&V were approved by the SE. AREVA NP submitted topical report ANP-10272, "Software Program Manual for TELEPERM XS Safety System Topical Report," by letter dated December 21, 2006, to address action item 2 from page 52 of the SE for the TXS application software development process used for United States projects. As indicated in Duke letter dated April 29, 2008', in response to NRC Issue 3, Duke has evaluated 4

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 reference to the AREVA SPM and concluded that there is no need to reference the AREVA SPM. The response to Issue 3 identifies SPM implementation documents.

Processing Principles Page 2 of the SE states:

"The design principle for software of Class 1E systems is to ensure that the sequence of processing executed for each expected situation can be deterministically established. It discourages the use of non-deterministic data communications, non-deterministic. computations, multitasking, dynamic scheduling, use of nondeterministic interrupts and event driven designs.

Based on its review, the NRC staff determined the design of the TXS system satisfies this design principle for Class 1E system software."

The TXS design principles related to processing are approved by the SE.

• Interchannel communication principles Page 7 of the SE states:

"Specific communication methods are applied to ensure interference-free communication inside the TXS system and within the plant process information system. The TXS design requires that in case of a single failure of one of the independent processing channels or within one communication path in the same processing channel, the channels still available will continue to operate as designed on the basis of the remaining information to ensure the required safety functions do not fail."

Additionally, page 19 of the SE describes in greater detail the "specific communication methods" mentioned above.

The TXS interchannel communication methods and principles are clearly identified and approved by the SE.

5

Enclosure TSC 2007-09, Supplement 3 May 15, 2008

• Service Unit maintenance interface Pages 5 and 6 of the SE describe the principles of the service unit interface in several statements:

"The MSI serves as a gateway between the computers of the automatic path and other non-safety-related systems such as service units."

"The non-safety-related service unit requests access through the MSI to perform the diagnostic function at the safety-related processor."

"The service unit contains the central data of the I&C system. It is the central means for interventions into the safety-relevant software of the function processors."

"The service unit is protected against unauthorized interventions. The control mechanisms are installed by software so that only authorized persons may access the service unit, only authorized interventions may be performed, and interventions are restricted to a single redundant channel."

Duke believes the TXS principles and methods related to the service unit maintenance interface are clearly identified and approved by the SE.

2. NRC Review and Audit of TXS Configuration Management and Design Change Process during Topical Report Review Engineering Procedure FAW-1.5, "Configuration Management," was submitted to NRC to support the review of the TXS Topical Report.

The NRC review of the TXS platform configuration management and design change process is discussed on page 36 of the SE:

"2.2.4 Configuration Management Configuration management activities are controlled by Siemens Engineering Procedure FAW-1.5, "Configuration Management." This procedure provides the requirements and 71 procedures necessary for maintaining configuration control of the project. The procedure defines the configuration requirements and specifies the processes for generating configuration identifiers, controlling changes, and 6

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 maintaining version control during the development process. Configuration identification is applied to all software and associated documentation.

Baselines are established to control design, product, and engineering changes.

These baselines are defined by the configuration manager, and cannot be changed without approval of the configuration control board. The procedure to change a configuration item consists of the following steps:

• A change request is prepared by the person requesting the change.

• The development group evaluates the change.

• A proposal describing the process for making the change is prepared.

• The development group recommends disposition of the change request.

• The configuration item is changed according to the approved change request and proposal for change.

Software configuration management and control is applied to all documents and software code. This control is implemented using the configuration identification

.number assigned by the configuration manager.

Siemens maintained the documentation of configuration management for the TXS system platform that includes long-term service with compatible hardware and software components. Siemens also maintained the documentation of project-specific configuration management activities that include project-specific application software consistent with functional requirements. Every hardware and software component has a certification that identifies the modification version of that component.

The staff found that the configuration management procedure FAW-1.5 is compatible to IEEE-1042, "IEEE Guide to Software Configuration Management,"

and is, therefore, acceptable. However, the licensee should demonstrate that the plant-specific configuration management activities have been carried out in the life cycle process implementation. Documentation should exist that shows the configuration baselines have been established for the activity group, and an adequate change control process has been used for changes to the product baseline. This is a plant-specific action item."

The implementation of the TXS platform design change process was specifically audited by NRC, as documented on page 45 of the SE:

7

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 "The adequacy of the Siemens development process was reviewed by the staff during an audit at the vendor facility. The staff conducted a life cycle process audit of the TXS by tracing three requirements through the software life cycle."

Statements are made in the SE to indicate that specific hardware and software modules were audited to verify the acceptability of the processes under which they were designed. For example, page 45 of the SE includes the following statement:

"The first audit of requirements conducted by the staff involved change request 200 (CR200), which implemented the S706 input/output driver, version 1.20. The staff reviewed the documentation supporting the life cycle phases of system specifications, functional specifications, detailed design specifications, implementation (by code review), test specifications, test results, and the certification update. In the review of the test specifications and the test results for consistency with test specifications, the staff concluded that the development of the S706 input/output driver was consistent with the' Siemens software life cycle processes and, therefore, was acceptable."

and, "The third audit of requirements conducted by the staff involved CR203, which addressed the process by which data may be entered in a SPACE function block module diagram. The change was required to remove the capability to enter hardware-specific parameter information from the network diagram parameter entry dialog screen. The change request was processed according to Siemens procedures, following all of the Siemens requirements, including verification and This information was reviewed by NRC staff at the Siemens offices in Germany. The following documents were later submitted to NRC by AREVA letter dated January 13, 2000:

" Documentation for Modification Request 200

" Documentation for Modification Request 203 There are no statements in the SE to indicate that approval was limited to specific versions of hardware or software that were audited as part of the review.

Finally, Section 3.2 "Method. of Review" of the SE states on page 39 that:

"This topical report was submitted for generic review, and will be referenced in 8

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 the future for a plant protection system upgrade or replacement. To ensure that the digital plant protection system will perform its safety function as designed, the staff concentrated on the basic operation of the TXS software system, the life cycle activities of TXS hardware and software systems, and the qualification testing."

Duke understands this passage as an acknowledgement that the NRC's review and subsequent approval of the TXS platform focused on the basic operating principles of the TXS platform, the life cycle activities used in development of TXS platform software and hardware, and the TXS qualification testing methods; all of which are TXS design principles and methods. As such, there are no deviations from any limitations or conditions that need to be evaluated for acceptability.

3. Recent NRC Inspection of TXS Configuration Management and Design Change Process NRC recently conducted an inspection at the AREVA-NP GmbH (AREVA) facility in Erlangen, Germany. Relevant portions of the NRC Inspection Report For AREVA-NP GmbH 99901371/2008-20 1 dated May 7, 20084, are provided below:

TXS Platform Software Development and Configuration Management (from page 5)

"FAW TXS 1.5en, "Configuration Management Plan for the TELEPERM XS System Platform," Revision C, dated October 4, 2005, provides controls for the configuration requirements and specifies the processes for generating configuration identifiers, controlling changes, and maintaining version control during the development process.

Configuration management (CM), as described in this engineering procedure, is based on the system platform of TXS and represents a generic basis for developing and implementing safety-related digital I&C systems. The CM as specified comprises the technical support and management of the product life cycle of the TXS system platform, which includes all the hardware and software components recorded in the product structure plan as well as the associated development documentation. This engineering procedure also addresses the requirements of the type tests for the TXS system platform which covers the recommendations of relevant parts of DIN EN ISO 10007, "Quality Management, Guidelines for Configuration Management," issued December 1996, and IEEE 828, "Software Configuration Management Plans," dated May 1998."

.9

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 Development Infrastructure Security (from page 7)

"The inspectors requested engineering procedure FAW-TXS 1.7, "Information Security,"

dated August 23, 2004, to review the security aspects during the development of the TXS operating system software and function block library software to determine whether AREVA has a secure software development infrastructure. The vendor indicated that a corporate-wide procedure for information technology security incorporating all of the FAW 1.7 requirements had superseded this procedure. The inspectors reviewed the new procedure, AREVA NP GmbH "Informationssicherheit," dated November 25, 2005, with support from the vendor's technical staff. The inspectors also conducted detailed interviews with AREVA personnel to ensure that this new replacement procedure covered the necessary security aspects and requirements of a secure software development infrastructure. The inspectors requested information regarding, but not limited to, 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 to the development lab.

Additionally, the inspectors verified implementation of security measures during the tour of the TXS platform development lab. The inspectors found no issues associated with the security controls used for the development of TXS software."

Conclusions (from page 13)

"The inspectors concluded that AREVA design control program requirements are consistent with the regulatory requirements of Criterion III of Appendix B to 10 CFR Part

50. Based on the limited sample of TXS platform and application design, CM, and testing documentation reviewed, the inspectors determined that the AREVA design control procedures were being effectively implemented."

Duke believes the inspection process provides an established framework to provide regulatory oversight of the continued evolution of TXS technology under approved design, testing and qualification controls in accordance with the approved TXS design principles.

10

Enclosure TSC 2007-09, Supplement 3 May 15, 2008

4. Oconee RPS/ESPS Project Documentation Previously Submitted to NRC Duke has provided specific documentation requested by NRC as evidence that the hardware and software used for the Oconee project have been qualified in accordance with the TXS process. These documents were identified in the RPS/ESPS License Amendment Request (January 31, 2008, letter from Duke Energy to NRC entitled "License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2007-09) and docketed by reference in Supplement 1 to the LAR dated April 3, 20085. These documents provide reasonable assurance that the previously approved processes have been followed to make software, hardware, and procedural changes to the TELEPERM XS platform.

LAR Document 3 - AREVA NP Document 38-9018447-000, "Software Configuration of the

'TXS Software' for LINUX, Release 3.0.7A (NGLTD/2005/en/0148)," provides a summary of the independent qualification certificates for the operating system software provided for the Oconee project on page 26.

LAR. Document 20 - AREVA NP Document 66-5015893-03, "TELEPERM XS Supplemental Equipment Qualification Summary Test Report," provides a summary of additional equipment qualification testing required by plant-specific action item 1 identified in the NRC safety evaluation for the TXS Topical Report.

LAR Document 21 - AREVA NP Document 66-5065212-03, "Oconee Nuclear Station Unit 1 RPS/ESFAS Replacement Project Equipment Qualification Report," provides a summary of all the equipment qualification testing performed for the Oconee project.

LAR Document 22 - AREVA NP Document 38-9046580-000, "TUV Certificate No.

968/K 110/02 for Communication Processor System TELEPERM XS," provides.the qualification certificate for the SCP2 communication processor.

LAR Document 23 - AREVA NP Document 38-9046927-001, "TUV Report No.

968/K 110.01/02, Documentation of Theoretical and Practical Testing in Accordance with KTA 3503 of Communication Processor SCP2 in the TELEPERM XS System from Framatome ANP GmbH," provides a summary of the independent qualification testing for the SCP2 communication processor.

LAR Document 24 - AREVA NP Document 38-9047360-000, "TUV Certificate No.

968/K 109/02 for Processing Module System TELEPERM XS," provides the qualification certificate for the SVE2 communication processor.

11

Enclosure TSC 2007-09, Supplement 3 May 15, 2008

5) Summary of Key TXS Development Process Changes The TXS configuration management process described in Engineering Procedure FAW-1.5, "Configuration Management Plan for the TELEPERM XS System Platform," Engineering Procedure FAW-1.5 has evolved since the TXS Topical Report was issued. The changes include the addition of a change control board to the configuration management process and the inclusi6n of additional detail describing configuration management tasks (e.g., more precise configuration identification).

The information security requirements have expanded since the TXS Topical Report was issued. The information security requirements described in Engineering Procedure FAW-1.7, "Information Security," was applicable to TXS activities. These controls were summarized in section 3.2.9.1 of the January 30, 2008 letter6 from Duke Energy to NRC entitled "Cyber Security Features Associated with the Digital Upgrade of Oconee Nuclear Station Reactor Protective System and Engineered Safeguards Protective System." The information security requirements for AREVA NP (GmbH) have been expanded to encompass all business activities, including TXS. The corporate level controls were summarized in section 3.2.9.2 of the same January 30, 2008 letter.

The TXS equipment qualification methods have been expanded to include the additional qualification testing required by plant-specific action item 1 identified in the NRC safety evaluation for the TXS Topical Report.

Changes to TXS platform hardware and software continue to be qualified using the generic qualification process as described in Section 2.2 of the TXS Topical Report.

Conclusion Based on the above, Duke believes it complies with the specific conditions a licensee must address, which are identified in Section 6.0 of the TXS Safety Evaluation as plant specific action items. Table 1-1 of Enclosure I of the LAR indicates where each plant specific action item is addressed in the LAR.

Duke concludes that there are no deviations from any limitations or conditions from the NRC approved Teleperm XS Topical Report that need to be evaluated for acceptability as suggested by NRC Issue 4. The TXS equipment for the Oconee RPS/ESPS project has been designed and qualified in accordance with the TXS development methods described in the TXS Topical Report that have been previously approved by the NRC. Duke has provided plant specific design 12

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 information in response to plant specific action items that are required to be addressed when requesting NRC approval of installation of a TXS System. These plant specific action items were identified as conditions. Information addressing these plant specific action items address differences between the TXS system approved by the NRC and the TXS system to be installed at Oconee and is provided with the LAR as required.

The SE for the TXS Topical Report documents the NRC's review and subsequent approval of the TXS platform that focused on the basic operating principles of the TXS platform, the life cycle activities used in development of TXS platform software and hardware, and the TXS qualification testing methods; all of which are TXS design principles and methods. As part of that review, particular attention was paid to the configuration management and design changes process. A summary of key TXS development process changes is provided in Item 5 above.

Duke believes there have been no changes in the methods approved by the TXS SE. The changes to the TXS System identified in Section 2.7 of the LAR were made by AREVA under the configuration management process approved by the NRC in the TXS SE. AREVA evaluated each change and confirmed that the requirements of the TXS Topical Report were met. All upgrades to hardware and software were qualified in accordance with the TXS Topical Report.

The scope of the Duke Energy supplier audits at AREVA NP, Inc. and AREVA NP, GmbH included a review of the adequacy and effectiveness of the Quality Assurance Program for implementation of 10 CFR50 Appendix B, 10CFR21 requirements. These two supplier audits were used to confirm that AREVA is following these approved methods for change control.

13

Enclosure TSC 2007-09, Supplement 3 May 15, 2008 References 1 Duke letter to NRC dated January 31, 2008, "License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change Number 2007-09" 2 NRC Letter to AREVA dated May 5, 2000, "ACCEPTANCE FOR REFERENCING OF LICENSING TOPICAL REPORT EMF-21 10(NP), REVISION 1, "TELEPERM XS: A DIGITAL REACTOR PROTECTION SYSTEM (TAC NO. MA1983)"

3 Duke letter to NRC dated April 29, 2008, "License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2007-09, Supplement 2" 4 NRC letter to AREVA dated May 7, 2008, "NRC INSPECTION REPORT FOR AREVA-NP Gmbh 99901371/2008-201, NOTICE OF VIOLATION, AND NOTICE OF NONCONFORMANCE" 5 Duke letter to NRC dated April 3, 2008, "License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2007-09, Supplement 1" 6 Duke letter to NRC dated January 30, 2008, "Cyber Security Features Associated with the Digital Upgrade of Oconee Nuclear Station Reactor Protective System and Engineered Safeguards Protective System."

14