ML053400247

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 2

ML053400247
Person / Time
Site:	Oconee
Issue date:	11/03/2005
From:	Rosalyn Jones Duke Power Co
To:	Document Control Desk, Office of Nuclear Reactor Regulation
References
Download: ML053400247 (34)

Text

RONALD A JONES Duk Vice President ftowPower, Oconee Nuclear Site Duke Power ONOI VP / 7800 Rochester Hwy.

Seneca, SC 29672 864 885 3158 864 885 3564 fax November 3, 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 2 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 October 6, 2005, Duke provided responses to many of the questions in an NRC Request for Additional Information (RAI) dated September 6, 2005. Since many of the responses are tied to design deliverables in the RPS/ESPS modification schedule, Duke committed to provide the remaining responses on or before November 3, 2005, December 1, 2005, and January 12, 2006.

Attachments 1 and 2 provide Duke's responses to RAIs 1.F, l.K, 1.R, 1.V, 4.a, 4.b, 4.c, 6, 7.c, 8.c, 10, 15, 16, 21, 22, 28, 29, 30 and 31. Attachment 3 provides an updated list of NRC commitments associated with this LAR.

Attachment 2 contains information proprietary to Framatome ANP (FANP). An affidavit from Framatome ANP (FANP) is included as Attachment 4. This affidavit sets forth the www.dukepower.com

U. S. Nuclear Regulatory Commission November 3, 2005 Page 2 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 r ly yours, R. A.Jones, Vice President Oconee Nuclear Site

U. S. Nuclear Regulatory Commission November 3, 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 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 November 3, 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 k edge.

R. A. n , Vice President Ocon e Nuclear Site S bscribed and sworn to before me this 'J day of

