ML052850287

From kanterella
Jump to navigation Jump to search
Response to Request for Additional Information Pertaining to License Amendment Request for Rps/Esps Digital Upgrade Technical Specification Change Number 2004-09, Supplement 1
ML052850287
Person / Time
Site: Oconee  Duke Energy icon.png
Issue date: 10/06/2005
From: Rosalyn Jones
Duke Power Co
To:
Document Control Desk, Office of Nuclear Reactor Regulation
References
TSC 2004-09
Download: ML052850287 (47)


Text

Dukee.

Duko_ RONALD AJONES Vice President L *ower. Oconee Nuclear Site Duke Power ONOl VP / 7800 Rochester Hwy.

Seneca, SC 29672 864 885 3158 864 885 3564 fax October 6, 2005 U. S. Nuclear Regulatory Commission Washington, D. C. 20555 Attention: Document Control Desk

Subject:

Oconee Nuclear Station Docket Numbers 50-269, 270, and 287 Response to Request for Additional Information Pertaining to the License Amendment Request (LAR) for RPS/ESPS Digital Upgrade Technical Specification Change (TSC) Number 2004-09, Supplement 1 In a submittal dated February 14, 2005, Duke proposed to amend Appendix A, Technical Specifications, for Renewed Facility Operating Licenses DPR-38, DPR-47 and DPR-55 for Oconee Nuclear Station, Units 1, 2, and 3. The LAR requests NRC to approve the Reactor Protection System (RPS)/Engineered Safeguards Protection System (ESPS) modification and associated Technical Specification change.

By letter dated September 6, 2005, Duke received a formal Request for Additional Information (RAI) from the NRC related to this LAR. Prior to this, Duke received a draft RAI via electronic mail on March 30, 2005. Duke provided preliminary responses to many of the questions in the draft RAI and later met with the NRC to discuss these responses.

Based on input received from NRC staff during a Duke/NRC meeting on August 17, 2005, or changes to the draft questions when formalized, Duke has revised many of the preliminary responses.

Duke is currently in the process of developing responses to the remaining questions. For these cases, Duke has provided an approximate date for submitting the responses.

In addition, many of the responses are tied to design deliverables in the RPS/ESPS modification schedule. Duke www. dukepower. corn

U. S. Nuclear Regulatory Commission October 6, 2005 Page 2 plans to submit the remaining responses as they become available on or before November 3, 2005, December 1, 2005, and January 12, 2006. and 2 provide Duke's response to the RAI questions. Attachment 3 provides a list of NRC commitments associated with this submittal. contains information proprietary to Framatome ANP (FANP). An affidavit from Framatome ANP (FANP) is included as Attachment 4. This affidavit sets forth the basis on which the information may be withheld from public disclosure by the NRC pursuant to 10 CFR 2.790.

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

Very t yours, R. . es, Vice President Oconee Nuclear Site

U. S. Nuclear Regulatory Commission October 6, 2005 Page 3 cc: Mr. L. N. Olshan, Project Manager Office of Nuclear Reactor Regulation U. S. Nuclear Regulatory Commission Mail Stop 0-14 H25 Washington, D. C. 20555 Mr. S. E. Peters Office of Nuclear Reactor Regulation U. S. Nuclear Regulatory Commission Mail Stop 0-14 H25 Washington, D. C. 20555 Dr. W. D. Travers, Regional Administrator U. S. Nuclear Regulatory Commission - Region II Atlanta Federal Center 61 Forsyth St., SW, Suite 23T85 Atlanta, Georgia 30303 Mr. M. C. Shannon Senior Resident Inspector Oconee Nuclear Station Mr. Henry Porter, Director Division of Radioactive Waste Management Bureau of Land and Waste Management Department of Health & Environmental Control 2600 Bull Street Columbia, SC 29201

U. S. Nuclear Regulatory Commission October 6, 2005 Page 4 bcc:

Robert E. Hall James T. Fuller Robert W. Cornett Barry R Loftis Barbara M. Thomas B. Graham Davenport T. P. Gillespie Robert L. Medlin Lisa F. Vaughn Paul M. Stovall David B. Coyle Scott L. Batson Robert L. Gill - NAID Lee A Keller - CNS Charles J. Thomas - MNS Gregg B. Swindlehurst H Duncan Brewer Robert P Boyer NSRB, EC05N ELL, ECO50 File - T.S. Working BWOG Tech Spec Committee (5)

ONS Document Management Reene' V. Gambrell

U. S. Nuclear Regulatory Commission October 6, 2005 Page 5 R. A. Jones, being duly sworn, states that he is Vice President, Oconee Nuclear Site, Duke Energy Corporation, that he is authorized on the part of said Company to sign and file with the U. S. Nuclear Regulatory Commission this revision to the Renewed Facility Operating License Nos.

DPR-38, DPR-47, DPR-55; and that all the statements and matters set forth herein are true and correct to the best of his knowledge.

R. A.c Oconee Sutbscribed and sworn to before me this V day of 2005 1 ,,

Notary Publ.ic My Commission Expires:

N- ol 3

  • _ A-  :

~: i:N October 6, 2005 Page 1 Attachment 1 - Non Proprietary Duke Response to Request for Additional Information (RAI)

Oconee Nuclear Station License Amendment Request for RPS/ESPS Digital Upgrade RAI 1.A Please provide the following documentation:

Design requirements and design basis for the RPS/Engineered Safeguards Protection System (ESPS) TELEPERM XS (TXS) system as it will be installed at Oconee. This should include a detailed system description with system architecture and system specification for the planned TXS and any subsystems. This should include a copy of the information supplied by the licensee to the vendor, and the vendor system, and hardware and software design specifications as described in specification item 11.4.

Duke Response to RAI I.A Design requirements and design basis for the RPS/Engineered Safeguards Protection System (ESPS) TELEPERM XS (TXS) system as it will be installed at Oconee are provided in ESFAS Replacement Project Specification OSS-0311.00-00-0012 - R02, RPS Replacement Project Specification OSS-0311.00-00-0013 - R01, and RPS and ESFAS System Functional Description, OSC-8623, R01 (also referred to as a Functional Requirements Specification (FRS)). A system description with an overview of the system architecture is provided in Section 2 of ONS-1 RPS/ESF Software Design Description (SDD), Revision 0, FANP Document 51-5065423-00.

Revision 1 to the replacement project specifications was provided in electronic format to NRC staff via electronic mail on May 2, 2005, in response to RAI 11.B. Revision 2 to the ESFAS replacement project specification was provided in electronic format to NRC staff via electronic mail on September 29, 2005. The FRS was provided in electronic format to NRC staff via compact disk on August 23, 2005, in response to RAI 1-.H. The SDD was provided in electronic format to the NRC staff via electronic mail on September 30, 2005. Duke requests these documents be withheld from public disclosure pursuant to 10 CFR 2.390.

October 6, 2005 Page 2 RAI 11.B Please provide the following documentation:

Procurement Specification. If this does not include specific hardware and software specifications, please provide them. If the specification is revised or updated during the course of the project, please provide these updates.

Duke Response to RA! 1.B The following Duke/ONS replacement project specifications were provided in electronic format to NRC staff via electronic mail on May 2, 2005:

  • Specification No. OSS-0311.00-00-0012, R01 Engineered Safeguards Features Actuation System (ESPS) Replacement Project Specification
  • Specification No. OSS-0311.00-00-0013, R01 Reactor Protective System (RPS)

Replacement Project Specification Duke contracted Framatome ANP (FANP) to develop the Software Requirements Specification (SRS). Duke provided the Software Requirements Specification, Revision 01 (FANP Document 15-5045380-01 for Oconee Nuclear Station Unit 1), in electronic format to NRC staff via compact disk on August 23, 2005. The SRS is also being provided in response to RAI 11.H (ii. Technical Design Specification).

Duke requests these documents be withheld from public disclosure pursuant to 10 CFR 2.390.

RAI 1.C Please provide the following documentation:

Oconee Software Management plan (BTP-14, Section 3.1.a). The plan should show how the licensee will manage the software independent of the vendor.

RAI 11.D Please provide the following documentation:

Oconee Software Quality Assurance Plan and any procedures specific to this system (BTP-14, Section 3.1.c). This may include vendor document, but must specifically show how the licensee will maintain control of the hardware and software quality at the licensee site.

RAI 1.E Please provide the following documentation:

Oconee Configuration Management Manual, including the Software Configuration Management Plan (BTP-14, Section 3.1.k). This may include vendor document, but must specifically show how the licensee will maintain control of the hardware and software configuration at the licensee site. This plan should show how the licensee will insure the correct configuration management of the system and software independent of the vendor.

October 6, 2005 Page 3 Duke Response to RAI 1.C, 1.D, 1.E A project specific software configuration plan and verification and validation plan are in the process of being prepared. Configuration control will be maintained by Duke's vendor (FANP) for the following software development phases: Basic Phase, Requirements Phase, Design Phase, Implementation Phase, and Installation &

Checkout Phase.

Following the completion of the post installation testing, FANP will turn over configuration management control of the software to Duke. Duke will maintain software configuration control through the Operation and Maintenance Phase of the software life cycle pursuant to applicable nuclear system directives.

