ML060520628

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 6

ML060520628
Person / Time
Site:	Oconee
Issue date:	02/03/2006
From:	Brandi Hamilton Duke Power Co
To:	Document Control Desk, Office of Nuclear Reactor Regulation
References
Download: ML060520628 (34)

Text

MkDuke f-Power, BRUCE H HAMILTON Vice President Oconee Nuclear Station Duke Power ONOl VP / 7800 Rocherster Highway Seneca, SC 29672 864 885 3487 864 885 4208 fax February 3, 2006 U. ',. 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 6 In FL submittal dated February 14, 2005, Duke Energy Corporation (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 License Amendment Request (LAR) requests Nuclear Regulatory Commissicn (NRC) to approve the Reactor Protective System (RPS)/Engineered Safeguards Protective System (ESPS) modification and associated Technical Specification (TS) change.

Duke! provided responses to an NRC Request for Additional Information (RAI) dated September 6, 2005, by letters dated October 6, 2005, November 3, 2005, November 22, 2005, November 22, 2005, November 30, 2005, and January 12, 2006.

NRC requested additional information by letter dated January 10, 2006. Attachment 1 provides Duke's response to RAIs 32 through 45. contains information proprietary to Framatome ANP (FANP).

An affidavit from Framatome ANP (FANP) is included as Attachment 5. 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.