( zaAit'kj 2005

/fotary Public My Commission Expires:

>0 .

November 3, 2005 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.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 FANP process for meeting the requirements of BTP-14, Section 3.2.a is documented in 'ONS 1 RPS/ESFAS Controls Upgrade Software Safety Plan" (FANP Document # 51-9005043-000) provided in the response to RAI 1.U. As required by BTP-1 4, this plan includes safety analysis activities and documentation for each life cycle phase. Since software safety activities are an integral part of the entire design process and each life cycle phase is analyzed to determine that no new hazards are introduced by the design process, there is no single document that includes all safety analysis activities.

Safety analysis activities include the following as described in the Software Safety Plan:

• Conceptual Phase o A Diversity and Defense-in-Depth (D-in-D &D) analysis is conducted and documented in the D-in-D&D Analysis Report - The D-in-D &D Analysis performs activities that are equivalent to developing the Preliminary Hazards List (PHL) and analyzing software safety including any hazard that could be created as a result of Software Common Mode Failure (SWCMF).

• Requirements Phase o Software Requirements Specification (SRS) (15-5045380-01) o Functional Requirements Specification (FRS) (32-5061401-01) o SRS V&V Report (51-5066516-01) - The V&V Plan requires the V&V Engineer to evaluate the Software Requirements Phase activities to ensure no new software hazards are introduced. The V&V Engineer's assessment is included in the SRS V&V Report

• Design Phase o FMEA - The FMEA, in addition to analyzing hardware failures, analyzes propagation of failure events through the software.

o Design Verification Checklist (DVC) for the ONS-1 RPS/ESFAS Software Design Description (SDD) (FANP 51-5065423-00) documents that no new software hazards have been introduced as a result of design phase activities.

November 3, 2005 Page 2

• Implementation Phase o The source code and build products are analyzed in this phase to ensure no new software hazards are introduced. The results are documented in the Software Unit Test Report

• Testing Phase o FMEA - The conclusions in the FMEA are verified and tested during FAT Testing o Factory Acceptance Test Report - Documents that the system performs to its requirements and that the testing did not introduce any new software hazards.

Other activities integral to the Design process are:

• The V&V Process - used to assure the system is designed with high integrity and high quality.

• The Requirements Traceability Matrix - used to trace and document that all requirements have been incorporated, tested and meet measurable acceptance criteria.

• The Reliability Analysis - Ensures the system is designed to be highly reliable Duke Response to RAI 1.K Duke contracted FANP to provide the initial system and software training on the TXS.

This includes the following courses:

1. TXS Introduction

2. TXS Hardware

3. TXS Software

4. TXS System Administration A brief discussion of each course is provided below. To date 39 Oconee personnel have been trained on one or more of the courses outlined below.

TXS Introduction Course This course provides an overview of the scope and application for TXS safety-related systems. It is a prerequisite for the hardware, software and system administration courses.

The course is targeted at individuals that need a basic understanding of the TXS system capabilities, structure, and operation. Typical attendees include:

• Management

• Engineering

• Operations

• Maintenance November 3, 2005 Page 3

• Software Engineering

• Quality Assurance

• Procedure Writers The course duration is 2.5 days TXS Hardware Course This course provides insight into the hardware integration, configuration and maintenance. Each module's operation and indications are covered in depth.

This course provides the detailed system knowledge required by personnel involved in maintenance, surveillance, trouble-shooting and those attending the Software Course.

Groups attending this training include:

• Plant Engineering

• Maintenance Technicians

• System Administrators The TXS Hardware course is a prerequisite for the TXS Software Course. The course duration is 7.5 days.

TXS Software Course This course provides an in-depth look at the TXS software. It provides hands-on instruction in use of the Specification and Coding Environment (SPACE) tool for engineers and maintenance technicians. The knowledge gained in this course supports the understanding of:

• Software control functions

• How software parameters replace set-points

• Generation and checking of TXS software

• Testing using digital control technology

• How to change system parameters

• Input/Output channel testing

. Diagnostics Groups attending this training include:

• Plant Engineering

• I&C Technicians

• Computer Engineering The TXS Software Course is a prerequisite for the TXS System Administration Course.

Its duration is 9 days.

Attachment 1 November 3, 2005 Page 4 TXS System Administration Course This course covers TXS system set up and administration and provides an understanding of the server and process computer configuration. It addresses software installation, hierarchy and verification. The course provides an understanding of:

• Application software loading

• System network setup

• Software configuration management - consistency, traceability and reproducibility

• Network setup

• User management

• Platform and Operating system software

• TXS database administration Groups attending include:

• Plant Engineering

• Computer Engineering The course duration is 3 days.

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.

Response to RAI 1.R FANP Report No. NGLP/2004/en/0094, 'TELEPERM XS Simulation - Concept of Validation and Verification" was provided in electronic format to the NRC staff via electronic mail on October 31, 2005. Duke requests that this report be withheld from public disclosure pursuant to 10 CFR 2.390. This report provides a detailed description of FANP's Simulation based Validation Tool (SIVAT) and its application for verification and validation of the TXS application software. The basis for its use is also addressed.

November 3, 2005 Page 5 Section 2.0 of the document provides the description of the tool and its use in the TXS design process. Section 2.4.7 provides an example of the methodology for testing a typical function including sample output data. Section 4.1 describes the processes and procedures used to develop and test SIVAT under the FANP quality assurance program.

Section 4.2 provides a summary of FANP's experience in using SIVAT in the development of TXS application software. The quality assurance process described in Section 4.1 along with the experience documented in Section 4.2 provide basis for FANP's confidence in the use of SIVAT as a verification and validation tool for TXS application software.

The output of SIVAT and analysis of this output for the Oconee TXS will be provided in the Software Unit Test Report. This report will be completed prior to the start of the Oconee TXS integration test and FAT.

RAI 1.U Please provide the following documentation:

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

Duke Response to RAI 1.U Duke provided a copy of the Software Safety Plan in electronic format to the NRC staff by electronic mail on November 2, 2005. Duke requests that this document be withheld from public disclosure pursuant to 10 CFR 2.390.

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 letter dated October 6, 2005, provided an initial response to RAI 1.V indicating that Duke will provide a date when this document can be provided by November 3, 2005.

NSD-800, "Software Data Quality Assurance (SDQA) Program," previously provided electronically to the Staff via electronic mail on May 5, 2005, applies to all software and data used in support of the Nuclear Generation Department (NGD), including software and data currently in use, under development, or in procurement. NSD-800 fulfills the requirements of the Duke Energy Corporation Topical Report, Quality Assurance Program (QA Program,) related to the development, procurement, operation, and maintenance of software and data in support of NGD. The requirements for each application are defined in the Oconee SDQA plan.

The SDQA for the RPS/ESPS application is currently scheduled to be completed by December 1, 2005. Duke will provide a copy of this plan when it is available.

November 3, 2005 Page 6

RAI 4

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:

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

Duke Response to RAI 4.B The response to RAI 4.A and 4.C is included in Duke's response to RAI 30.

Duke provided Certificate # 968/K 109/04 (Report ID 47.47) and Test Report # 968/K 109.01/04 in electronic format to the NRC staff via electronic mail on September 19, 2005 in response to RAI 04D. These documents cover the qualification testing of the SVE2 TXS function computer.

Duke provided Certificate # 968/K 110/02 (Report ID 44.08) in electronic format to the NRC staff via electronic mail on November 2, 2005. Test Report # 968/K 110.00/02 is currently being translated from German to English. Duke will provide this document to the NRC staff when it is available. These documents cover the qualification testing of the SCP2 communication processor.

A qualification summary report addressing Oconee specific equipment such as relays, breakers, transmitters, etc., is in preparation, review and approval and is expected to be issued by November 17, 2005. Duke will provide this document when it is issued.

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

RAI 6

Section 4.9 of topical report EMF-2110 states "Signal transmission between redundant class I E 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.

November 3, 2005 Page 7 RAI 6.a 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?

Duke Response to RAI 6.a The basis for Duke's conclusion that the design complies with IEEE-279-1971 channel independence requirements is provided below by demonstrating how each aspect of the design complies with IEEE standards. In addition, Duke interprets that the NRC originally developed this same conclusion based on the NRC review provided for the TELEPERM XS Topical Report. For the convenience of the reader, Duke has restated the salient conclusions of the Safety Evaluation for the TELEPERM XS that makes this conclusion logical.

Compliance with Standards Standard guidance for channel separation is provided via numerous industry standards, most notably IEEE 603, IEEE 279, IEEE 379 and IEEE 7.4.3.2 and endorsed per NUREG 0800.

IEEE 603 Section 5.1 states:

"Redundantportions of a safety system provided for a safety function shall be independent of, and physically separated from, each other to the degree necessary to retain the capability of accomplishing the safety function during and following any design basis event requiring that safety function."

IEEE 279 section 4.6 States "Channel Independence. Channels that provide signals for the same protective function shall be independent and physically separated to accomplish decoupling of the effects of unsafe environmental factors, electric transients, and physical accident consequences documented in the design basis, and to reduce the likelihood of interactions between channels during maintenance operations or in the event of channel malfunction."

IEEE 379-1998 section 6.3.2.1 states:

"6.2.1 Channels, Interconnections. Interconnections between redundant channels through devices such as data loggers and test circuits are areas where independence could be lost. These interconnections shall be analyzed to assure that no single failure can cause the loss of a safety function. The means for isolating the redundant channels shall be analyzed for single failures that would lead to loss of a safety function.

Lines connecting sensors to the process systems shall be included in the single-failure analysis."

November 3, 2005 Page 8 IEEE 7.4.3.2 Section 5.6 provides further guidance for data communication independence as follows:

'in addition to the requirements of IEEE Std 603-1998, data communication between safety channels or between safety and nonsafety systems shall not inhibit the performance of the safety function."

Finally, IEEE 384 - 1992 defines physical separation criteria for safety systems to ensure physical and electrical isolation.

To meet the single failure criterion of IEEE-603 Section 5.1, the RPS/ESPS maintains independence between the redundant safety channels in accordance with IEEE-603 Section 5.6., IEEE 384-1992, IEEE 279 and IEEE 379.

There are three key aspects of the design that ensure this independence:

• Physical Independence

• Electrical Independence

• Communications Independence Each of these design aspects is discussed below.

In addition a discussion of inter-channel data communication reliability and failure prevention is provided. A summary of the results of the NRC's review of the Teleperm XS Topical Report confirming the acceptability of the methods used to ensure channel independence is also included. The final section of this report describes all inter-channel signals and their function.

Physical Independence Per section 5.6.1 of IEEE 603 physical independence pertains to the ability of the system to function before, during and after design basis events for which its functionality is credited. To ensure independence during adverse environmental conditions, the RPS/ESPS equipment is qualified in accordance with IEEE 323 and IEEE 344.

In addition, physical separation as defined in IEEE 603 is provided via physical barriers and physical separation in accordance with IEEE 384.

Electrical Independence Electrical independence ensures that electrical faults, including conventional electrical hot shorts, which may occur and cause malfunctions in one safety channel cannot propagate to other redundant safety channels. The RPS/ESPS uses fiber optic cables for all cross channel communication between safety channels. Due to their inherent electrical isolation characteristics, fiber optic cables have been used in the nuclear

November 3, 2005 Page 9 industry for many years as an NRC accepted media for compliance to the electrical independence requirements of IEEE-384 and RG 1.75.

For all non-QA external electrical interfaces, not utilizing fiber optic cables, qualified isolation devices are provided.

Communications Independence Communications independence pertains to the ability of computers in different redundant channels to exchange data without adverse interaction. Independence requirements of IEEE 603 do not address communications independence. In fact, as stated in NUREG 0800, Appendix 7.1-C; "(IEEE Std 603 does not directly discuss digital systems. It is supplemented by IEEE Std 7-4.3.2, 'IEEE Standard for Digital Computers in Safety Systems of Nuclear Power Generating Stations, " which provides criteria for applying IEEE Std 603 to computer systems. IEEE Std 7-4.3.2 is endorsed by Reg. Guide 1.152, "Criteria for Digital Computers in Safety Systems of Nuclear Power Plants. " References to IEEE Std 603 in the remainder of this appendix should be read as including IEEE Std 7-4.3.2, Reg. Guide 1.152, and Reg Guide 1.153.)"