Duke defines the requirements for configuration management of Structures, Systems and Components (SSC), including software, at its nuclear facilities in Nuclear System Directive (NSD) 106, Configuration Management. Further guidance on configuration management is given in NSD 800, Software and Data Quality Assurance (SDQA)

Program, which requires the preparation of a Software and Data Quality Assurance (SDQA) document for safety related software. The SDQA document contains both the elements of the software and data quality assurance plan and also the elements of the configuration management plan. NSD 800 was provided in electronic format to the NRC staff via electronic mail on May 5, 2005. NSD 106 was provided in electronic format to the NRC staff via compact disk on August 23, 2005.

Duke provided drafts of FANP documents 51-5055761-00 (Oconee Nuclear Station, Unit 1 RPS/ESPS Controls Upgrade Application Software Configuration Management Plan (SCMP)) and 51-5058661-00 (Oconee Nuclear Station Unit 1 RPS-ESPS Controls Upgrade Application Software V&V Plan) to the NRC electronically on June 16, 2005. A draft SDQA document was provided to the NRC electronically on June 16, 2005. The final approved SDQA document is in preparation, review and approval and is expected to be issued by December 1, 2005. Duke will provide the final approved plan when it is issued.

RAI 1.F Please provide the following documentation:

The Oconee Safety analyses and the Framatome software safety analysis as required by specification item 7.3, including the licensee acceptance of the Framatome software safety analysis (BTP-14, Section 3.2.a).

Duke Response to RAI 1.F The Software Safety Analysis Plan is in preparation, review, and approval and is expected to be issued by October 31, 2005. Duke will provide a copy of the plan when is issued.

October 6, 2005 Page 4 RAI 1.G Please provide the following documentation:

Oconee Nuclear Station, Unit 3 RPS/ESF Controls Upgrade, Software V&V Plan, Document 51-5024087-00.

Duke Response to RAI 1.G See Response to 1.1 below.

RAI 1.H Please provide the following documentation:

Oconee Software Development plan and related life-cycle documentation, if any applications software is being developed by the licensee (BTP-1 4, Section 3.1 b). If applications software is being developed by Framatome, please provide the following software life-cycle documents in accordance with Section 5.1.2 of Topical Report EMF-21 10, 'Teleperm XS: A digital Reactor Protection System".

i. Requirements Definition ii. Technical Design Specification.

iii. Detailed Design Specification.

iv. Implementation Specification.

v. Integration Plan (BTP-14, Section 3.1.d).

vi. Test Plan Duke Response to RAI 1.H Duke contracted FANP to develop these software life-cycle documents. The V&V Plan (FANP Document 51-5058661-0) provides a complete description of FANP's software life-cycles and associated documentation. This plan was provided in Duke's response to RAI 01G and RAI 011-1. The life-cycle documents, procedures, document content, and industry standards used for the development of these documents are equivalent to those described in EMF-2110 and BTP HICB-14. Duke performs an owner's acceptance review of these software life-cycle documents. Life cycle documents available at this stage in software development are:

i. Requirements Definition - FANP Document 32-5061401-01 (Functional Requirements Specification Rev. 01 - owner's acceptance review complete) ii. Technical Design Specification - FANP Document 15-5045380-01 (Software Requirements Specification - owner's acceptance review not complete) iii. Detailed Design Specification - FANP Document 51-5065423-00 (Software Design Specification - owner's acceptance review not complete The Functional Requirements Specification and the Software Requirements Specification were provided in electronic format to the NRC staff via compact disc on August 23, 2005. The Software Design Specification was provided in electronic format to the NRC staff via electronic mail on September 29, 2005. Duke requests these documents be withheld from public disclosure pursuant to 10 CFR 2.390.

October 6, 2005 Page 5 The remaining documentation required by EMF-21 10 are being prepared in accordance with the Requirements Phase Life-cycle of the FANP V&V Plan (FANP Document 51-5058661-00). These documents are in preparation, review, and approval and are expected to be issued by the dates indicated below:

iv. Implementation Specification January 28, 2006

v. Integration Plan November 30, 2005 vi. Test Plan November 30, 2005 Duke will provide these documents when they are issued.

RAI 1.1 Please provide the following documentation:

The documentation and plans which the licensee will determine that the RPS/ESPS system software meets the requirements. This would normally include:

i. Software Design Review.

ii. Source Code Review iii. Software Verification and Validation Plan (BTP-14, Section 3.1.j) iv. Verification and Validation Report Duke Response to RAI 1.1 Duke contracted FANP to develop the Software Verification and Validation Plan, FANP Document 51-5058661-00, for Oconee Nuclear Station Unit 1. Duke performs an owner's acceptance review of this document in accordance with the applicable Oconee Site Engineering Manual procedure to check the reasonableness of inputs, assumptions, methods and results, and to obtain the concurrence of Oconee stakeholders. FANP Document 51-5058661-00 was provided in electronic format to the NRC staff via electronic mail on August 1, 2005. Duke requests that this document be withheld from public disclosure pursuant to 10 CFR 2.390. This document addresses RAI 1.G and RAI 1.1.iii. It is being provided in lieu of the Unit 3 Software V&V plan requested by RAI 1.G since the modification will be implemented on Unit 1 first.

Software development is currently at the stage of completing V&V activities described in the Requirements Phase Life-cycle of the V&V Plan. Software Design Reviews and Source Code Reviews are performed in later Software Life-cycle phases and are expected to be issued by October 31, 2005, and December 16, 2005, respectively.

Duke will provide these documents when they are issued.

The Verification and Validation (V&V) Report is being provided in phases. The requirements phase V&V Report was provided in electronic format to the NRC staff via electronic mail on September 29, 2005. The remaining V&V Reports are in preparation, review, and approval and are expected to be issued by:

1) design phase - November 15, 2005
2) implementation - January 30, 2006
3) testing phase - May 4, 2006 October 6, 2005 Page 6 Duke will provide these reports when they are issued.

RAI 1.J Please provide the following documentation:

Factory Acceptance Test (Specification item 9.2 - 9.6) and the Oconee Nuclear Station (ONS) Site Acceptance Test (Specification item 9.8), and any other test documentation which will be used.

Duke Response to RAI 1.J The Factory Acceptance Test (FAT) is currently planned for March 7 - March 23, 2006.

The FAT Plan, FAT Procedure, and FAT Report are expected to be issued by the dates indicated below:

FAT Plan November 30, 2005 FAT Procedure February 28, 2006 FAT Report May 4, 2006 Duke will provide the FAT Plan, Procedure, and Report when issued.

The Site Acceptance Test (SAT) is currently planned for April 3 - May 4, 2006. The Site Acceptance Test (FAT) Plan, SAT Procedure, and SAT Report are expected to be issued by the dates indicated below:

SAT Plan February 28, 2006 SAT Procedure March 28, 2006 SAT Report June 30, 2006 Duke will provide the SAT Plan, Procedure, and Report when they are issued.

RAI 1.K Please provide the following documentation:

The Oconee system and software training plan (BTP-14, Section 3.1.g).

Please include User Instruction Manual and an explanation of what training will be provided to control room operators, l&C maintenance personnel and plant engineering, as described in specification item 12.

Duke Response to RAI 1.K The Oconee User Instruction Manual is in preparation, review, and approval and is expected to be issued by December 15, 2005. Duke will provide this document when it is issued.

Duke will submit an explanation of what training has been provided by FANP to Duke by November 3, 2005. Training for control room operators, l&C maintenance personnel October 6, 2005 Page 7 and plant engineering is being developed as part of the modification process. Duke will provide additional explanation of this training by January 12, 2006.

RAI 1.L Please provide the following documentation:

The RPS/ESPS specification compliance matrix (specification item 11.12.a).

Duke Response to RAI 1.L The RPS/ESPS specification compliance matrix was provided in electronic format to the NRC staff via electronic mail on August 1, 2005. Duke requests that this document be withheld from public disclosure pursuant to 10 CFR 2.390.

Currently specification requirements are being traced into the Software Requirements Specification (SRS), and Hardware Requirements Specification (HRS). The requirements matrix is a living document, and is updated at the end of each V&V phase.

An update was provided in electronic format to the NRC staff via compact disk on October 4, 2005. Duke expects to issue the next updates by February 14, 2006, and May 4, 2006. Duke will provide these updates when they are issued.

RAI 1.M Please provide the following documentation:

The updated ONS UFSAR Chapter 15, Accident Analyses. This analysis should include an accident analysis which assumes that a common mode software failure renders unavailable all safety-related functions which are performed by the Teleperm XS RPS/ESPS system. If manual actions (sic) is credited, show what indications the operators would have which are not dependant on the Teleperm XS RPS/ESPS system.

Duke Response to RAI 1.M The Defense-in-Depth & Diversity (D3) Assessment, submitted on March 20, 2003, provided a re-analysis of Chapter 15 events coincident with a software common mode failure (SWCMF) (summary of the analyses and results provided in Section 10 of the Attachment). The bases for crediting operator action is described in Section 9.3 of the Attachment to the March 20, 2003 D3 submittal.

The D3 assessment assumes that all display indications other than those fed by the Teleperm XS portion of RPS/ES, will be available to the operator to prompt/aid in taking manual operator action since they will not be subject to the assumed SWCMF. For example, source and wide range NI's, NI power range total flux, RCS pressure, RCS flow, and RCS temperature will be available.