AO:)(

www dukep c~Ijer o

n

U. S. Nuclear Regulatory Commission February 3, 2006 Page 2 During the November 14 through November 18, 2005, NRC audit of RPS/ESPS digital upgrade at Framatome-ANP (FANP) offices in Alpharetta, Georgia, the NRC reviewers obtained several design documents for review.

At that time, they indicated that they may request Duke to docket these at a later date.

Table 1 of Attachment 3 lists and dockets the items that were obtained during that audit that have not been docketed by reference in response to either set of RAIs.

These documents were provided in electronic format by electronic mail on January 25, 2006.

Table 2 of Attachment 3 lists and dockets items that have been provided as updates to documents provided in response to the September 6, 2005, RAI. provides an updated list of the outstanding commitments associated with :Duke's responses to NRC's RAIs dated September 6, 2005, and January 10, 2006.

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

Very truly yours, B. H. Hamilton, Vice President Oconee Nuclear Site

U. S. Nuclear Regulatory Commission February 3, 2006 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 & JEnvironmental Control 2600 Bull Street Columbia, SC 29201

U. S. Nuclear Regulatory Commission February 3, 2006 Page 4 B. H. Hamilton, 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.

B. H. Hamilton, Vice President Oconee Nuclear Site S bscribed and sworn to before me this day of a___

v-2006 ry Public My Commission Expires:

~

- Non Proprietary Duke Response to Request for Additional Information (RAI)

Oconee Nuclear Station License Amendment Request for RPS/ESPS Digital Upgrade

RAI 32

The licensee for Oconee Nuclear Station, Unit I (Duke Energy Corporation) has submitted a change in the design of its analog-based reactor protective system (RPS) and engineered safeguards protective system (ESPS) that integrates protective functions from both of these systems into a combined system using digital technology. In combining these two echelons of defense-in-depth, this proposed design is a first-of-its-kind approach. The staff is aware of information the Electric Power Research Institute (EPRI) presented to the NRC Advisory Committee on Reactor Safeguards (ACRS) on October 21, 2005, regarding defense-in-depth and diversity for digital upgrades (ML053120050). At that meeting, EPRI presented sample results of sensitivity studies for digital common cause failures that indicate that multiple diverse systems were important to maintaining a level of risk commensurate with the risk associated with an equivalent analog system.

a. Please provide a summary of the scope, methods, and results of any calculations, analysis, or studies addressing the safety consequences of the combination of RPS and ESPS functions that demonstrate the level of safety provided by the proposed design is commensurate with that of the existing analog design.

b. If no such calculations, analysis, or studies have been performed, please provide an equivalent analysis or justification that adequate safety of the public is maintained.

Duke Response to RAJ 32 Duke reviewed EPRI's October 21, 2005, ACRS presentation and could not make the general conclusion that "multiple diverse systems were important to maintaining a level of risk commensurate with the risk associated with an equivalent analog system." Duke then requested EPRI to advise them on the intent of their presentation. EPRI indicated that following the presentation of example numerical results from the sensitivity studies, they stated:

Diversity is of value based on "the frequency of the initiating event" and "the existing diversity of the mechanical and electrical systems" into which the l&C is to be installed.

EPRI then provided the following specific risk insights:

High frequency initiators benefit frDm diversity in the l&C due to the existence of multiple diverse mitigating systems and the need to preserve the existing diversity between the mechanical and electrical equipment in these systems.

mm February 3, 2006 Page 2 Low frequency initiators receive little benefit from the addition of diversity in the l&C because they are generally mitigated by a single system with little diversity between the redundant trains of mechanical and electrical equipment within that system.

With respect to how reliable a digital system needs to be, EPRI suggested that for high frequency events, digital channel reliabilities on the order of that for a similar channel of analog equipment are adequate to manage risk. For low frequency events, digital channel reliability can be less than that of similar analog channels and still be effective in managing risk. A major point EPRI makes with their report is that mechanical components are the areas where risk is highest and not within the l&C architecture.

With only one design for valves and pumps, system reliability is not improved by employing diverse l&C architectures.

In Duke's November 22, 2005 submittal (Supplement 3), Duke explained that the combining of RPS and ESPS into a single processor is not a new concept. Components have been shared in current analog l&C architectures by both Combustion Engineering and Westinghouse designed nuclear plants. In particular, ANO-2, SONGS, Waterford and Palo Verde have a shared protection system architecture. The NRC certified System 80+ design has the same l&C architecture with the RPS and ESFAS implemented in common PLCs.

Response to Part a:

No quantitative analysis of the Oconee RPS/ESPS upgrade has been performed in a manner similar to the EPRI analysis. However, the following insights can be provided with respect to EPRI's conclusions:

Actuation of mitigating systems for high frequency Oconee initiators is provided by multiple diverse means as is suggested to be of value in the EPRI sensitivity studies (e.g., Emergency Feedwater (EFW) can be initiated by its own control system, ATWS Mitigation System Actuation Circuitry (AMSAC) or by manual initiation; reactor trip is actuated by RPS, Diverse Scram System (DSS) or manually).

Actuation of mitigating systems for Oconee low frequency initiators, meets or exceeds the diversity considered necessary by the EPRI sensitivity studies (e.g.,

the Oconee RPS/ESPS digital upgrade includes a diverse actuation system for LPI in response to the Large Break LOCA.

With respect to the combination of the RPS and ESPS functions, ESPS is not a backup to RPS at Oconee. The same mitigating systems are required following a failure of the RPS as would be needed for failure of both RPS and ESPS (e.g., adequate pressure relief, EFW and emergency boration). The ATWS Rule, 10 CFR50.46, was issued after an industry and NRC analysis of the failure of the RPS to function because of a common mode failure with existing analog systems. Oconee has implemented required ATWS modifications resulting from the rule. Given that Oconee complies with the requirements

February 3, 2006 Page 3 of the ATWS rule with or without successful ESPS operation, Duke concludes that the digital upgrade complies with 10 CFR50.46. Duke also concludes that Oconee meets the acceptance criteria of BTP-1 9 with respect to RPS/ESPS interactions caused by postulated software common mode failures. Duke performed this assessment and submitted it for review on March 20, 2003.

During the November 14 through November 18, 2005, NRC audit of the RPS/ESPS digital upgrade at Alpharetta, Georgia, the NRC reviewers expressed a concern as to whether a common mode failure in the ESPS portion of the software could cause an undesirable effect on the RPS function or vice versa. There was general agreement that a common mode failure of the RPS could not result in an undesirable effect on the ESPS function since these channels must energize to actuate. However, there was some discussion on whether a common mode failure in the ESPS portion of the software could cause an undesirable effect on the RPS function. The NRC reviewers indicated that any failure that resulted in an RPS trip was an undesirable since this represented an unnecessary challenge to the plant. A common mode failure of the ESPS function could cause at least two of the three channels that share processors between RPS and ESPS to reset, which could de-energize multiple RPS channels and thereby cause an RPS trip.

A common mode failure within the RPS, whether caused by l&C (digital or analog) components or mechanical components, would have the same affect. Furthermore, Duke/FANP reminded the NRC reviewers that this scenario was extremely remote based on: (1) the operating experience with TXS platforms, (2) the plant specific Failure Mode's and Effects Analysis (FMEA) that would reveal any credible failures, and (3) the Factory Acceptance Test (FAT) that would validate functionality of the TXS system as further described below. In addition, the high quality of TXS software provides additional assurance (discussed in response to Part b of the NRC question below).

(1) Operating Experience The mature operating history for the TXS system, which is on the order of more than 64 million accumulated hours (as discussed during the Duke/NRC management meeting of October 18, 2005), includes no failures that have degraded plant operation. To date, all of the reported failures have been related to hardware, with no reported software failures occurring during plant operation.

(2) Failure Modes and Effects Analysis The FMEA, which was provided to the NRC Staff on December 15, 2005, is a systematic qualitative analysis of the RPS and ESPS design with the primary objectives of identifying all potential failure modes, evaluating the consequence and effects of failures, and verifying that the design satisfies the single failure criterion and safety criteria. The FMEA also performs an extended qualitative analysis of common-cause failures.

As part of this analysis, the ONS TXS design was evaluated to determine the extent to which the design methodology captures the principles of reliability. This February 3, 2006 Page 4 evaluation was performed by a qualitative evaluation of the overall system design. This qualitative analysis is considered to be a review of the top-level design methodology and is considered sufficient to represent the reliability of the design foundation. Based on the qualitative analysis resulting from the FMEA of the RPS/ESFAS TXS system, the system design incorporates sufficient redundancy and independence to meet the design basis of the ONS RPS/ESFAS. The ONS RPS/ESFAS TXS system maintains sufficient redundancy such that no credible single-failure can compromise the design.

Failures were considered down to the system/subsystem level and included evaluation of impacts to the system critical functions. The FMEA concludes that critical functions required for performing protective actions, during normal and abnormal conditions, will continue to be performed for all identified failure modes and that no single failure causes an unanalyzed event. It further concludes that the consequence of failure is negligible and the associated risk of failure is low to very low in significance. Therefore, Duke concludes that the failure modes for the RPS/ESPS system upgrade have been adequately considered and there are no risk significant failures that could impact the ability to perform critical functions.

(3) Factory Acceptance Test (FAT)

During the FAT, all hardware and software will be inspected and/or tested to systematically validate functionality under a comprehensive set of test conditions.

Past operating experience demonstrates the overall reliability of the TXS platform. The plant specific FMEA and FAT allows potential failure modes to be identified and corrected and will establish additional confidence of equipment reliability.

Response to Part b:

Addressing EPRI's suggestion that a channel of digital l&C have a reliability on the order of that for a similar analog channel, the TXS platform at ONS employs several techniques (described in more detail in Section 5.0 of the Attachment to Duke letter dated March 20, 2003) that aid in reducing the likelihood of the occurrence of a software common mode failure by maximizing TX'; dependability.

The TXS software is of the highest quality and has been accepted by the NRC for use in safety related systems (NRC SER dated May 5, 2000). On the basis of its review the NRC concluded that the TXS system satisfies the requirements of IEEE Std 603-1991 with regard to reliability and testability.

The TXS system is designed to exhibit deterministic instrumentation and control (I&C) system behavior. This means that the overall system behavior in response to any input data trajectories is determined by the validated application software and is free of any unintended interference from the operating system software or the system hardware.

To ensure that the system's operating behavior is independent from any input data trajectories; the following set of system features is implemented: strict cyclic

rn February 3, 2006 Page 5 system operation, no process-dependent interrupts, and static allocation of system resources.

The application software is designed using the advanced SPACE engineering system. This tool was approved by the NRC as being qualified and, therefore, code produced by this tool is acce ptable and of high quality. SPACE's most effective technique for eliminating design errors is the functional validation of the generated application software.

• The self-monitoring software performs a sequence of checks on the various hardware components of the processing module.

Selected failure management techniques have been employed within the TXS System. Software architectures have been designed to minimize SWCMFs.

Detecting all of the types of failures that are possible through the TXS testing techniques makes the probability of the TXS system detecting a software failure very high and significantly lowers the likelihood of a SWCMF occurring without detection. This detection is available either through automatic or manual means giving adequate time for compensatory action to ONS and its operators.

As acknowledged in BTP-1 9, despite the high quality of design, software errors may still defeat safety functions in redundant, safety-related channels. Because of this the Staff requires that the applicant/licensee perform a Defense in Depth and Diversity (D-in.-D&D) assessment of the proposed digital l&C system to demonstrate that vulnerabilities to common-mode failures have been adequately addressed. In this assessment, the applicant/licensee should analyze design basis events (as identified in the safety analysis report). Duke performed such an assessment and submitted it for review on March 20, 2003. The conclusion of that assessment identified one vulnerability that was addressed by installing a new diverse mitigating system. There were no other vulnerabilities identified.

Conclusion The above discussion demonstrates reasonable assurance that the level of safety provided by the proposed digital design is commensurate with that of the existing analog desig n.

RAI 33

The staff has concluded that the interchannel communications used for 2ndmin/2ndmax online signal validations do not conform to the channel independence requirements of IEEE 603-1991, section 5.6.1 and IEEE 279-1971, section 4.6, or the IEEE 603 or IEEE 279 channel definition in section 2 of both standards. Please provide a design that meets the applicable standards or a relief request in accordance with 10 CFR 50.55a that justifies the approach. In either case, the appropriate documentation should be submitted expeditiously, to minimize schedule risk.

RAI 35

The staff believes that the permanent two way communication path between the TXS system and the maintenance panel does not meet the requirements for isolation between safety-related and non-safety systems of IEEE 603,

-m February 3, 2006 Page 6 sections 5.6.3 and 5.6.3.1(2). Please provide design details that conform to applicable standards or a relief request in accordance with 10 CFR 50.55a that justifies the approach. In either case, the appropriate documentation should be submitted expeditiously, to minimize schedule risk.

Duke Response to RAI 33 and RAI 35 10 CFR 50.55a(a)(3)(i) permits licensees to propose alternatives to the requirements of 50.55a that provide an acceptable level of quality and safety. An NEI guidance document, Standard Format for Requests from Commercial Reactor Licensees Pursuant to 10 CFR 50.55.a," June 2004, provide templates for preparing relief requests.

The guidance in the NEI guidance document has been considered in responding to RAI 33 and RAI 35.

Duke Response to RAI 33 A description of the design that meets the applicable standards has been previously provided by Duke letter dated November 3, 2005, the response to RAI 6.

Duke understands that the TXS system components of concern in RAI 33 are:

(1) the fiber optic inter-channel communications, and (2) the individual channel software used for 2nd min/2nd max online signal validations and channel trip functions.

The applicable IEEE Standards for these components are - IEEE Std 603 - 1998 and IEEE Std 7-4.3.2 - 2003 (as discussed in NRC Regulatory Guide 1.152 - Criteria for Digital Computers in Safety Systems of Nuclear Power Plants, Revision 2 issued January 2006). (Note that IEEE Std 603 - 1998 is essentially the same as IEEE Std 603

- 1991 with the exception of reference to the later IEEE 7-4.3.2 - 1993 version and the addition of Annex B for EMI guidance.)

Two sections of IEEE Std 603 - 1998 are applicable to these components:

a. Section 3, definition of channel states:

Channel - an arrangement of components and modules as required to generate a single protective action signal when required by a generating station condition.

A channel loses its identity where single protection action signals are combined.

b. Section 5.6.1 states:

Between Redundant Portions of a Safety System. Redundant portions 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 to accomplish the safety function during and following any design basis event requiring that safety function.

-U February 3, 2006 Page 7 IEEE Std 603 - 1998 also states that it shall be used in conjunction with several additional IEEE publications, one of which is IEEE Std 7-4.3.2 - 1993 which states in part:

NOTE-See Annex G for more information on the independence criterion.

In addition to the requirements of IEEE Std 603-1991, the following requirement is necessary in order to meet the independence criterion.

Data communication between safety channels or between safety and nonsafety systems shall not inhibit the performance of the safety function.

Section 3 of IEEE Std 603 - 1998 provides a definition of a channel. The TXS design utilizes channels and it is unclear how the TXS design is not in compliance with the definition of channel in Section 3 of IEEE Std 603 - 1998 or why a request for relief would be needed or even what would be an alternative to the definition even if one were to be proposed. Based on the above, Duke concludes that the TXS design is in compliance with IEEE Std 603 - 1998, Section 3 and that no relief request is necessary.

Section 5.6.1 provides requirements for redundant portions of a safety system. As stated in the response to RAI 6, a failure modes and effects analysis (FMEA) of the 2nd mrin/2nd max configuration concludes that the data shared between channels cannot be used incorrectly and that a single channel's data cannot cause multiple channels to malfunction. Postulated failures of redundant channel data communication via isolating fiber optic connections between the safely channels does not inhibit the performance of the safety function. The channels are independent to the degree necessary to retain the capability to accomplish the safety function during and following any design basis event requiring that safety function.

Duke provided the complete Failure Modes and Effects Analysis electronically on December 15, 2005 and formally docketed it by letter dated January 12, 2006. Thus, Duke concludes that the TXS design is in compliance with IEEE Std 603 - 1998, Section 5.6.1 and that no relief request is necessary.

RAI :35 The staff believes that the permanent two way communication path between the TXS system and the maintenance panel does not meet the requirements for isolation between safety-related and non-safety systems of IEEE 603, sections 5.6.3 and 5.6.3.1(2). Please provide design details that conform to applicable standards or a relief request in accordance with 10 CFR 50.55a that justifies the approach. In either case, the appropriate documentation should be submitted expeditiously, to minimize schedule risk.

February 3, 2006 Page 8 Duke Response to RAI 35 Duke understands that the two components affected by RAI 35 are:

(1) the safety-related fiber optic cable between the safety-related TXS system and the non-safety-related maintenance service unit, and (2) the software communications interface between the safety-related TXS system and the non-safety-related maintenance service unit.

The applicable IEEE standards for these components are - IEEE Std 603 - 1998 and IEEE Std 7-4.3.2 - 1993 (as discussed in NRC Regulatory Guide 1.152 - Criteria for Digital Computers in Safety Systems of Nuclear Power Plants, Revision 1 issued January 1996). (Note that IEEE Std 603 - 1998 is essentially the same as IEEE Std 603

- 1991 with the exception of reference to the later IEEE 7-4.3.2 - 1993 version and the addition of Annex B for EMI guidance.)

Two sections of IEEE Std 603 - 1998 are applicable to these components:

a. Section 5.6.3, Between Safety Systems and Other Systems, states: The safety system design shall be such that credible failures in and consequential actions by other systems, as documented in 4.8 of the design basis, shall not prevent the safety systems from meeting the requirements of this standard.

b. Section 5.6.3.1 (2), Isolation, states: No credible failure on the non-safety side of an isolation device shall prevent any portion of a safety system from meeting its minimum performance requirements during and following any design basis event requiring that safety function. A failure in an isolation device shall be evaluated in the same manner as a failure of other equipment in a safety system.

IEEE Std 603 - 1998 also states that it shall be used in conjunction with several additional IEEE publications, one of which is IEEE Std 7-4.3.2 - 1993 which states in part:

NOTE-See Annex G for more information on the independence criterion.

In addition to the requirements of IEEE Std 603 - 1991, the following requirement is necessary in order to meet the independence criterion.

Data communication between safety channels or between safety and nonsafety systems shall not inhibit the performance of the safety function.

The Teleperm XS based RPS/ESPS systems contain several design features to ensure that the physical connection and data communications between the non-safety maintenance service unit (SU) and the safety related Teleperm XS RPS/ESPS do not prevent the performance of the required safety functions of the safety related RPS/ESPS.

m~M February 3, 2006 Page 9 These design and security features include the following:

Physical Location Security:

Administrative Access Controls:

Electronic Access Security; The maintenance SU is physically located within the plant vital areas adjacent to the main control room. The RPS/ESPS cabinets are located in the main control room.

The maintenance SU is located near the main control boards and the cabinets containing the RPS/ESPS. Vital area access is required to enter the main control room.

Completion of the plant access security program authorization activities is required along with appropriate management authorization to access plant vital areas. In general, main control room access is further limited by authorization from the Work Control Center (WCC) to those non-operational personnel who have a need to enter the area. The maintenance SU is located in the main control room along with the plant's main control boards, numerous safety related and non-safety related system equipment cabinets, plant computer equipment and plant monitoring equipment. (Property Security) (Personal Features Security)

Access to all plant equipment is administratively controlled. Access to Control Room plant equipment is more stringently controlled. Prior to performing authorized maintenance on the RPS/ESPS, permission would be obtained from both the WCC to initiate activities described in a planned/approved work order and Operations Staff present in tie WCC. This two-step process (WCC and Operations Staff) is utilized for all plant maintenance activities which occur in the control room. The WCC aspect is used to control the volume of and scheduling of work being performed both in the main control room and plant, while the second Operations Staff related aspect is used to ensure awareness by assigned Unit specific Operations staff to the actual activities being performed on an assigned unit. (Property Security)

Access to the maintenance SU functional interface with the RPS/ESPS is password protected. Password protection provides an additional layer of assurance that maintenance SU interface with the RPS/ESPS is performed only by those individuals authorized. Access to the password is via controlled plant procedures. Only those maintenance personnel assigned to perform maintenance related activities on the RPS/ESPS are authorized to use the controlled procedures for their intended purposes.

February 3, 2006 Page 10 Along with the above, properly formatted data communication interfaces with the RPS/ESPS are required for meaningful interaction. This means that unless commands have followed the proper sequence and are properly formatted and executed, the RPS/ESPS would not recognize the actions or requests being input from the maintenance SU. (Knowledge Security)

Cabinet Access Security:

Electrical Isolation:

Each cabinet of the RPS/ESPS is locked and secured. A key is required to gain access to the internal RPS/ESPS channel key switches. Each channel of the RPS/ESPS utilizes a key switch that requires a specific position to permit any system changes to parameter settings, alarms and system functional software. The keys to these key switches are controlled by the Operations Staff in the WCC. Whenever a RPS/ESPS cabinet door is opened, a plant computer alarm will be generated in the main control room alerting control room staff to cabinet access.

Whenever a key is utilized and a position change occurs with the key switch, an annunciator alarm will be generated on the main control board. If the key switch is not in the proper position, any command, proper or improper would fail to be responded to by the affected channel. (Property Security)

The connection from non-safety equipment such as the maintenance SU to the RPS/ESPS is via a safety related SINEC-HI data link fiber optic cable. The maintenance SU is connected to the RPS/ESPS via the NetOptics port aggregator device (NetOptics) and Media Converter as shown in the figure used in response to RAI 34. The use of fiber optic cable prevents any postulated conventional electrical fault from propagating from the maintenance SU (or other non-safety equipment) to the RPS/ES or vice versa. The electrical isolation of the RPS/ESPS to the maintenance SU and other non-safety plant equipment is assured through the used of safety-related fiber optic cabling.

Thus, Duke concludes that the Teleperm XS design is in compliance with IEEE 603 - 1991, Sections 5.6.3 and 5.6.3.1(2) as well as IEEE 7-4.3.2 - 1993. In addition, Duke concludes that the Teleperm XS design utilizes the appropriate subject matter guidance provided in Regulatory Guide 1.152, Rev. 2. No relief request is necessary.

February 3, 2006 Page 1 1 RAI :34 The staff understanding is that isolation between the TXS system and the plant computer will be improved by the addition of a port tap hardware-based device. The acceptability of this isolation method depends on the port tap not providing any return path for communications from the plant computer.

Please provide sufficient design details on the port tap device to show that there is no path for data to be transmitted into the port tap from the plant computer.

Duke Response to RAJ 34

[Proprietary Information - Refer to Attachment 2]

RAI :36 After discussions with Framatome and the licensee, the staff understands that future RPS trip functions #2 and #12 will be removed from the trip system logic until the trip functions have been approved by the NRC for all three ONS units. Please provide the appropriately modified documentation to this effect.

This includes the trip function descriptions, the software requirements specifications, and the software design descriptions.

Duke Response to RAI 36 RPS Trip Functions #2 and #12 have been removed from trip system software logic.

Appropriate design documents have been modified to reflect the removal. Duke provided the latest revisions to the system functional description (OSC 8623, Revision 3) and the software requirements specification (SRS)(FANP Document No. 15-5045380-

03) in electronic format on January 6, 2006 via electronic mail. Duke provided the latest revision to the software design description (SDD)(FANP Document No. 51-5065423-02) on January 11, 2006, via compact disk. These revisions show RPS Trip Functions #2 and #*12 removed from the RPS/ESPS digital upgrade.

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

RAI :37 ESFAS Emergency Override Function

a. During the Framatome site visit on November 14-18, the reason for the ESFAS Emergency Overr'de Pushbuttons was explained as necessary to remove power output from the ESFAS voter so that the manual action circuit could now apply and control the power. This seems to be the function of the Auto/Manual selector switches, described in calculation OSC-8623, section 20.6. Please explain how the emergency override function meets the IEEE 603-91 section 5.2, 'Completion of Protective Action", requirement that once initiated, the intended sequence of protective actions shall continue until completion. It would appear that the February 3, 2006 Page 12 function of the emergency override is specifically to interrupt the protective action and prevent completion of the intended sequence.

Duke Response to RAI 37.a These switches will be located in the control room on the main control boards. They give the operator at the controls a mechanism to shut down the automatic system in the event of a spurious actuation caused by a Software Common Mode Failure (SWCMF).

While a SWCMF is an extremely improbable beyond design basis event, Framatome and Duke believe it is prudent to provide this capability. Having these switches in the system is not a violation of the IEEE-603 requirement. The applicable portion of IEEE 603 - 1991 is section 5.2 "Completion of Protective Action". This section is inserted below in its entirety.

"The safety systems shall be designed so that, once initiated automatically or manually, the intended sequence of protective actions of the execute features shall continue until completion. Deliberate operator action shall be required to return the safety systems to normal. This requirement shall not preclude the use of equipment protective devices identified in 4.11 of the design basis or the provision for deliberate operator interventions. Seal-in of individual channels is not required."

The second to last sentence of IEEE 603 - 1991, 5.2 clearly states, "This requirement shall not preclude the use of equipment protective devices identified in 4.11 of the design basis or the provision for deliberai:e operator interventions."

Therefore, the use of the Emergency Override function as currently designed meets the IEEE 603 Standard and is therefore permissible under the standard.

RAI 37.b The staff understands that the ESFAS Emergency Override function will be modified such that the actuation override annunciator can not be powered down while the ESPS system is being overridden, and that the use of this function will be limited to those circumstances in which plant procedures require the use of the ESPS override function. Please provide documentation of the appropriate design changes, and documentation on the plant operation procedures that authorize use of this function.

Duke Response to RAI 37.b

[Proprietary Information - See Attachment 2]

RAI :38 The proposed system includes lead/lag modules and a complementary bias signal that modify the measured signals before they are submitted to the main processors. It does not appear that such modules exist in the present

mm February 3, 2006 Page 13 (analog) system, and yet the licensee has indicated that the proposed system is functionally identical to the present system as far as safety functions are concerned. Please address the following in regard to these modules:

a. Explain why the introduction of these modules, which seem capable of dramatically altering the system response to plant conditions, do not constitute a substantive change relative to the present (analog) system.

Duke Response for 38.a The current software design includes the lead/lag filters, but the filter parameters are set in such a manner as to turn off the filter (i.e. pass through filter). The only filters that are expected to be switched on are the filters on the differential pressure input signals (used for calculating RCS Flow) received by the RPS for use in the Flux/Flow/Imbalance Trip ;3.

In the present (analog) system, the STAR modules receive these differential pressure signals. The STAR modules currently contain a 594ms hardware filter on the flow inputs to address signal noise. The proposed TXS system will use software filters or a combination of hardware (SAA1) and software filter settings on these input signals with a time response delay not exceeding the 594ms filter delay as exists in the present system. In the present analog RPS, the old Bailey BY pressure transmitters were replaced with new Rosemount 1154 differential pressure transmitters. The 594ms filter was included in the STAR design in order to address process noise sensed by the new Rosemount 1154 Differential Pressure Transmitters.

The inclusion of software filters on analog input signals is merely a proactive design to allow the system to be flexible and address future signal noise that may be encountered due 1:o plant equipment changes (similar to the differential pressure signal noise encountered). These filters are set to operate in the Pass Through mode and will not affect the system response to plant conditions. This will be confirmed via SIVAT testing and FAT testing. The addition of these filters is a change from the original SER approved existing system design. The filters are designed into the system in order to allow the system to tolerate signal noise that might be caused by process system conditions. All future filter setting changes will be controlled under the plant modification program and procedure change process that ensures proper design and licensing reviews of the changes performed.

RAI :38.b Explain how the settings associated with these modules are to be computed.

Show that the computed settings will not adversely impact the dynamic response of the system as compared with the dynamic response of the present system. Show that the net steady-state signal gain presented by these modules is either constrained to unity or appropriately addressed in all applicable scaling and setpoint calculations. Show that the combined effect of these modules and any noise suppression circuitry or other dynamic compensation built into the data acquisition modules (AND conversion units) upon the measured signal is acceptable.

-U February 3, 2006 Page 14 Duke Response for 38.b

[Proprietary Information - See Attachment 2]

RAI 38.c Explain how the settings associated with these modules are to be controlled. In particular, explain how it will be ensured that the settings that are actually implemented will not be adjusted to values which compromise the response of the system. If it is physically possible to adjust the settings to inappropriate values (values which alter the dynamic or steady-state response of the system), explain how future proposed adjustments will be reviewed and approved prior to implementation. If such adjustments are not Dhysically possible, explain why this is so.

Duke Response for 38.c The time constants of the filters will be documented and controlled in the Oconee Calculation OSC-8695, "Unit 1 Software Parameters for TXS Plant Protection System."

The values in this calculation will be incorporated in the TXS software and will be tested in the FAT. The settings as tested during FAT will be installed in the plant. During post modification testing and prior to declaring the system operable, the settings will be verified or adjusted as needed under the plant post modification testing processes.

If the settings are to be adjusted anytime after testing the appropriate calculations will be created or updated and a new modification package will be developed.

RAI 38.d If the modules are intended for noise suppression, describe the characteristics of the noise that they are intended to suppress and show that the noise suppression will not impact the system response to credible rapid changes in the measured signals. Explain why such noise suppression is needed in the proposed system but not in the present system, or show that the present system does have this feature and that the implementation in the proposed system is equivalent to that in the present system and is constrained to remain so. Explain why such noise suppression would be implemented after the A/D conversion rather than before it.

Duke Response for RAI 38.d The filters were designed and implemented in the proposed TXS system to give flexibility to the system in order to compensate for different signal noise characteristics that may be encountered during the life-cycle of the TXS RPS/ESFAS system. As stated in the response to Part 38a of this RAI, the only known need for an activated filter would be for the RCS differential pressures signals. The noise characteristics are documented in Duke Calculation OSC-3712. This calculation would be an example of signal noise February 3, 2006 Page 15 characteristic that might be encountered: but is not representative of all types of signal noise that might be encountered by the T-XS RPS/ESFAS system due to plant conditions.

Noise suppression before the A/D conversion will be implemented by the SAAI card and the low pass filter settings of 48, 94, and 188ms. Software filtering would only be needled if noise suppression requirements were outside this range, as is the case with the RCS differential pressure signals.

RAI 38.e According to Framatome ANP document 01-1007776-03, "Teleperm XS Function Blocks," Version 2.60, the PT1 Tlag parameter value must be greater than the signal sampling period, Ta. In the proposed ONS-1 RPS/ESPS application, the safety functions will be processed every 50 ms; consequently, the signal sampling period, Ta, is 50 ms. However, the Tlag parameter value entered for signal filtering in Framatome ANP document 51-5065423-01, "Oconee Nuclear Station, Unit 1 RPS/ESFAS Controls Upgrade Software Design Description," has been set at 0.00001 s (0.01 ms). This parameter value (0.01 ms) is not in within the required Framatome ANP PT1 function block parameter value range. Describe the process by which appropriate values for Gain and Tlag will be determined. Also, describe the process by which the corresponding MUL-K module parameters will be determined such that the signal filtering process will not adversely affect signal response times or trip function performance.

Duke Response to RAI 38.e Entries of values lower than the cycle time Ta are allowed by SPACE in the PT1 block.

The value is used in a calculation and is therefore not limited to the cycle time. If a parameter value was not allowed then the Software RTE would generate an FBPARAM ERROR message on start-up. This is described in Section 6.9 of TXS Function Block Manual (FANP Doc 01 -1 007776-03). This does not occur using a value of 0.00001 in the PT1 Function Block. The TXS Function Block Manual incorrectly shows this lower limit of Ta. Framatome.-ANP has initiated a change request to GmbH to correct the manual.

RAI 38J The PT1 module parameter values for Gain and Tlag are 0 and 0.00001, respectively, for each signal filtering application in the Software Design Description schematic diagrams. The corresponding MUL-K parameter values are 1.0 for each of the signal filtering loops. Applying these parameter values to a steady state signal results in a filtered signal that is biased low by a factor of the Tlag/(Tlag + Ta). A preliminary staff analysis indicates that to ensure the PT1 module does not contribute a bias to the signal (All) that is to be used for subsequent trip calculations, the PT1 Gain value should be set to -(Tlag/Ta). Alternatively, the binary input value, Bll, should be set to 1 (TRUE) and the Gain should be to 0.0 to February 3, 2006 Page 16 ensure the output signal from the PT1 module is set to 0.0. Please provide analytical confirmation that the PT1 parameters are set to appropriate values for bypassing the PT1 function.

Duke Response to RAI 38.f

[Proprietary Information - See Attachment 2]

RAI 39

Various sections of OSC-8623 state that all new ESFAS output contacts will have an 0 to 15 minutes adjustable software time delay on closure, and that all time delays will be set to zero seconds. What is the purpose for this time delay capability, under what circumstances would this time delay be used, and how will this time delay value be controlled?

Duke Response to RAI 39 The new system design will enhance the existing ESFAS capabilities by including a variable time delay function (0 to 15 minute range) on each output prior to ESF device actuation. This function will allow Oconee flexibility in designing a future load sequence of ESF equipment actuation. The implementation of load sequence for ESF equipment is not within the scope of this modification. All time delays will be set at 0 to provide the same performance as the present system. The settings will be controlled by approved plant procedures. Subsequent change to the time delay setting would require a plant modification.

RAI 40

Requirements traceability is presently maintained by the system developer (Framatome ANP) using its automated configuration management processes.

Requirements traceability and configuration management responsibilities will be transferred to the licensee upon delivery and transfer of the integrated system operations and maintenance functions to the licensee. Please provide information on how the information maintained by the system developer's automated processes will be transferred to the licensee, such that configuration management and requirements traceability will not be adversely affected by a change in automated configuration management and requirements traceability processes.

Duke Response to RAI 40 The Requirements Traceability Matrix (RTM) will be issued to Duke as a controlled document upon completion. The controlled document will be in the form of a searchable pdf file that contains the traceability matrixes and traceability tree along with the book-marked versions of electronic files containing the critical documents such as the Functional Requirements Specification, Software Requirements Specification and Software Design Descriptions. Duke will be able to perform manual searches much in the same manner as the automated configuration process (IBM Requisite Pro) used at February 3, 2006 Page 17 Framatome-ANP. Additionally Framatome-ANP will maintain the RTM until the end of the project and warranty period and also as a permanent plant record that can be made available to Duke as needed. Duke does not intend to modify the design of the RPS!ESPS software on its own, but if it chooses to do so, Duke can manage requirements using the method described above or optionally purchase IBM Requisite Pro.

RAI 41

Provide an updated revision cf the requirements traceability listings, the system requirements specification, and the software design description.

Duke Response to RAI 41 Duke provided a copy of the system requirements specification (FANP Document No.

15-5045380-03), and the requirements traceability matrix (RTM) in electronic format via electronic mail on January 6, 2006, and January 10, 2006, respectively. Duke provided an updated version of the RTM in electronic format via electronic mail on January 24, 2006. Duke provided a copy of the system design description (FANP Document No. 51-5045423-02) in electronic format via compact disk on January 11, 2006. Duke requests that Ihis document be withheld from public disclosure pursuant to 10 CFR 2.390.

RAI 42

Provide the following Specification and Coding Environment (SPACE) listings for the hardware:

a. A cabinet equipment list (subracks, modules) with codes (KKS, AKZ, etc.), mounting locations, and complete parameter settings list (e.g.,

addresses, measuring ranges, options and pin assignment of the I/O modules);

b. The switch and jumper settings to be performed on the modules;

c. A list of the signals applied to the I/O modules; and

d. A software/hardware assignment list for each processing module (list of the function diagram modules executing on this processing module).

Duke Response to RAI 42 The SPACE listings for the hardware are provided in FANP Document 51-9011274-000.

This document was provided in electronic format via electronic mail on January 26, 2006. Duke requests this document be withheld from public disclosure pursuant to 10 CFR 2.390.

February 3, 2006 Page 18

RAI 43

Provide the following Specification and Coding Environment (SPACE) listings for the software:

a. A list of the function diagram modules executing on the processing modules complete with ID-code and internal SPACE ID number;

b. A parameter settings list for each function diagram module that provides an overview of the function block modules used, complete with internal SPACE ID number, coordinates of the layout on the function diagram; and

c. Complete parameterization information.

Also, please explain how the value of these parameters will be determined and controlled.

Duke Response to RAI 43 SPACE Code listings for the software have been developed and are currently being reviewed. These listings will be included in the Implementation Specification that Duke committed to provide in the October 6, 2005, response to RAI 1.H when issued. At that time the issue date was expected to be January 28, 2006. This document is now expected to be issued by February 14, 2006. Duke will provide a copy when issued.

The plant specific critical parameters will be determined by a calculation (OSC-8695, "Unit 1 Software Parameters for TXS Plant Protection System"). Future parameter changes will be controlled by the plant modification process.

RAI 44

Provide a discussion of the process used to develop the validation test plans and bases for defining the test envelopes for each requirement. If validation test results have been obtained, provide a representative sample of the test results including the test procedures and the test reports.

Duke Response to RAI 44 The process used to develop the tests starts with the requirements identified in the Functional Requirements Specifications and Project Equipment Specifications (previously provided). The Requirements Traceability Matrix is used as a tool to ensure all requirements are tested. Software Testing is conducted using the guidance of Regulatory Guides 1.170 and 1.171.

A common approach to testing is taken that uses a multi-level test program to help ensure quality in a complex software product or complex set of cooperating hardware and software products: Pre-FAT testing, Software unit-level testing, Software February 3, 2006 Page 19 integration-level testing, Factory Acceptance Testing, Site Acceptance Testing, and Post Installation Testing.

Pre-FAT Testing Pre-FAT testing was conducted at the GmbH manufacturing facility in Erlangen, Germany to ensure the hardware components were assembled properly and were ready for delivery to Oconee for Factory Acceptance Testing.

Software Unit Testing Process This process tests software elements at the lowest level of development.

Units may be aggregates of software elements. Planning for unit test should occur concurrently with the software design process. Test case and procedures are generated using the tool SIVAT to check software components individually for typographical, syntactic, and logic errors to ensure that each correctly implements the software design and satisfies the software requirements. Software Unit Testing is conducted in accordance with a Software Unit Test Plan (FANP ID 51-9003307-00). This document was provided in electronic format to the NRC staff via electronic mail on January 26, 2006. Duke requests this document be withheld from public disclosure pursuant to 10 CFR 2.390.

Software Integration Test Process Software integration testing is performed to examine how units interface and interact with each other with the assumption that the units and the objects (e.g., data) they manipulate have all passed their unit tests.

Software integration tests check how the units interact with other software (e.g., libraries) and hardware. Software Integration Testing checks the inter-component communication links and test aggregate functions formed by groups of components. Software integration testing tests all signal paths using a test machine and special scripts. Software Integration Testing is included in the Factory Acceptance Test Plan (FANP ID 51-9001334-02).,

and is performed prior to official Factory Acceptance Testing. The latest version of this document was provided in electronic format to the NRC staff via electronic mail on January 26, 2006. Duke requests this document be withheld from public disclosure pursuant to 10 CFR 2.390.

Factory Acceptance Testing Process Factory Acceptance Testing, in the context of V&V, involves the conduct of tests to execute the completely integrated system. Software system testing is the validation that the software meets its requirements.

Validation of the complete system may involve many tests involving all system components. The software system tests exercise only those February 3, 2006 Page 20 system functions that invoke software. The perspective is on the software aspects of the system, and whether the software behaves as intended relative to complete system performance. These tests must be conducted in such a manner as to stress and break the system based on software responses to system inputs (e.g., from sensors, operators, and databases). Factory Acceptance Testing is performed in accordance with Factory Acceptance Plan (FANP ID 51-9001334-02).

Site Acceptance Testing After Factory Acceptance Testing is complete, the system can exercised and validated with operational and maintenance procedures by the licensee. The Site Acceplance Test is normally performed by rerunning selected portions of the Factory Acceptance Test. The licensee conducts installation configuration audits to determine that software outputs needed to operate the system are present and checks that the software installed in the system is the software that underwent V&V.

Post-Installation Testing After installation is complete, the system is fully exercised and validated in its operating environment using approved post modification testing procedures prior to unit startup.

RAI 45

Section 23.4, "RPS Manual Bypass Keylock Switch," in the Duke Energy Corporation calculation OSC-8623, Rev. 1, describes the RPS Manual Bypass keylock switch function. The discussion states, 23.4.2 The RPS MANUAL BYPASS Keylock Switch allows puffing the complete RPS channel into Bypass for maintenance activities. This includes power-down of the TXS computer of the RPS channel. If the RPS MANUAL BYPA.SS Keylock Switch is in the "ON" position, it:....

23.4.4 The RPS MANUAL BYPASS Keylock Switch status information is sent to the Statalarm panel 1SA5, windows 1, 13, 25, 37; see Section 22 for window descriptors.

OSC-8623 Section 22.4, "1 SA5 Panel," indicates that the existing window descriptors for window 1, window 13, window 25, and window 37 are: "RP Channel A Trip Bypass," "RP Channel B Trip Bypass," "RP Channel C Trip Bypass," and "RP Channel D Trip Bypass," respectively, will remain unchanged.

In reviewing the RPS Manual Bypass Keylock Switch configuration in the SDD, it was found that the corresponding ESPS functions on an RPS microprocessor also are bypassed when the keylock switch is operated.

February 3, 2006 Page 21 However, there are no panel windows planned for indicating that the ESPS Set 1 functions for the corresponding RPS channel have been bypassed.

This could be an equipment configuration risk management issue, in that, if the corresponding ESPS 2 functions have been or are planned to be bypassed for maintenance, bypassing the corresponding RPS/ESF channel would place the ESPS in a 2-channel configuration, which is not in conformance with single failure requirements. A potential solution could be to change the windows to reflect the bypassing of RPS and ESPS functions in a channel. For example, window 1 could state, "RP/ESF 1 Channel A Trip Bypass."

Describe actions to be taken to ensure that operators are informed about this potential equipment configuration risk.

Duke! Response to RAI 45

[Proprietary Information - See Attachment 2]

rable I NRC Audit Review Items for RPSIESFPS Digital Upgrade Document No.

Description Status FANP Document No. 38-5069821 -001 Oconee Nuclear Station TXS RPS/ESPS Provided by electronic Replacement System Cabinet Design:

mail on 1/25/06 1 PPSCA0005 FANP Document No. 38-5069822-002 Oconee Nuclear Station TXS RPS/ESPS Provided by electronic Replacement System Cabinet Design:

mail on 1/25/06 1 PPSCA0006 FANP Document No. 51-5045379-00 ONS 1, 2, & 3 RPS/ESF Controls Upgrade Provided by electronic Design Specification for Key Locks and Key mail on 1/25/06 Switches FANP Document No. 51-5052833-01 ONS 1, 2, & 3 RPS/ESF Controls Upgrade Provided by electronic Hardware Design Solutions mail on 1/25/06 FANP Document No. 51-5058134-02 Oconee Nuclear Station, Units 1, 2, & 3 Provided by electronic RPS/ESF Controls Upgrade ID Coding Concept mail on 1/25/06 Test Case L01 0400A SIVAT LSELS Specifications, Job 4310002, Provided by electronic Outputs: EFHV0037 mail on 1/25/06 TXS-1 047-76-V2.0/01.04 (FANP SIVAT-TXS Simulation Based Validation Tool, Provided by electronic Document No. 01-5044046-00)

Version 1.4.0 mail on 1/25/06 Table 2 i ___

_!J

! i a_

I_ __v rs^^e rs

^ l I

updates of Documents provided In Response to September 6, 205, KAI Document No.

Description RAI #

Status RTM 011736 Requiremenlt Traceability Matrix - Update 1.L Provided by electronic mail on 1/24/06 FANP Document No. 51-9001334-002 Factory Acceptance Test Plan 1.J Provided by electronic mail on 1/26/06 FANP Document No. 51-90104194-ONS 1,2,3 RPS/ESFAS Controls Upgrade 1.1 Provided by electronic mail 000 Software Verification and Validation Plan on 1/26/06 FANP Document No. 51-9006444-000 ONS 1,2,3 RPS/ESFAS Controls Upgrade 1.E Provided by electronic mail Software Configuration Management Plan on 1/26/06 FANP Document No. 51-5072680-01 ONS 1,2,3 RPS/ESFAS Controls Upgrade 1.1 Provided by electronic mail Software Design Review Report on 1/30/06 OSC 2495, Rev. 6 Reactor Building Narrow Range Pressure 1.Q Provided by electronic mail Instrument LDop Accuracy Calculation on 2/3/06 (ES FAS)

OSC 8829 (replaces OSC 2759)

Wide Range RCS Pressure Uncertainty, 1.Q Provided by electronic mail (ESFAS HPI & LPI setpoints) on 2/3/06 OSC 8857 (replaces OSC 3416)

RPS Flux/Flow Ratio Uncertainty 1.Q Provided by electronic mail Evaluation on 2/3/06 OSC 8828 (replaces OSC 4048)

RPS RCS Pressure & Temperature Trip 1.Q Provided by electronic mail Function Uncertainty Analysis and on 2/3/06 Variable Low Pressure Safety Limit OSC 8856 (replaces OSC 7237)

RPS High Flux and Pump/Power Monitor 1.Q Provided by electronic mail Trip Function Uncertainty Analysis on 2/3/06

• Duke requests that the documents listed in Attachment 3 be withheld from public disclosure pursuant to 10 CFR 2.390.

Updated List of Outstanding NRC Commitments associated with RAI Responses RAI Commitment Status 11.H, Previous commitment:

In progress 43 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 Duke will provide this document when they are issued.

Revised commitment:

The Implementation Specification (or Space Code Listing for Software) is now expected to be issued by February 14, 2006. Duke will provide a copy when issued.

1.1 Previous commitment:

In progress 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 (provided 11/30/05, updated 1/31/06)

2) implementation - January 30, 2006

3) testing phase - May 4, 2006 Duke will provide these reports when they are issued.