Instead, requirements contained in the body of IEEE 7-4.4.2 are supplemented by Annex G of IEEE 7-4.3.2, which was written specifically to define acceptable means for computer communications between channels.

NUREG 0800, Appendix 7.1, Section 5.6 states:

Annex G of IEEE Std 7-4.3.2, as discussed in SRP Section 7.1.11, describes an acceptable means for providing communications independence. The review of communications independence should include confirmation that the routing of signals related to safety maintains (1)proper channeling through the communication systems, and (2) proper data isolation between redundant channels.

Where data communication exists between different portions of a safety system, the analysis should confirm that a logical or software malfunction in one portion cannot affect the safety functions of the redundant portion(s). If a digital computer system used in a safety system is connected to a digital computer system used in a non-safety system, the review should confirm that a logical or software malfunction of the non-safety system cannot affect the functions of the safety system.)

Through the use of buffering circuits, an acceptable method of inter-channel communication prevents adverse interactions such as hand-shaking errors, buffer overloads and processing interrupts. IEEE 74.3.2 Annex G provides Figure G2 as an acceptable method for meeting the separation requirements between safety channels.

That figure is duplicated below:

Attachment I November 3, 2005 Page 10 io munications Isolauion Co~mmunications Isolation Safety Computer In < Imerial Isolation / Sarety Computer In Channel A ok I Channelg Safety Function A