October 6, 2005 Page 8 RAI 1.N Please provide the following documentation:

The Human Factors Review, including the standards used. This should include any analysis done to demonstrate conformance with specification item 5.4.i and 5.6.

Duke Response to RAI 1.N The Duke/ONS design change process requires a Control Room Impact Evaluation which includes Human Factors (HF) Engineering reviews I Human-System Interface (HSI) reviews in accordance with Oconee Nuclear Site Engineering Manual (EM), EM 4.17, Human Factors Engineering Procedure. The review guidelines of EM 4.17 are consistent with NUREG 0700, "Human-System Interface Design Review Guidelines,"

Rev. 2, 2002, and NUREG 071 1, "Human Factors Engineering Program Review Model,"

Rev. 1, 2002. The initial HFE review is documented in a completed Attachment 2, HFE Review Form for Plant Changes of EM 4.17. A description of the review and the results are provided below. Subsequent human factors reviews, which are done as part of the design process, will be performed and documented in accordance with EM 4.17.

Specification items 5.4.i and 5.6 contain the requirements for HMI displays, indications and alarms for compatibility with existing plant Operations, Maintenance, and Engineering configurations. The various design change, HFE/HSI design reviews, and HFE Task Analysis will fully address the specification requirements. The results of these reviews will support compliance with specification sections 5.4.i and 5.6 and will be documented in the ONS modification Design Input Calculation per Oconee nuclear system directive requirements.

Initial Operations Panel Review The Operations Panel reviewed the initial plans to assess impact to the main control room control boards, the existing RZ Modules (ES actuated equipment controls) and the control room Stat Alarm annunciator panels. At this point in the project schedule only preliminary initial scope information was available. However, the Oconee Operations and System Engineering organizations were provided this input as early as possible in the design process to effectively obtain their review and comments.

This design review effectively identified Human Factors Engineering (HFE) discrepancies (problems and issues) associated with operator tasks that could potentially hinder human performance. Identifying HFE discrepancies during the initial scoping phase provided a basis for changing the system design at a time that resulted in minimal design impact. The corrective actions taken to resolve these HFE discrepancies will be reflected in subsequent HFE/Design Reviews. Copies of the documentation for this Operations Panel Review, which includes the RPS/ESPS System Overview summaries and Unit control room Stat Alarm panel windows, identify the proposed changes to the system operation and controls presented during this review.

Additionally, interviews with the Operations personnel and System Engineers who have familiarity with these systems and an understanding of the intended modification were conducted as part of the discussions. This approach will be repeated throughout the October 6, 2005 Page 9 design development process and documented as part of the design and HFE review process.

The HFE review applies to all of the individual elements of the proposed design.

Operating Experience Review (OER)

The OER was performed to identify and analyze HFE-related safety issues. The objective was to identify any relevant plant specific or industry wide history of operating experience problems and issues encountered previously in designs and human tasks that were similar to Oconee's planned modification so that issues that could potentially hinder human performance can be addressed.

There are 22 nuclear applications using the Framatome-Siemens TXS design platform worldwide. The proposed design change upgrade modification for the Oconee Units 1, 2, & 3 is the first installation of a safety related digital control system for a Reactor Protection System (RPS) and Engineered Safeguards Protective System (ESPS) in a nuclear power plant in the United States. Because of this, there was very little specific RPS/ESPS digital operating experience to draw from. There are, however, many safety related and non-safety related digital control systems currently operating in US nuclear power plants in various other applications. Operating history experience identified for those systems was included in this review. The following Duke ONS plant specific, Framatome-ANP, and industry information sources were reviewed:

> Problem Investigation Process (PIP) System (100+ PlPs)

> Framatome-ANP procedure 1717-06, Corrective Action Program (WebCAP)

> The Duke/ONS Digital Control Rod Drive Control System (DCRDCS) Project Lessons Learned Briefing

> INPO Significant Event Notifications/Reports (SENs/SERs) and INPO Significant Operating Experience Reports (SOERs) (600 total events)

> NRC Generic Letters (19 letters)

> NRC Bulletins (12 bulletins)

> NRC Information Notices (172 notices)

> NRC License Event Reports (300 LERs)

> NRC Human Factors Information System (6 events)

All applicable items related to Digital Control Systems were provided to the RPS/ESPS Project Team for their review and consideration as part of the design development.

Additionally, to ensure that any future items are identified, the FANP RPS/ESPS Project October 6, 2005 Page 10 Team receives a summary of any relevant SOERs, Duke/ONS PlPs, and FANP WebCAP items as part of the weekly project staff meeting. This approach will be maintained throughout the design modification project.

Phase II and Phase IlIl of the human factors review are being completed as part of the final modification process. Phase II includes an integrated design review, task analysis, and functional requirements specification analysis and function allocation. Phase IlIl includes a final design review, training, simulator modifications, task analysis procedures, and integrated system validations.

RAI 1.0 Please provide the following documentation:

The Failure Modes and Effects Analysis (FMEA), including not only significant failure modes but all failure modes (specification item 2.1.cc, 2.3.u, 6.12, and 11.11).

Duke Response to RAI 1.0 The FMEA is in preparation, review, and approval and is expected to be issued by November 30, 2005. Duke will provide a copy of the FMEA when it is issued.

RAI 1.P Please provide the following documentation:

Siemens (FANP) Report, 66-5015893, "TXS Supplemental Equipment Qualification, Summary Test Report" and TUV test report, 968/K 109.00/02 dated September 13, 2002.

Duke Response to RAI 1.P Siemens (FANP) Report, 66-5015893, "TXS Supplemental Equipment Qualification, Summary Test Report" was provided in electronic format to the NRC staff via electronic mail on May 3, 2005. TUV test report, 968/K 109.00/02 was provided in electronic format to the NRC staff via electronic mail on May 10, 2005. Duke requests that these documents be withheld from public disclosure pursuant to 10 CFR 2.390.

RAI 1.0 Please provide the following documentation:

The RPS/ESPS System Instrument Setpoint Calculations and Instrument Accuracy Uncertainty Calculations. If the ONS setpoint methodology is derived from ISA 67.4, please state which methodology is used. Has the setpoint methodology been reviewed and approved by NRC? If so, please provide the appropriate reference documents. The intent is to demonstrate:

1) That in accordance with plant specific action item 10 contained in the April 13, 2000, SER on the TXS topical report, that overly conservative setpoints that may occur due to elimination of analog system drift are not retained, as this would increase the possibility that the TXS equipment may be performing outside the vendor specifications, and 2) to show that the approach that is October 6, 2005 Page 11 used to develop the proposed limits provides adequate assurance that the plant will operate in accordance with safety analyses, and that operability is ensured in the Technical Specifications.

Duke Response to RAI 1.0 The current RPS/ESPS Instrument Setpoint Calculations and Instrument Accuracy Uncertainty Calculations (listed below) were provided in electronic format to the NRC staff via compact disk on June 23, 2005. Duke requests that these documents be withheld from public disclosure pursuant to 10 CFR 2.390.

The current setpoint methodology has been reviewed and approved by the NRC (reference NRC letters dated October 1,1998, May, 25,1999, and September 24, 2003). These documents (listed below) were provided in electronic format to the NRC staff via compact disk on June 23, 2005.

These calculations require revision as a result of the RPS/ESPS digital modification.

The revised calculations will address any margin gains or losses. The required revisions are in preparation, review, and approval and are expected to be issued by December 31, 2005. Duke will provide a summary of the results of the revised calculations when issued.

The following documents were included on the CD sent to NRC on June 23, 2005:

Current Setpoint Methodology and NRC approvals Current Oconee Setpoint Methodology NRC letter dated October 1, 1998 NRC letter dated May 25, 1999 NRC letter dated September 24, 2003 RPS/ESPS System Instrument Setpoint Calculations and Instrument AccuracV Uncertainty Calculations

1. OSC-2759, Rev. 2, Wide Range RCS Pressure Uncertainty, (ESFAS HPI & LPI setpoints)
2. OSC-4048, Rev. 4, RPS RCS Pressure & Temperature Trip Function Uncertainty Analysis and Variable Low Pressure Safety Limit
3. OSC-3395, Rev. 3, RPS Main Feedwater Pump Pressure Instrument Loop Accuracy Calculation
4. OSC-3416, Rev. 3, RPS Flux/Flow Ratio Uncertainty Evaluation
5. OSC-3446, Rev. 3, Reactor Building Pressure Instrument Loop Accuracy Calculation (ESFAS & RPS)
6. OSC-5604, Rev. 2, Power-Imbalance Safety Limits and Tech. Spec. Setpoints Using Error-Adjusted Flux/Flow Ratio of 1.094
7. OSC-7237, Rev. 1, RPS High Flux and Pump/Power Monitor Trip Function Uncertainty Analysis October 6, 2005 Page 12
8. OSC-2495, Rev. 5, Reactor Building Narrow Range Pressure Instrument Loop Accuracy Calculation (ESFAS)

RAI 1.R Please provide the following documentation:

The output from the RETRANS tool, and the analysis comparing this output to the design data base. If a different validation tool, not previously reviewed and approved by the NRC staff, is being used, please provide sufficient information on the tool to show that the tool can be relied upon to perform its task, as well as the output of that tool and the analysis of that output showing that the design data base was correctly implemented in the plant specific safety-related software. In addition, please show how this new tool was dedicated for safety-related use, and the configuration control as required by Teleperm in accordance with specification item 6.13.

Duke Response to RAI 1.R The RETRANS tool is not being used for the Oconee application. FANP plans to validate the generated code on a test bed with a TELEPERM XS simulation tool referred to as SIVAT (Simulation-based Validation Tool). This V&V activity complies with Regulatory Guide 1.168, which states: V&V tasks of witnessing, reviewing, and testing are not required for software tools, provided the software that is produced using the tools is subject to V&V activities that will detect flaws introduced by the tools."

SIVAT was developed and is maintained by the GRS ISTec Institute for Safety Technology, Garching, Germany. ISTec applied it for the purpose of independent verification of TELEPERM XS applications software in the course of various TELEPERM XS I&C projects. RETRANS was used to gain experience and create a high level of confidence in the automatic code generation tool used for TELEPERM XS application software during the introductory phase.

Today the code generation process has been proven by a long series of successful TELEPERM XS I&C installations. Any updates performed to the code generation tool were subject to extensive testing and independent assessment by ISTec. For the last years of use, RETRANS code verification did not reveal any new findings. For this reason, the total RETRANS verification is no longer performed for current TELEPERM XS l&C projects and not available on recent software tool releases (release 3.0.x).

Those checks that were significant for design verification in the engineering process have been implemented in the scope of a Framatome ANP-owned TELEPERM XS tool. Namely, the automated crosschecking by the redifftool for detecting any deviations between the specified function diagrams assigned to the redundant protection channels (logics, parameters).

Additional information related to the qualification of the SIVAT simulation tool is in preparation and will be submitted as a revision to this RAI response by December 1, 2005.

October 6, 2005 Page 13 RAI 1.S Please provide the following documentation:

The RPS/ESFAS Software Defense-in-Depth and Diversity Analysis provided by Teleperm in accordance with specification item 6.13.

Duke Response to RAI 1.S FANP provided input into this assessment but was not required to perform the analysis of each UFSAR Chapter 15 event. Duke submitted the Defense-in-Depth and Diversity Assessment required by plant specific requirement 12 of the NRC staff SER on the TXS Topical Report by letter dated March 20, 2003. As such, the RPS and ESFAS Replacement Project Specifications, specification item 6.13, will be revised to reflect this.

RAI 1.T Please provide the following documentation:

The Software Installation Plan (BTP-14, Section 3.1.e).

Duke Response to RAI 1.T The Software Installation Plan is in preparation, review, and approval and is expected to be issued by November 30, 2005. Duke will provide this document when it is issued.

RAI 1.U Please provide the following documentation:

The Software Safety Plan (BTP-1 4, Section 3.1.i).

Duke Response to RAI 1.U The Software Safety Plan is in preparation, review, and approval and is expected to be issued by November 30, 2005. Duke will provide this document when it is issued.

RAI 1.V Please provide the following documentation:

The Software Operations Plan (BTP-14, Section 3.1.h).

Duke Response to RAI 1.V Duke will provide a date when this document can be provided by November 3, 2005.

RAI 2

List all functions currently performed by the existing RPS and ESPS. Indicate which of these functions will now be performed by the TXS.

October 6, 2005 Page 14 Duke Response to RAI 2 The functions currently performed by RPS/ESPS are listed in Table 1 below. All of these functions will be performed by the TXS.

Table 1 RPS Trip Functions Trip Function Name Trip Description High Reactor Power Trip Trip if NI power ZSetpoint At power, the Setpoint Is normally 104.75%

FluxlFlowlmbalance Trip Trip it NI power zSetpoint The Setpoint Isa calculated function of RC flow-rate and core axial power imbalance.

Number of RC Pumps Running Trip Trip If < 3 RC pumps running and NI power 2t 1.5%m (Flux/Pump Trip)

High RCS Pressure Trip Trip If RCS Pressure 2 Setpoint SP is normally = 2345 psig.

Low RCS Pressure Trip Trip If RCS Pressure 5 Setpoint SP is normally = 1810 psig.

Variable Low RCS Pressure Trip Trip If RCS Pressure 2 Setpoint The Setpoint Is calculated function of Thot SP = (11.14xThot) - 4696 is the equation when this document was written.

High RCS Hot Leg (Thot) Temperature Trip If RCS Temp 2 Setpoint 0

Trip SP is normally = 617 F.

High Reactor Building Pressure Trip Trip if Rx Bldg Press 2 Setpoint SP Is normally = 3.5 psig.

Main FW Pumps ARTS Trip Trip If both Main FW pumps are tripped and NI power Is approximately > 1.75%.

(Main FW Pumps Trips if hydraulc oil pressure 5approximatel 85 psig and trip is enabled.)

Main Turbine ARTS Trip Trip i the Main Turbine Trips and NI power is approximately > 30%.

(Main Turbine Trips if hydraulic fluid pressure Is S approximately 850 psig and trip is enabled.)

The ESPS actuation parameters are listed in Table 2 below. All of these functions will be performed by the TXS.

Table 2 ESPS Trip Functions r!rrp Condition *' TrIp Setpolnt -,Action"---

Low Reactor Coolant Pressure 1600 psig High Pressure Injection and Reactor Building (enabled at > 1750 psig) Non-Essential Isolation High Reactor Building Pressure 3.0 psig High Pressure Injection and Reactor Building Non-Essential Isolation Very Low Reactor Coolant Pressure 550 psig Low Pressure Injection (enabled at > goo psig)

(enabled at sgm psig)

High Reactor Building Pressure 3.0 psig Low Pressure Injection High Reactor Building Pressure 3.0 psig Reactor Building Cooling and Reactor Building Essential Isolation High Reactor Building Pressure 10 psig Reactor Building Spray October 6, 2005 Page 15 RAI3 List all hardware modules and software components which will be used in the Teleperm XS RPS/ESPS system, including the revision level. This should Include the detailed Bill of Materials described in specification item 2.3.w and the hardware and software documentation as described in specification item 11.5 and 11.6. Are any of these revision levels of either hardware and software different from those previously reviewed and approved by NRC? If so, please provide the change control documentation and results of regression testing.

Duke Response to RAI 3 Advances in digital technology have resulted in revisions to the TXS platform in the six years since the Topical Report was initially submitted in 1999. These enhancements take advantage of advancements in technology and increased processing power.

There are three hardware components that are different than those previously reviewed and approved by the NRC:

  • the SVE1 (Control Processor),
  • the SCP1 (Ethernet Communication processor) and
  • the SBG1 (Equipment sub-rack) have been upgraded and assigned new model numbers.

There are also different revisions to the parts originally installed in the TELEPERM platform.

Oconee will receive Version 3.0.7a of the TELEPERM TXS Core Software and version 1.5.1 of the SIVAT Simulation Software.

The current software version is different than the version available and reviewed in the Topical Report. However, it utilizes the same architecture and is comprised of the same software components (though with upgrades to some components) as the software originally reviewed in the Topical Report. In addition, it has undergone the same testing and qualification. These changes were made in accordance with the software configuration management program described in the Topical Report and approved by the NRC SER for the Topical Report dated May 5, 2000. For a detailed discussion of software configuration management for the TXS software, refer to section 3.2 of the Topical Report.

[Proprietary Information - Refer to Attachment 2]

The NRC requested Duke to provide an evaluation of the hardware and software differences (between what was approved by the Topical Report SER and what is being used in the Oconee design) and explain why changes (whether they are considered trivial and non trivial) are acceptable. This request was made in a new RAI (RAI 30) provided verbally on August 17, 2005 and formally by letter dated September 6, 2005.

Duke will provide any further information related to differences in our response to RAI 30.

October 6, 2005 Page 16 RAI4 The submittal identified several differences between the TXS system approved by the NRC and the system proposed for installation at ONS, principally the SVE CPU module and the communications modules. Please provide the following information:

A. Exact description of the changes, including changes to support chip sets, printed circuit board artwork, and software changes. Software change descriptions should include changes to the basic input/output system (BIOS) for the different processor.

B. The environmental test data which verified the new equipment qualifications, including temperature, humidity, radiation, seismic, and electromagnetic qualifications.

C. Test data showing that the existing software did not require modification, or if modifications were required, a description of those software changes and how the changes were tested.