Revised commitment:

This commitment is tied to the FAT schedule. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

-U February 3, 2006 Page 2 Updated List of Outstanding NRC Commitments associated with RAI Responses RAI Commitment Status 1.J Previous commitment:

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

FAT Plan November 30, 2005 (provided 11/30/05, updated 1/26/06)

FAT Procedure February 28, 2006 FAT Report May 4, 2006 Duke will provide the FAT Procedure, and Report when issued. Duke provided a revision to the FAT Plan in electronic format on January 26, 2006, via electronic mail. The revision removed Functions # 2 and #12 from the plan.

Revised commitment:

Duke's initial review of vendor provided FAT procedures concluded that significant revisions are needed prior to approval. Duke is re-evaluating the schedule for developing and issuing the FAT procedures, performing the FAT and issuing the FAT report. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

1.J Previous commitment:

In progress The Site Acceptance Test (SAT) 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, 20013 Duke will provide the SAT Plan, Procedure, and Report when they are issued.

Revised commitment:

This commitment is tied to the FAT schedule. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

February 3, 2006 Page 3 Updated List of Outstanding NRC Commitments associated with RAI Responses RAI Commitment Status 1.K Previous commitment:

In progress Copies of Volumes 1, 2 and 3 (Users Instruction Manual) will be provided as soon as they are available but no later than 3 weeks prior to the beginning of the Factory Acceptance Test (FAT), which is currently scheduled to begin on March 7, 2006.