• Communications Path Safi Function B Figure G2-Communication between safety channels (Two-way communication)

The RPS/ESPS uses a similar inter-channel communication method. The figure below depicts the inter-channel communication method used within the RPS/ESPS:

Safety Function A Fiber Optic Cable Safety Function B ES/RPS - Communication between safety channels (Two-way communication)

November 3, 2005 Page 11 The following table compares the components of the RPS/ESPS to Figure G2 of IEEE 7-4.3.2:

IEEE 7-4.3.2 Annex G Figure G2 RPS/ESPS Electrical Isolation Fiber optic cable Buffer Circuit Channel A Prof iBus controller Channel A (Communications module SL21)

Buffer Circuit Channel B ProfiBus controller Channel B (Communications module SL21)

Communication Isolation Channel A Dual Port RAM Channel A (Communications module SL21)

Communication Isolation Channel B Dual Port Ram Channel B (Communications module SI21)

Safety Function A Function Processor Channel A (Controller module SVE2)

Safety Function B Function Processor Channel B (Controller module SVE2)

The RPS/ESPS communication path between two safety processors use SL21 communication interface modules and fiber optic cables to interface between separate safety channel processors. Through the use of dual port RAM (DPRAM), the SL21 interface, the processors can communicate autonomously, so that the safety function processing is not compromised. In addition, the SL21 removes the communication burden from the safety processors.

The DPRAM provides communications isolation by allowing the safety function processor and communications processor to operate completely independently. Data written to the DPRAM by the safety function processor can be read and transmitted at any time by the SL21 communications module. Similarly, data received by the communications module and written to the DPRAM can be read by the safety function processor at any time. Either processor can read and write from/to the DPRAM without any synchronization, control permissives or other interaction between the processors.

This ensures that trip functions within the function processor can operate with no regard to operations of the redundant processors (e.g. no communication handshaking or latencies between channels). This results in cyclical, deterministic and asynchronous performance of all trip functions in all channels.

Data Communication Reliability and Failure Prevention:

[Proprietary Information - Refer to Attachment 2]

November 3, 2005 Page 12 Conclusion Based on the above, Duke concludes that the RPS/ESPS design meets the channel independence requirements of IEEE 279-1971.

Previous NRC Review The Oconee RPS/ESPS uses the same methods to ensure channel independence as were described in the Teleperm XS Topical Report and accepted by the staff in the associated Safety Evaluation Report (transmitted by NRC letter dated May 5, 2000).

Section 5 of that SER, Regulatory Compliance, states the following:

Page 47:

"Section 50.55a(h) of 10CFR endorses IEEE-603, which addresses both system level design issues and quality criteria for qualifying devices. Siemens has addressed these issues in the topical report. The TXS system meets the criteria of IEEE-603 and the supplemental standard IEEE-7-4.3.2-1996. The staff concludes, therefore, that the TXS system is in compliance with this requirement."

Page 49:

"SRP Section 7.1-C provides guidance for evaluation of conformance to IEEE-603.

IEEE-603 provides criteria for l&C systems in general. Reference is made to IEEE-7-4.3.2 for hardware and software issues of digital computers.

To meet the single-failure criterion for U.S. applications, the TXS is applied to four redundant process channels and two trip logic trains for each RPS or ESF actuation function. These redundant channels and trains are electrically isolated and physically separated. Qualified isolation devices have been tested to ensure functional operability when subjected to physical damage, short circuits, open circuits, or credible fault voltages on the device output terminals."

Page 50:

'The independence criterion in the TXS system is met through the redundancy and separation of the Channels. The communication between channels is via fiber optic cable."

Page 51, addressing GDC 22, Protection System Independence:

"The TXS system conforms to the guidelines in RG 1.75 for protection system independence. On the basis of its review, the staff concludes that the TXS system satisfies the requirement of IEEE-603 with regard to system independence. Therefore, the staff finds that the TXS system satisfies the requirements of GDC 22.

November 3, 2005 Page 13 The SER describes the NRC's review of the 2nd Min/Max logic in various sections:

Section 2.0:

'the signal on-line validation uses a 2nd minimum (or 2nd maximum) principle.

For a redundant measurement system, each protection channel uses the 2nd lowest measurement to compare the low setpoint value and then determines the partial trip status of that channel for a "low trip"parameter. Similarly, it uses 2nd highest measurement to compare the high setpoint value and then determines the partial trip status of that channel for a "high trip"parameter. This method will reject the outlying signal in the process measurement and thereby minimize inadvertent trips.'

Section 2.2.1.1:

"The RTE software automatically marks the invalid message and all signals stored in this message with the ERROR status flag. Signals marked with ERROR status flag are excluded from further processing by the function blocks. For example, a "2-out-of-4" voting function block will calculate a "2-out-of-3" function of the remaining 3 input signals, if one input signal is marked with the ERROR status flag. For example, a "2.MAX" analog signal selection block function block will select:

• The "2nd highest" signal of the remaining 3 input signals, if one input signal is marked with ERROR status flag.

• The "2nd highest" signal of the remaining 2 input signals (that means the lowest one), if two input signals are marked with ERROR status flag.

• The remaining input signal, if three input signals are marked with ERROR status flag.

The safety function can be postulated to be lost only if all of the incoming data is old or corrupt. For this case a fail-safe state of the function can be designed on the application software level. In all other cases (loss of 1, 2, or 3 inputs signals) the function will be executed correctly based on a reduced set of available input information. As soon as the communication failure is repaired (that means, the receiving CPU finds new and consistent data in the dual port RAM), the ERROR status for the incoming data will be automatically reset and this data will be used for function processing. No manual initialization is necessary."

Section 2.2.1.2:

"In nuclear power plant safety systems, safety-related values are acquired and processed in redundant channels. One way TXS systems process redundant signals is to use the signals to determine a real time best-estimate representation of the actual process being measured. The process for obtaining the best-estimate value is usually by voting the appropriate signals and then selecting the best-estimate value from the results of this voting. For example, the voting process could use the second highest value of four signals for selecting the

November 3, 2005 Page 14 signal to be used for actuating a safety system on a high-trip setpoint. This process also allows the system to monitor the consistency of the signals. All failures that do not result in a "frozen" value can be detected with redundant measured value processing."

Section 4.4:

'The second audit of requirements conducted by the staff involved the 2.MIN function module life cycle process. The purpose of this software module is to select a signal from a group of signals for subsequent use in a function group.. .the source code was consistent with the documentation.'

Conclusion Based on the above, Duke concluded that the NRC review found that the TELEPERM XS system met channel independence requirements.

RAI 6.b Please describe in detail all communications and data exchange between channels.

Duke Response to RAI 6.b

[Proprietary Information - Refer to Attachment 2]

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

c) "in addition, please show how isolation is maintained"

RAI 8

...dual port RAM... c) How does this prevent cyber intrusion and maintain security of the system?

Duke Response to RAI 7c and 8c In the October 6, 2005 LAR Supplement 1, Duke committed to submit more information regarding the hardware solution by November 3, 2005. Duke provided additional information regarding the proposed hardware solution to ensure TXS cyber security is November 3, 2005 Page 15 maintained via electronic mail on October 25, 2005. The hardware solution negates the question related to dual port RAM.

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?