D. Page 3-48 of EMF-2110 states that a ISTecIT(JV-Nord issued a certificate for the CP486. Has a similar certificate been issued for the new SVE CPU? If so, please provide that certificate Duke Response to RAI 4 The response to RAI 4.A and 4.C will be included in Duke's response to RAI 30. The response to RAI 4.B is in preparation and will be submitted by November 3, 2005.

In response to RAI 4.D, a similar certificate has been issued. Duke provided the certificate (Nr. 968K 109/04) in electronic format to the NRC staff via electronic mail on September 19, 2005. Duke provided the test report (968-K109.03-04) referenced as an integral part of the certificate in electronic format to the NRC staff via electronic mail on September 20, 2005.

RAI 5

List the online continuous self-testing and diagnostic functions. Do these differ or add to the diagnostic functions reviewed In the original TXS SER? Please provide sufficient information for the NRC staff to determine either that the diagnostics and self test have not changed since the original SER, or that they have changed, sufficient information for the NRC staff to review those changes.

Duke Response to RAI 5

[Proprietary Information - Refer to Attachment 2]

October 6, 2005 Page 17

RAI 6

Section 4.9 of topical report EMF-2110 states "Signal transmission between redundant class 1E channels may be required for availability or reliability reasons.

If required it will be performed by serial fiber optic Profibusses in an end to end configuration." Since the February 14, 2005, submittal states that the TXS sets exchange their process data via point-to-point fiber-optic data links and that by comparison (Data Validation) between the redundant values, outlying signals are rejected and the optimum representative signal is selected, it would appear that this feature [is] used in the Oconee RPS/ESFS application. How is the requirement for channel independence maintained in accordance with IEEE 279-1971, as referenced in the Duke Power specification item 5.4.f? Please describe in detail all communications and data exchange between channels.

Duke Response to RAI 6 Duke will respond to the question related to channel independence in our response to RAI-27. Duke's response to the question related to communications and data exchange is in preparation and will be submitted by November 3, 2005.

RAI 7

The February 14, 2005, submittal states that "the new RPS system will enhance the RPS/Operator Aid Computer (OAC) interface. The TELEPERM-OAC gateway will make additional Information available to the OAC on RPS process variables and equipment status."

a) Please provide details on this enhancement, listing what additional information will be available.

b) and all software and hardware changes to the TXS system required for these changes" c) "In addition, please show how isolation is maintained" d) "Please describe In detail all communications and data exchange between the safety-related RPSIESPS TXS system and any non-safety system, e) How does this meet the Standard Review Plan section 7.9 criterion that the communications systems "does not present an electronic path by which unauthorized personnel can change plant software or display erroneous plant status information to the operators" and "Such connections should be one-way communication paths."

RAI 7a Please provide details on this enhancement, listing what additional information will be available.

October 6, 2005 Page 18 Duke Response to RAI 07a The TXS-OAC Gateway is a rack mountable high performance server, which, on the one side, behaves like a TXS functional processing computer and on the other side behaves like a data acquisition system. On the TXS side, the TXS-OAC Gateway is connected to the TXS Monitoring and Service Interface (MSI) via a fiber-optic data link using the SINEC H1 protocol (industrial Ethernet). The TXS-OAC Gateway software reads the data coming across the link from the MSI and writes data to a memory buffer. The secondary side of the TXS-OAC Gateway executes a custom OPC server application.

This application communicates directly with the OPC client, which in turn communicates with the OAC. The OPC client requests data from the memory buffer of the OPC server and transfers all requested data to the OAC.

The TXS-OAC Gateway can provide approximately 20 new analog signals and 800 new discrete points to the computer interface. The complete listing of additional information that will be provided is still in the process of being developed. The following are several examples of analog points and discrete points that are being considered:

Analocg Points;

  • Upper / Lower Core Flux
  • Loop Flow D/P Channel E Discrete Points:
  • Failure alarms for NI Flux monitoring equipment
  • Trip Status (Auto and manual)
  • TXS Trouble / Deviation Alarms
  • TXS computer change enabled
  • Manual Bypass of components
  • Cross Channel value comparisons
  • Additional channel trip data
  • Gen Turbine EHC Oil Pressure alarms
  • Parameter input limit violation and/or deviation
  • ESPS Voter status
  • RPS Channel Trouble
  • ESPS Channel Trouble
  • RBCU Cooling Fan Status Use of the TXS-OAC Gateway replaces approximately 300 hard wired connections to the plant computer.

October 6, 2005 Page 19 Duke Response to RAI 07b, 7c, 7d, & 7e

[Proprietary Information - Refer to Attachment 2]

RAI 8

a) Please explain how the use of dual port RAM as an interface maintains the requirement for independence? b) Is the safety side input port write only, or the non-safety output port read only? c) How does this prevent cyber intrusion and maintain security of the system?

Duke Response to RAI 8 tProprietary Information - Refer to Attachment 2)

RAI 9

The February 14, 2005, submittal states, in section K, that "The digital upgrade of the RPS and ESPS will not have a significant impact on the Oconee PRA results."

Please provide information on how this determination was reached, including the data used to make this determination. This should be justified keeping in mind that a single hardware failure will disable one channel of all RPS and ESPS functions in which the TXS is used, and one common mode failure could eliminate all RPS and ESPS functions in which the TXS is used.

Duke Response to RAI 9 Due to the redundancy currently designed into the RPS and ESPS, equipment failures within these systems do not contribute to Oconee's PRA results. That is, there are no ESPS failure modes in the current base case PRA results and only one failure mode related to the RPS -- "Insufficient Number Of CRAs Drop Into Core Upon Scram" --

which will still apply after the upgrades. Thus the equipment change-outs would not be expected to have an appreciable or measurable impact on the PRA results. No attempt was made to quantify the impact of any new common cause failure modes associated with the TXS, since the rates for such failures have not been established.

RAI 10

The February 14, 2005 submittal, in section K, refers to "The expected high reliability of the digital actuation systems." What Is the value of this expected high reliability, and how was it determined? How was software reliability calculated, and how was this software reliability included In the expected high reliability value?

October 6, 2005 Page 20 Duke Response to RAI 10 Duke provided a preliminary response to this question on June 30, 2005. After discussions with the staff on August 17, 2005, Duke agreed to revise this response. The response to this RAI is in preparation and will be submitted by November 3, 2005.

RAI 11

In the safety evaluation for EPRI TR-102323, the NRC staff concluded that "TR-102323 provide (sic) an acceptable method for assessing the qualification of digital equipment to the nuclear plant EM environment without the need for plant specific EMI surveys if the plant specific EM environment is confirmed to be similar to that identified in TR-1 02323". Please show how it was determined that the EM environment at Oconee was similar to that Identified in TR-102323.

Duke Response to RAI 11 The EMI/RFI Environment at Oconee was confirmed to be similar to that identified in EPRI TR-102323 by participation in NUREG/CR-6436, uSurvey of Ambient Electromagnetic and Radio Frequency Interference Levels in Nuclear Power Plants,"

USNRC, November 1996. NUREG/CR-6436 describes the ambient EM environments observed at the various nuclear plants surveyed, including Oconee.

In 1995, The U.S. Nuclear Regulatory Commission (NRC) Office of Nuclear Regulatory Research engaged the Oak Ridge National Laboratory (ORNL) to perform measurements to characterize the electromagnetic interference (EMI) and radio-frequency interference (RFI) levels that can be expected in nuclear power plant environments. Based on the results, a set of recommended electromagnetic operating envelopes for safety-related instrumentation and control (I&C) systems in nuclear power plants were proposed in NUREG/CR-6431, "Recommended Electromagnetic Operating Envelopes for Safety-Related I&C Systems in Nuclear Power Plants, " USNRC, April 1999.

Both of the above documents, and EPRI TR-102323, were included as input documents for development of Regulatory Guide (RG) 1.180, "Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety-Related Instrumentation and Control Systems."

The FANP hardware for replacement of the Oconee Reactor Protection System (RPS) and the Engineered Safeguards Protection System (ESPS) is qualified for the EM environment per the guidance of:

1. EPRI TR-1 02323, -Guidelines for Electromagnetic Interference Testing in Power Plants."

October 6, 2005 Page 21

2. EPRI TR-107330, "Generic Requirement Specification for Qualifying a Commercial Available PLC for Safety-Related Applications in Nuclear Power Plants."
3. RG 1.180, "Guidelines for Evaluating Electromagnetic and Radio-Frequency Interference in Safety-Related Instrumentation and Control Systems."
4. RG 1.89, "Qualification of Class 1E Equipment for Nuclear Power Plants."

and other supporting standard, guides, procedures and documents.

Duke concludes that participation in the confirmatory NRC NUREG based activities provides substantial evidence of meticulous determination and verification of a similar EM environment to that identified in TR-1 02323.

RAI 12

The February 14, 2005, submittal states that TXS equipment qualification criteria bound the plant specific qualification levels for the applicable locations at ONS.

Please provide the worst case plant specific accident environmental conditions for the locations where the TXS equipment will be located.

Duke Response to RAI 12 The Reactor Protective System (RPS) and the Engineered Safeguards Protective System (ESPS) TELEPERM TXS cabinets will be located within each Unit's Main Control Rooms, which are located in the Auxiliary Buildings for Oconee Units 1, 2, and 3.

Duke has established the specific Oconee plant areas which are identified as "harsh" environments. The TELEPERM TXS cabinets will not be located in a designated "harsh" environment area. The Control Room is exempt from EQ requirements because it has a controlled environment and is protected from harsh post-accident environment.

The following environmental (temperature and humidity) data for the Control Room is provided:

ENVIRONMENTAL TEMPERATURE RELATIVE CONDITION (OF) HUMIDITY (%)

Normal 74 30-80 Design Basis Accident 60-100 30-80 The radiation doses in Oconee Control Rooms are 100 rads or less for the accident analysis.

October 6, 2005 Page 22

RAI 13