Revised commitment:

This commitment is tied to the FAT schedule. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

1.L Previous commitment:

In progress The requirements traceability matrix (RTM) 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. The latest update was provided on January 24, 2006 by electronic mail.

Revised commitment:

This commitment is tied to the FAT schedule. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

1.Q Previous commitment:

Provided 2/3/06 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. As of January 12, 2006, these calculations are currently in final review and are expected to be issued within one week. Duke will provide a summary by January 31, 2006.

Revised commitment:

Duke provided an electronic copy of the calculations requiring revision on February 3, 2006 by electronic mail. Since Duke provided a copy of the revised calculations, Duke withdraws the commitment to provide a summary of the calculations.

M February 3, 2006 Page 4 Updated List of Outstanding NRC Commitments associated with RAI Responses RAI Commitment Status 18 Previous commitment:

In progress 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 May 4, 2006)

Revised commitment:

This commitment is tied to the FAT schedule. Duke will provide a revised schedule on or before February 21, 2006 by electronic mail.

37.b Oconee is currently developing an abnormal procedure (AP) to provide In progress the appropriate guidance for operator response to inadvertent actuation of ESPS. Duke will implement appropriate procedure changes to address the use of the ESFAS emergency override function prior to returning the ESPS system to service after installation.

February 3, 2006 Page 1 Affidavit of Gayle F. Elliott

AFFIDAVIT COMMC)NWEALTH 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 Framatorne ANP, Inc.'s input to the responses in of the letter to the NRC Document Control Desk from B.H. Hamilton, Vice President Oconee Nuclear Site, dated January 31, 2006 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 6, 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 IFANP 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 _'

L day of 2006.

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