Duke Response to RAI 10 TELEPERM TXS Software and Hardware Reliability are discussed in Attachment 3 (Section N, page 36) to the February 14, 2005 submittal, and in Section 2.4 of the TXS Topical Report. Minimum reliability goals for the TXS RPS and ESPS were established in the "RPS Replacement Project Specification" (Ref. 1) and the "ESFAS Replacement Project Specification" (Ref. 2). Expressed in terms of operational unavailability, the goals were defined as <1.OE-05.

Hardware Reliability A detailed hardware reliability analysis has been completed following the guidance in IEEE STD 352-1987 and IEEE STD 577 - 1976. The methodology and results of the analysis are documented in the UTXS Hardware Availability Analysis." The analysis uses theoretical failure rate data specific to the TXS components being used in the Oconee RPS/ESPS.

The limiting analysis result of the hardware failure on demand unavailability for RPS is 5.44E-10 per demand, for a typical loss of feed water event, considering that for each DBE, there is both a primary and at least one backup trip function. For the ESPS, the calculated hardware failure on demand unavailability is 2.8E-05 per demand, per logic channel.

Software ReliabilitV Currently there is no industry consensus or standards governing the methodology or procedures for quantitatively analyzing software reliability. As such, software reliability is not included in the TXS hardware reliability analysis.

Regulatory Guide 1.152, uCriteria for Digital Computers in Safety Systems of Nuclear Power Plants," and IEEE 7-4.3.2-1993 requires when qualitative or quantitative goals are required to be met both hardware and software reliability must be included. However, the methodology used to determine reliability can be qualitative, including a combination of analysis, field experience or testing. The reliability of the TXS software has been addressed qualitatively in the detailed Defense-In-Depth & Diversity Assessment and

November 3, 2005 Page 16 the Failure Modes and Effects Analyses for the Oconee TXS system. In addition, the system will undergo extensive testing prior to installation.

Software is not susceptible to transient, random, aging or environmental related faults.

Thus, the software will not exhibit degradation from these factors. Software failures that are not associated with hardware failures are generally caused by design errors and, therefore, do not follow the random failure behavior used for hardware reliability analyses. For software, the error rate is at the highest level during integration and testing. As it is tested, errors are identified and removed. This removal continues (though at a much slower rate) during its operational use. In fact, software reliability curves predict an increase in reliability with the passage of time as users identify and correct design defects. IEEE Std 729-1983 defines this process as "reliability growth".

RAI 10 References 1l1 RPS Replacement Project Specification OSS-0311.00-00-0013

/2/ ESFAS Replacement Project Specification OSS-0311.00-00-0012

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 I application". Please provide the test plans, procedures and reports.

Duke Response to RAI 15 Duke provided FANP Document 51-5055058-01 and FANP Document 51-9002116-000 in electronic format to NRC staff via electronic mail on November 1, 2005. These two documents provide the test plans, procedures and reports for the commercial dedication and qualification of the power supplies.

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 RPSIESPS system.

November 3, 2005 Page 17 Duke Response to RAI 16 Per the request of one of the NRC reviewers in a teleconference on October 25, 2005, Duke has revised the response to RAI 16, provided on October 6, 2005, to indicate "simplex" communications will be used rather than "half duplex." The response is provided in its entirety below with the proper terminology. The locations of the changes are identified by a revision bar on the right side of the page.

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 simplex; 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 simplex 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 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.

Response to RAI 21 The Software Maintenance Plan (or SDQA at Oconee) is expected to be issued by December 1, 2005, and will be provided as part of Duke's response to RAI 01C.

Duke has obtained FANP's commitment to support the Teleperm XS (TXS) I&C system throughout the life of the ONS TXS system. This support will include hardware spare parts and software maintenance.

FANP will maintain hardware spare parts for the critical TXS components through a combination of spare parts for the existing system and form, fit, and function replacements. This is in addition to the inventory of spares that Duke will maintain at ONS. Duke will conduct repairs and replacement of TXS components at ONS using station procedures for safety equipment as required. Failed equipment that is returned to FANP by Duke will be repaired, tested and returned to inventory as appropriate.

November 3, 2005 Page 18 System software will be maintained by FANP throughout the life of the ONS TXS system. FANP monitors system software performance worldwide and develops fixes to address all reported errors. These fixes are always developed and tested in Germany using the same procedures and processes that were used in developing the original software code. Prior to completion of the Site Acceptance Testing (SAT), any modifications to the operating system software will be installed by FANP under its Quality Assurance and configuration management program. After the SAT, any required modifications will be installed under the ONS software configuration management program (or SDQA program at Oconee). Actual installation of the modifications will be by FANP personnel but in all cases will be under the ONS program.