The February 14, 2005, submittal, in response to plant specific requirement 9, as listed in the NRC staff SER on the TXS Topical Report, stated that "The Oconee AMSAC and DSS systems' attributes have been evaluated for diversity between them and the TXS based RPS/ESPS for the categories of Design Diversity, Human Diversity, Equipment Diversity, Software Diversity, Functional Diversity, and Signal Diversity." Please provide that evaluation.

Duke Response to RAI 13 There is not a separate diversity evaluation. Page 25 of Attachment 3 of the February 14, 2005, submittal states that the AMSAC and DSS systems' attributes have been evaluated for diversity between them and the TXS based RPS/ESPS for these categories. The subsequent two paragraphs after this statement provide this "evaluation."

The March 20, 2003, Defense in Depth & Diversity (D3) Assessment also provides such an evaluation for AMSAC and DSS in Section 6.3 of the Attachment, along with other diverse systems credited in the D3 assessment.

RAI 14

The submittal, in response to plant specific requirement 12, as listed in the NRC staff SER on the TXS Topical Report, stated that a plant specific risk informed Defense-in-Depth and Diversity assessment to justify eliminating the need to install the diverse LPI actuation in early 2005. Please provide that assessment, keeping in mind that NRC has neither reviewed or approved the EPRI report 1002835, "Guideline for Performing Defense-in-Depth and Diversity Assessments for Digital Upgrades."

Duke Response to RAI 14 Duke has deferred the submittal date for the risk informed D3 assessment. As indicated in the February 14, 2005, submittal and the April 6, 2005, meeting, the risk informed assessment would be used to eliminate the need to install a diverse LPI actuation system on the two follow on Oconee Units and maintain the diverse LPI actuation systems for the remaining life of the plant. Duke plans to install a diverse LPI actuation system for Oconee Unit 1 in the Fall 2006 outage and will install in the remaining two Units if necessary. Duke will be mindful that the NRC has neither reviewed nor approved the EPRI report 1002835 in any risk informed D3 assessment performed.

During the August 17, 2005, RAI meeting, the NRC reviewer requested Duke to provide the design details for the diverse LPI actuation system. Duke provided the design requirements for that system during a November 17, 2004 Duke/NRC meeting. NRC concurred in that meeting as documented in NRC letter dated January 3, 2005 that the October 6, 2005 Page 23 design requirements presented were appropriate for the DLPIAS. The Duke design requirements for the DLPIAS are as follows:

The DLPIAS will use analog bi-stable trip units and 2 out of 3 relay logic actuated on Low RCS Pressure. See Figure below.

(new Wndow) > ie Dies AP Diver.

Bypassed Ti Proposed Diverse LPI Actuation System Compliance to the Design Requirements for DLPIAS:

The DLPIAS design requirements are listed below. Where appropriate, a statement of how the DLPIAS will comply with these design requirements is made.

1. The system shall be of sufficient quality to perform the necessary function under the associated event conditions and within the required time (BTP HICB-1 9 B.1)
  • The proposed system will be a combination of Safety and Non-Safety Related components. The interface with the LPI actuation circuit and the LPI Diverse Disable switch will be Safety related. The bi-stable devices, two out of three logic relays, annunciator circuits will be supplied as non safety related and wired for separation accordingly. The power for the bi-stables and relay logic will be non safety related.
  • The quality of the components will be based on selection of known components that have a proven reliability. The relays and disable switch October 6, 2005 Page 24 selected will be the same as those supplied for the ES actuation circuits. The bi-stables will be standard commercial grade quality.
2. Automatic and manual actuation capability.
  • The DLPIAS will provide for automatic actuation of the Channel 3 and Channel 4 components. This includes LPI pumps, LPSW pumps and LPI Injection valves.
  • Manual initiation is accomplished with the existing Trip/Reset buttons located on the main control board. The logic for this manual trip bypasses the TXS logic and allows the Operator to initiate ES actuation on a per channel basis.
3. Actuate LPI on Low RC Pressure or High Reactor Building Pressure
  • DLPIAS will actuate only on Low Reactor Coolant Pressure. The basis for this is the DLPIAS is intended to provide automatic LPI injection to cover the case of the Large Break Loss of Coolant Accident (LBLOCA) in case the TXS has a common mode software failure. The loss of coolant pressure is the most appropriate indication that a LBLOCA has occurred.
4. Accuracy - Setpoints will be chosen that permit ESPS Actuation prior to DLPIAS actuation including instrumentation loop error.
  • The Setpoint of the DLPIAS will be chosen to allow the ESPS to actuate first.

Because the DLPIAS is backup for LBLOCA the setpoint selected will be based on the relationship of the maximum LPI pump developed head and accuracies of the instrumentation.

5. Minimize Inadvertent Actuation - Use multi-channel logic in "an actuate to initiate" manner. For example; 2 out of 2 channels required
  • The 2 out of 3 logic will minimize inadvertent actuations. Actuation circuit relays are energized to actuate. Loss of power will not result in actuation.

The 2 out of 3 logic will revert to a 2 out of 2 when a transmitter is taken out of service.

6. Diverse Hardware and Software required - both analog and digital applications are acceptable provided diversity is maintained
  • Diverse hardware (bi-stables) is being provided. No Software is being provided for the DLPIAS.
7. Diverse Sensors not required - Follow BWOG AMSAC/DSS guidance if using existing RPS/ESPS sensors October 6, 2005 Page 25
  • The Reactor Coolant Pressure signals will be isolated from the safety related signals utilizing the TXS SNV1 isolators. The signal split is on the front end of the TXS and is not affected by the software of the TXS computers.
8. Diverse power source to RPS/ESPS not required. Battery backup not required
  • The power will be from the same 120 VAC supplied to Channel E of the RPS.

This power is non-safety related, fed from inverter 1(2,3) Kl.

9. Physical Separation not required
  • Physical separation will be maintained as it relates to IEEE -384 separation criteria between safety related and non-safety components. The bi-stables and relays will be DIN Rail mounted components.
10. Electrical Separation is required. Electrical separation per ONS requirements.
  • Electrical separation between safety and non-safety will be maintained by the use of qualified isolators and relays.
11. Safety to Non-Safety Isolation required. Isolation required to meet ONS criteria and guidance.
  • Physical separation will be maintained as it relates to IEEE -384 separation between safety related and non-safety components. Electrical separation between safety and non-safety will be maintained by the use of qualified isolators and relays.
12. Equipment must be qualified for its intended location. All logic equipment shall be located in a Mild Environment.
  • All equipment associated with the DLPIAS system with the exception of the transmitters and cabling (which is Environmentally Qualified) is located in the Control Room and will be qualified for the environment based on manufacturer product specification sheets.
13. Operating Bypasses or Maintenance Bypasses

>Appropriate Operating and or Maintenance Bypasses must be determined.

>Appropriate human factors and task analyses performed along with OPS training to prevent inadvertent bypassing

>Administrative procedures used to address Operating Bypass

  • The Diverse LPI Disable Switch will be used to bypass the DLPIAS system for both maintenance and operations. The procedures will require that the DLPIAS be bypassed on controlled shutdowns at the same time the LPI Bypass is initiated for the ESPS.

October 6, 2005 Page 26

14. DLPIAS Actions go to completion once initiated - reset controlled by procedure.

same as existing ESPS

  • The above criteria and requirements will be met.
15. Information Readouts provided in Control Room for Operator awareness and system monitoring shall be the same as during normal operation.
  • Existing readouts utilized. No additional indicators will be provided.
16. Augmented Quality Program (GL85-06) is not required. Non Safety Related commercial industrial products consistent with application are acceptable.
  • There are no unique or special procurement requirements.
17. Software Quality Assurance
  • The DLPIAS design will not require the use of any software.

RAI 15

The submittal, in response to plant specific requirement 14, as listed in the NRC staff SER on the TXS Topical Report, stated: "The power supplies will be commercially dedicated and qualified by Framatome ANP for this ONS safety related, Quality Condition 1 application". Please provide the test plans, procedures and reports.

Duke Response to RAI 15 The response to this RAI is in preparation and will be submitted by December 1, 2005.

RAI 16

The submittal, in response to plant specific requirement 14, stated: "The TXS communication from the safety l&C system to the non-safety plant information system is done via the Monitoring and Service Interface (MSI)". Please describe this communications link, and the manner in which it maintains isolation? Is this a communications path a broadcast type one-way communication path used without handshaking or acknowledgment signals? If the communications is not a broadcast, please explain the cyber security provisions used by the TXS RPS/ESPS system.

October 6, 2005 Page 27 Duke Response to RAI 16 The communications link between the plant information system and the MSI is via a TXS-OAC Gateway using an Ethernet connection. Physical and electrical isolation is maintained by fiber optics link. Communications isolation will be maintained by the hardware. The hardware will be configured to be half duplex; the MSI will be able to transmit data to the TXS-OAC Gateway, but will not have a physical connection that allows the TXS-OAC Gateway to transmit data to the MSI.

The communications path will be a broadcast type one-way communication path. The transmission of data from the MSI to the TXS-OAC Gateway/ plant information system will use half duplex communications. This configuration will be maintained via hardware.

The transmission path from the TXS-OAC Gateway to the MSI will be physically disconnected so that it is physically impossible for the TXS-OAC Gateway to transmit data to the MSI.

RAI 17

How is access control for the TXS cabinets maintained? Who controls the keys?

Please provide a proposed access list or the access list for physical access to the existing cabinets. This should be in sufficient detail to allow the NRC staff to make a determination of the physical security of the TXS system.

Duke Response to RAI 17 Access is controlled administratively by an Oconee Operations Management Procedure (OMP) for lock and key control. Testing, maintenance, or modification work requiring access to the RPS/ESPS cabinets must be approved by the Work Control Center (WCC)

Senior Reactor Operator (SRO). The keys to these cabinets are controlled by the WCC SRO and are issued by him to allow the approved work. There is not an approved access list. Access is on an as required basis and must be approved for each work task.

Keys for access to these cabinets during an emergency are also located in the Control Room (CR). These keys are controlled by the CR SROs and ROs.

RAI 18

Please discuss the response time requirements for the RPS/ESPS functions. What is the expected worst case response time for the TXS systems as it will be installed at Oconee, and how will that response time be tested at ONC (sic)? This should include a discussion of the microprocessor cycle times, sampling rates, and testing procedures. In addition, please provide the system response time reports as discussed in specification item 6.14.

October 6, 2005 Page 28 Duke Response to RAI 18 The minimum response time requirements are listed in specification item 6.14. The response to this RAI is in preparation and will be submitted by January 12, 2006. FANP is required to provide the System Response Time test reports to Duke for approval and acceptance prior to beginning the SAT. FANP will perform response time testing during the FAT. Duke will provide the system response time reports coincident with the FAT report (expected to be issued by May 4, 2006).

RAI 19

What provisions for repair parts has been made? How many spare boards and modules will be delivered with the system? For what period of time has Framatome guaranteed that additional parts of the same revision level as the original be available? If parts are received with a different revision level, how will they be evaluated, and under what conditions will NRC approval be required?

This should include the list of recommended spare parts as required by specification item 15.

Duke Response to RAI 19 Both equipment purchase specifications (OSS-0311.00-00-0012, R01 & OSS-0311.00-00-0013, R01) contain provisions for the procurement of spare parts. Oconee will identify, with FANP input, the spare parts requirements for the replacement RPS and ESPS. Oconee will then place a purchase order with FANP for procurement of the finalized spare parts inventory. This spare parts order will be sufficient to initially support all three (3) Oconee operating units. The equipment specifications require that FANP guarantee the availability of any supplier-manufactured part for twenty (20) years from the date of the last Site Acceptance Test (SAT) completion. FANP has agreed to support the 20 year requirement. Future spare parts provided by FANP have been guaranteed to be of the applicable revision level or to be backward compatible (including documentation of such compatibility) in the event of a part revision number change or obsolescence. Oconee will respond accordingly, maintaining appropriate site documentation, to show interchangeability, replacement or equivalency.

During the August 17,2005, Duke/NRC RAI meeting, Duke agreed to provide an initial spare parts list. An initial recommended spare parts list was provided in electronic format to the NRC staff via electronic mail on September 30, 2005. Duke requests it be withheld from public disclosure pursuant to 10 CFR 2.390.

October 6, 2005 Page 29

RAI 20

Please show how and where the software under configuration management is stored, and who the software librarian is. Is the librarian designated by name, or by some other means?

Duke Response to RAI 20 At Oconee, software under configuration management is stored in the Document Control Records Management (DCRM) vault in the Oconee Office Building. The software librarian is the DCRM supervisor. The SDQA document, required to be prepared by the Nuclear System Directive (NSD) for safety related software, identifies the software elements to be controlled and the documents that they will be controlled through. These documents along with the software are transmitted to DCRM to retain and control.

Duke defines the requirements for configuration management of Structures, Systems and Components (SSC), including software, at its nuclear facilities in an NSD that addresses configuration management requirements. Further guidance on configuration management of software is given in the NSD for Duke's Software and Data Quality Assurance (SDQA) Program. This NSD requires the preparation of a Software and Data Quality Assurance (SDQA) document for safety related software. The SDQA document contains both the elements of the software and data quality assurance plan and also the elements of the configuration management plan.

Duke's NSD for Document Control designates the DCRM Supervisors and their staffs, as custodial owners, having overall responsibility for the physical control of software at ONS. Duke's NSD for Records Management requires permanent records to be stored in a facility (vault) which is designed to criteria specified in Reg. Guide 1.88, except as noted in the QA Topical, Table 17-1, to protect records from loss.

RAI 21

Please discuss what provisions have been made for the repair and maintenance of components, PC boards and software. This should Include a copy of the Software Maintenance Plan, which itself should meet the requirements of SRP BTP-14, Section 3.1.f.

RAI 22

Will ONC (sic) or Framatome modify software if errors are discovered? How will those modifications be tested, both by the organization making the changes and by the licensee?

October 6, 2005 Page 30 Duke Response to RAI 21 and 22 Duke discussed the preliminary response provided to the draft RAI in the August 17, 2005, Duke/NRC RAI meeting and agreed to revise this response. This response is in preparation and will be submitted by November 3, 2005.

RAI 23

Will all documentation, training manuals, software listings, screen data and error messages be in English? Where is the application specific software being developed and tested?

Duke Response to RAI 23 Documentation, training manuals, software listings, screen data and error messages will be in English.

The application specific software is being developed and tested at the FANP facility in Alpharetta, GA. and at Oconee Nuclear Station.

RAI 24

In attachment 3, Figure 1, there are two cabinets labeled "Status (Cab 8)" and "Status (Cab 9)". Please describe the functions performed by each. What hardware and software will be used in these functions, and how will each be qualified?

Duke Response to RAI 24

[Proprietary Information - Refer to Attachment 2]

RAI 25

In the same figure 1, the fifth bullet states "One RPS computer ("RPS-E")

providing information to the control board and the Integrated Control System (ICS) and implementing the functions of the TXS Monitoring and Service Interface (MSI)." Please describe RPS-E fully, including function, hardware, software, interconnects, and qualification.

Duke Response to RAI 25

[Proprietary Information - Refer to Attachment 2]

October 6, 2005 Page 31

RAI 26

In figure 2 there is an input described as "RPS Input Channel E". Please state where this input is from, and what function it performs.

Duke Response to RAI 26

[Proprietary Information - Refer to Attachment 2]

RAI 27

Please show how the Teleperm XS RPS/ESPS system as installed at ONC (sic) will comply with the following sections of IEEE Std. 603-1991 (as required by 10 CFR 50.55a). If this information is already contained in sufficient detail in the February 14, 2005 submittal, please reference the section of the submittal where the information is discussed.

Section 4.1 Identification of the design basis events Section 4.4 Identification of variables monitored Section 4.5 Minimum criteria for manual initiation and control of protective actions Section 4.6 Identification of the minimum number and location of sensors Section 4.4 Identification of the analytical limit associated with each variable.

Section 4.7 Range of transient and steady-state conditions Section 4.8 Identification of conditions having the potential for causing functional degradation of safety system performance Section 4.9 Identification of the methods used to determine reliability of the safety system design Section 5.1 Single-Failure Criterion Section 5.2 Completion of Protective Action Section 5.3 Quality Section 5.4 Equipment Qualification Section 5.5 System Integrity Section 5.6 Independence

  • Physical independence.
  • Electrical independence.
  • Communications independence.

Section 5.7 Capability for Test and Calibration Section 5.8 Information Displays Section 5.9 Control of Access Section 5.10 Repair Section 5.11 Identification Section 5.12 Auxiliary Features October 6, 2005 Page 32 Section 5.13 Multi-Unit Stations Section 5.14 Human Factors Considerations Section 5.15 Reliability Sections 6.1 and 7.1 Automatic Control Sections 6.2 and 7.2 Manual Control Section 6.3 Interaction Between the Sense and Command Features and Other Systems Section 7.3 Completion of Protective Action Section 6.4 Derivation of System Inputs Section 6.5 Capability for Testing and Calibration Sections 6.6 and 7.4 Operating Bypasses Sections 6.7 and 7.5 Maintenance Bypass Section 6.8 Setpoints Section 8 Power Source Requirements Duke Response to RAI 27 During the August 17, 2005 Duke/NRC RAI meeting, the NRC reviewer indicated that the timing of this response was not critical to his review and that Duke could provide in the next month or two. Based on this input Duke re-prioritized our RAI response schedule.

The response to this RAI is in preparation and will be submitted by December 1, 2005.

RAI 28

Please show which functions applicable to other users (specification item 5.4.1) were removed from the ONC (sic) software.

Duke Response to RAI 28 Oconee's software never contained any other users' software. Therefore, it wasn't necessary to remove any software. Oconee's application software was constructed from the ground up to Oconee specific requirements and as a result, other than common platform operating software, only contains software specific to Oconee.

RAI 29

The SRP chapters 7.2, "Reactor Trip System," and Chapter 7.3, "Engineered Safety Features System," require specific comments In the NRC staff SER on compliance with 10 CFR Part 50, TMI action requirements, and various other General Design Criteria. Please show how the TXS RPSIESPS system as installed at ONC (sic) will comply with these requirements. If this information is already contained in sufficient detail in the February 14, 2005, submittal or in other October 6, 2005 Page 33 documents previously submitted to the staff, please reference where the information is discussed.