TXS application specific software has been designed such that ONS will be able to develop and test any modifications to this software. The software tools and training required to accomplish these modifications will be provided as part of this contract. The software tools required to develop, test and implement changes include:

o SPACE Engineering 3.0.7a o SPACE Code Generation 3.0.0 o SPACE Analysis Tools 3.0.2 o TXS GW WIN32 1.0.4 o SIVAT 1.5.1 Through the completion of the SAT, any changes to the application specific software will be developed tested and installed by FANP under its configuration management program. After the SAT and prior to installation, any required changes to the application specific software will be developed by FANP; however, they will be implemented under the ONS program.

FANP will provide technical support for hardware and software throughout the life of the TXS system utilizing specialists from Germany or the US, as required.

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?

Response to RAI 22 The process for modifying software is described in the response to RAI 21. Until the Site Acceptance Testing (SAT), all system software development testing and installation will be performed by FANP under their configuration management program. After the SAT, system software changes will continue to be developed and tested by FANP, however, application specific software changes will be developed, tested, and installed by FANP under the ONS configuration management program.

November 3, 2005 Page 19 The process for developing, testing and implementing software changes will be described in the Software Data Quality Assurance Document (SDQA). This document is being provided in response to RAI 01C.

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 Per the request of one of the NRC reviewers in a teleconference on October 25, 2005, DUke has revised the response to RAI 16 provided on October 6, 2005 to clarify that the Oconee software will not include any unused functions. The location of the change is identified by a revision bar on the right side of the page.

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. The Oconee software will not include any unused functions except those 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 RPS/ESPS 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 documents previously submitted to the staff, please reference where the information is discussed.

Duke Response to RAI 29 The applicable review guidance and requirements presented in the SRP Section 7.0; Section 7.1 including Appendix A (review process for digital systems); B (IEEE Std 279-1971), C (IEEE Std 603-1991), Table 7-1, and Sections 7.2 and 7.3 are fulfilled by the Oconee TELEPERM XS design. Table 7.1 includes requirements and guidance documents of which a number are not relevant (e.g. design certification for advanced reactors) to the TELEPERM XS system and its intended use at ONS. The TELEPERM XS system was reviewed by the NRC using this guidance in the original SER 1l1 and was found acceptable. The conclusions of the review are provided in Section 5 of reference /ll. In addition, the following additional information is provided.

November 3, 2005 Page 20 SRP Table 7-1, Section 1 - 10CFR50 1: 10CFR50.55 Section 50.55(a)(1) of Title 10 of the Code of Federal Regulations (10CFR) "Quality Standards for Systems Important to Safety" are satisfied by conformance to the codes and standards listed in the SRP. The Codes and Standards for the Oconee RPS/ESPS design are provided in Section 16 of references 121 and /3/.

Section 50.55(a)(h) endorses IEEE-603-1991. For conformance to IEEE-603 see RAI 27.

2: 10CFR50.34(f 10 CFR 50.34(f) applies to applications that were pending as of February 16, 1982.

Clearly, Oconee is not within the scope of this requirement.

TMI action items per Table 7-1 of the SRP were reviewed in the original SER 1l1 and all except TMI Action Plan Item [1.D.3] were identified as Plant Specific Actions 3-8 of the original SER Section 6 11. All plant specific action items are addressed in the February 14, 2005 submittal in Attachment 3, Section M. 141 SRP Table 7-1. Section 2 - General Design Criteria Conformance to General Design Criteria is provided in the February 14, 2005 submittal in Attachment 3, Section I1/21 and Section 16 of references /3/ and /41.

SRP Table 7-1, Section 3 - Staff Requirements Memoranda For conformance to BTP-1 9, refer to the Defense-in-Depth and Diversity Assessment submitted on March 20, 2003 /5/.

SRP Table 7-1. Sections 4 and 5 - Regulatory Guides and Branch Technical Positions For conformance to Regulatory Guides and Branch Technical Positions refer to Section 16 of references /31 and /4/.

RAI 29 References

/1/ USNRC; Safety Evaluation by the Office of Nuclear Reactor Regulation -

Siemens Power Corporation Topical Report EMF-21 10(NP), Rev. 1; ADAMS Accession No. ML003711856 12/ ESPS Equipment Specification - Specification No. OSS-0311.00-00-0012

/3/ RPS Equipment Specification - Specification No. OSS-0311.00-00-0013 November 3, 2005 Page 21 14/ License Amendment Request for Reactor Protective System/Engineered Safeguards Protective System Digital Upgrade, Technical Specification Change (TSC) Number 2004-09; ADAMS Accession No. ML050550470

/51 Oconee, Defense in Depth & Diversity Assessment Associated With Digital Upgrade of Reactor Protective System & Engineered Safeguards Protective System, Accession Number, ML030920676, March 25, 2003.

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 reached by the NRC staff on the acceptability of the original items.

Duke Response to RAI 30

[Proprietary Information - Refer to Attachment 2]

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?

November 3, 2005 Page 22 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)