Duke Response to RAI 29 The response to this RAI is in preparation and will be submitted by December 1, 2005.

RAI 30

In order to show that the software and hardware being used for the RPS/ESPS TXS system as it will be installed at ONC (sic) is being designed, manufactured and tested in the same manner as was originally reviewed and approved by the NRC staff In the TXS SER, please list all Framatome procedures, manuals, specifications, and software and hardware design tools which have been modified or changed since the original SER. Provide sufficient details, including the change control documentation, on these changes that the NRC staff may determine that the changes do not invalidate any conclusions reach by the NRC staff on the acceptability of the original items.

Duke Response to RAI 30 This response will also address RAI 3, 4A and 4C. The response to this RAI is in preparation and will be submitted by December 1, 2005.

RAI 31

Please show the history of the TXS operating system:

A. In how many applications has the operating system been used in the past, and for what period of time?

B. Has there ever been a failure to perform the assigned function?

C. How many of these uses in the past have been at international nuclear power plants and how may (sic) at U.S. nuclear power plants?

Is the operating system version to be used In the ONC (sic) RPS/ESPS TXS system the same as the version originally approved in the April, 2000, SER on the TXS topical report? If not, please provide the following Information:

D. What changes have been made to the operating system originally approved?

E. How often has the version to be used with the ONC (sic) RPS/ESPS TXS system been used and for what period of time?

October 6, 2005 Page 34 F. Has there ever been a failure of the version to be used with the ONC (sic) RPS/ESPS TXS system to perform the assigned function?

G. How many of these uses of the version to be used with the ONC (sic)

RPS/ESPS TXS system have been at International nuclear power plants and how many at U.S. nuclear power plants?

Duke Response to RAI 31 The response to this RAI is in preparation and will be submitted by December 1, 2005.

October 6, 2005 Page 1 List or NRC Commitments RAI Commitment RAI 1.C, 11.D, & The final approved SDQA document is in preparation, review and 1.E approval and is expected to be issued by December 1, 2005. Duke will provide the final approved plan when is issued.

RAI 11.F The Software Safety Analysis Plan is in preparation, review, and approval and is expected to be issued by October 31, 2005. Duke will provide a copy of the plan when is issued.

RAI 1.H These documents are in preparation, review, and approval and are expected to be issued by the dates indicated below:

iv. Implementation Specification January 28, 2006

v. Integration Plan November 30, 2005 vi. Test Plan November 30,2005 Duke will provide these documents when they are issued.

RAI 1.1 Software Design Reviews and Source Code Reviews are performed in later Software Life-cycle phases and are expected to be issued by October 31, 2005, and December 16, 2005, respectively. Duke will provide these documents when they are issued. The Verification and Validation Report is being provided in phases and are in preparation, review, and approval and are expected to be issued by:

1) design phase - November 15, 2005
2) implementation - January 30, 2006
3) testing phase - May 4, 2006 Duke will provide these reports when they are issued.

RAI 1.J The FAT Plan, FAT Procedure, and FAT Report are expected to be issued by the dates indicated below:

FAT Plan November 30, 2005 FAT Procedure February 28, 2006 FAT Report May 4, 2006 Duke will provide the FAT Plan, Procedure, and Report when issued.

October 6, 2005 Page 2 List of NRC Commitments RAI 1.J The Site Acceptance Test (FAT) Plan, SAT Procedure, and SAT Report are expected to be issued by the dates indicated below:

SAT Plan February 28,2006 SAT Procedure March 28, 2006 SAT Report June 30, 2006 Duke will provide the SAT Plan, Procedure, and Report when they are issued.

RAI 1.K The Oconee User Instruction Manual is in preparation, review, and approval and is expected to be issued by December 15, 2005. Duke will provide this document when it is issued.

RAI 1X.K Duke will submit an explanation of what training has been provided by FANP to Duke by November 3, 2005.

RAI 1.KTraining for control room operators, l&C maintenance personnel and plant engineering is being developed as part of the modification process. Duke will provide additional explanation of this training by January 12, 2006.

RAI 1.L The requirements matrix is a living document, and is updated at the end of each V&V phase. Duke expects to issue the next updates by February 14, 2006, and May 4, 2006. Duke will provide these updates when they are issued.

RAI 1.0 The FMEA is in preparation, review, and approval and is expected to be issued by November 30, 2005. Duke will provide a copy of the FMEA when it is issued.

RAI 1.Q These calculations (Setpoint) require revision as a result of the RPS/ESPS digital modification. The revised calculations will address any margin gains or losses. The required revisions are in preparation, review, and approval and are expected to be issued by December 31, 2005. Duke will provide a summary of the results of the revised calculations when issued.

11.R Additional information related to the qualification of the SIVAT simulation tool is in preparation and will be submitted as a revision to this RAI response by December 1, 2005.

1.T The Software Installation Plan is in preparation, review, and approval and is expected to be issued by November 30, 2005.

October 6, 2005 Page 3 List of NRC Commitments 1.U The Software Safety Plan is in preparation, review, and approval and is expected to be issued by November 30, 2005.

1.V Duke will provide a date when Software Operations Plan can be provided by November 3, 2005.

4.B & 4.C The response to RAI 4.A and 4.C will be included in Duke's response to RAI 30. The response to RAI 4.B is in preparation and will be submitted by November 3, 2005.

6 Duke will respond to the question related to channel independence in our response to RAI-27.

6 Duke's response to the question related to communications and data exchange is in preparation and will be submitted by November 3, 2005.

7c Duke will submit more information regarding the hardware solution by November 3, 2005.

10 Duke provided a preliminary response to this question on June 30, 2005. After discussions with the staff on August 17, 2005, Duke agreed to revise this response. The response to this RAI is in preparation and will be submitted by November 3, 2005.

15 The response to this RAI is in preparation and will be submitted by December 1, 2005.

18 The response to this RAI is in preparation and will be submitted by January 12, 2006. Duke will provide the system response time reports to NRC (expected to be submitted by May 4, 2006).

21,22 Duke discussed the preliminary response provided to the draft RAI in the August 17, 2005, Duke/NRC RAI meeting and agreed to revise this response. This response is in preparation and will be submitted by November 3, 2005.

27 The response to this RAI is in preparation and will be submitted by December 1, 2005.

29 The response to this RAI is in preparation and will be submitted by December 1,2005.

30 The response to this RAI is in preparation and will be submitted by December 1, 2005.

Attachment 3 October 6, 2005 Page 4 List of NRC Commitments 31 The response to this RAI is in preparation and will be submitted by I I December 1, 2005.

October 6, 2005 Page 1 Affidavit of Gayle F. Elliott

AFFIDAVIT COMMONWEALTH OF VIRGINIA )

) ss.

CITY OF LYNCHBURG )

1. My name is Gayle F. Elliott. I am Manager, Product Licensing in Regulatory Affairs, for Framatome ANP ("FANP"), and as such I am authorized to execute this Affidavit.
2. I am familiar with the criteria applied by FANP to determine whether certain FANP information is proprietary. I am familiar with the policies established by FANP to ensure the proper application of these criteria.
3. I am familiar with Framatome ANP, Inc.'s input to the responses in of the letter to the NRC Document Control Desk from R.A. Jones, Vice President Oconee Nuclear Site, dated October 6, 2005 and entitled "Response to Request for Additional Information Pertaining to the License Amendment Request (LAR) for RPS/ESPS Digital Upgrade," Technical Specification Change (TSC) Number 2004-09, Supplement 1, and referred to herein as "Document." Information contained in this Document has been classified by FANP as proprietary in accordance with the policies established by FANP for the control and protection of proprietary and confidential information.
4. This Document contains information of a proprietary and confidential nature and is of the type customarily held in confidence by FANP and not made available to the public.

Based on my experience, I am aware that other companies regard information of the kind contained in this Document as proprietary and confidential.

5. This Document has been made available to the U.S. Nuclear Regulatory Commission in confidence with the request that the information contained in this Document be withheld from public disclosure.
6. The following criteria are customarily applied by FANP to determine whether information should be classified as proprietary:

(a) The information reveals details of FANP's research and development plans and programs or their results.

(b) Use of the information by a competitor would permit the competitor to significantly reduce its expenditures, in time or resources, to design, produce, or market a similar product or service.

(c) The information includes test data or analytical techniques concerning a process, methodology, or component, the application of which results in a competitive advantage for FANP.

(d) The information reveals certain distinguishing aspects of a process, methodology, or component, the exclusive use of which provides a competitive advantage for FANP in product optimization or marketability.

(e) The information is vital to a competitive advantage held by FANP, would be helpful to competitors to FANP, and would likely cause substantial harm to the competitive position of FANP.

7. In accordance with FANP's policies governing the protection and control of information, proprietary information contained in this Document has been made available, on a limited basis, to others outside FANP only as required and under suitable agreement providing for nondisclosure and limited use of the information.
8. FANP policy requires that proprietary information be kept in a secured file or area and distributed on a need-to-know basis.
9. The foregoing statements are true and correct to the best of my knowledge, information, and belief.

SUBSCRIBED before me this day of lo lee r , 2005.

Brenda C. Maddox NOTARY PUBLIC, COMMONWEALTH OF VIRGINIA MY COMMISSION EXPIRES: 7/31/07