RPSIESPS TXS system have been at international nuclear power plants and how many at U.S. nuclear power plants?

Duke Response to RAI 31

[Proprietary Information - Refer to Attachment 2]

November 3, 2005 Page 1 Updated List of NRC Commitments (from Duke Letter dated October 6, 2005)

RAI Commitment Status 1.C, The final approved SDQA document is in preparation, review and In progress 1.D, & approval and is expected to be issued by December 1, 2005. Duke will 1.E provide the final approved plan when issued.

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

1.H These documents are in preparation, review, and approval and are In progress 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.

1.1 Software Design Reviews and Source Code Reviews are performed in In progress 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.

The FAT Plan, FAT Procedure, and FAT Report are expected to be In progress 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.

Attachment 3 November 3, 2005 Page 2 Updated List of NRC Commitments (from Duke Letter dated October 6, 2005)

RAI Commitment Status 1.J The Site Acceptance Test (FAT) Plan, SAT Procedure, and SAT Report In progress 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.

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

1.K Duke will submit an explanation of what training has been provided by Provided FANP to Duke by November 3,2005. 11/3/05 1.K Training for control room operators, l&C maintenance personnel and In progress plant engineering is being developed as part of the modification process. Duke will provide additional explanation of this training by January 12, 2006.

1.L The requirements matrix is a living document, and is updated at the end In progress 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.

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

1.0 These calculations (Setpoint) require revision as a result of the In progress 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.

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

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

November 3, 2005 Page 3 Updated List of NRC Commitments (from Duke Letter dated October 6, 2005)

RAI Commitment Status 1.U The Software Safety Plan is in preparation, review, and approval and is Provided expected to be issued by November 30, 2005. 11/2/05 1.V Duke will provide a date when Software Operations Plan can be Provided provided by November 3,2005. 11/3/05 4.A & The response to RAI 4.A and 4.C will be included in Duke's response to Provided 4.C RAI 30. The response to RAI 4.B is in preparation and will be 11/3/05 submitted by November 3, 2005.

4.B Test Report # 968/K 110.00/02 is currently being translated from New German to English. Duke will provide this document to the NRC staff when it is available.

4.B A qualification summary report addressing Oconee specific equipment New such as relays, breakers, transmitters, etc., is in preparation, review and approval and is expected to be issued by November 9, 2005. Duke will provide this document when it is issued.

6 Duke will respond to the question related to channel independence in Provided our response to RAI-27. [Note - this question was addressed in 11/3/05 response to RAI 6.]

6 Duke's response to the question related to communications and data Provided exchange is in preparation and will be submitted by November 3, 2005. 11/3/05 7c Duke will submit more information regarding the hardware solution by Provided November 3,2005. 11/3/05 10 Duke provided a preliminary response to this question on June 30, Provided 2005. After discussions with the staff on August 17, 2005, Duke agreed 11/3/05 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 Provided December 1,2005. 11/3/05 18 The response to this RAI is in preparation and will be submitted by In progress 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 Provided the August 17, 2005, Duke/NRC RAI meeting and agreed to revise this 11/3/05 response. This response is in preparation and will be submitted by November 3,2005.

November 3, 2005 Page 4 Updated List of NRC Commitments (from Duke Letter dated October 6, 2005)

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

29 The response to this RAI is in preparation and will be submitted by Provided December 1, 2005. 11/3/05 30 The response to this RAI is in preparation and will be submitted by Provided December 1, 2005. 11/3/05 31 The response to this RAI is in preparation and will be submitted by Provided December 1, 2005. 11/3/05 November 3, 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. 1am familiar with the criteria applied by FANP to determine whether certain FANP information is proprietary. I am familiarwith the policies established by FANP to ensure the proper application of these criteria.

3. 1am 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 November 3, 2005 and entitled uResponse 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 2, 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 onove r , 2005.

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