ML053340287

Additional Information Pertaining to the License Amendment Request (LAR) for Rps/Esps Digital Upgrade Technical Specification Change (TSC) Number 2004-09, Supplement 3

ML053340287
Person / Time
Site:	Oconee
Issue date:	11/22/2005
From:	Rosalyn Jones Duke Power Co
To:	Document Control Desk, Office of Nuclear Reactor Regulation
References
TSC-04-09
Download: ML053340287 (31)

Text

Duke Duke RONALD A JONES Vice President

[P4owere Oconee Nuclear Site Duke Power ONOI VP / 7800 Rochester Hwy.

Seneca, SC 29672 864 885 3158 864 885 3564 fax November 22, 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 Additional Information Pertaining to the License Amendment Request (LAR) for RPS/ESPS Digital Upgrade Technical Specification Change (TSC) Number 2004-09, Supplement 3 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 a Reactor Protection System (RPS)/Engineered Safeguards Protection System (ESPS) digital modification and associated Technical Specification change. This Supplement provides the basis for Duke's conclusion that one aspect of the modification (common processor design) meets regulatory requirements and provides adequate safety.

The proposed Oconee ESPS design replaces the existing three channel system with two sets of ESPS channels (each set containing three channels with a two-out-of-three trip logic). One set of ESPS channels shares common processors with three of the four RPS channels. That is, Channel A of ESPS and Channel A of RPS share a common processor. The same is true for Channels B and C. Duke chose to add the second set of ESPS (the set that shares a processor with RPS) for maintenance and operational convenience and to improve overall system availability and reliability.

www.dukepower.com

U. S. Nuclear Regulatory Commission November 22, 2005 Page 2 Duke has evaluated applicable regulatory requirements and concluded that the common RPS/ESPS processor design complies. Duke has also evaluated other digital systems previously approved by the NRC and concluded that the Oconee RPS/ESPS common processor design is similar. In addition, the design provides capabilities and features that are beneficial to safe and reliable operation of Oconee. Duke believes the NRC should find the common processor design acceptable based on this demonstrated compliance with regulatory requirements, the precedence established by previous NRC approvals of similar designs, and the RPS/ESPS common processor being beneficial to safe and reliable operation of Oconee.

Duke considers resolution of the common processor design issue of the highest priority. As such, Duke requests NRC to expeditiously review Attachments 1 and 2. These attachments systematically present the bases for Duke's conclusion that the design provides reasonable assurance of compliance with applicable regulatory requirements and that public health and safety will be protected. contains information proprietary to Framatome ANP (FANP). An affidavit from Framatome ANP (FANP) is included as Attachment 3. This affidavit sets forth the basis on which the information may be withheld from public disclosure by the NRC pursuant to 10 CFR 2.790.

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

Very r y yours, R. A. Jones, Vice President Oconee Nuclear Site

U. S. Nuclear Regulatory Commission November 22, 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 22, 2005 Page 4 R. A. Jones, being duly sworn, states that he is Vice President, Oconee Nuclear Site, Duke Energy Corporation, that he is authorized on the part of said Company to sign and file with the U. S. Nuclear Regulatory Commission this revision to the Renewed Facility Operating License Nos.

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

R. A. eIIVice President Oconeel& ear Site Subscribed and sworn to before me this Zt'day of j4LJ 2005 N tary Public My Commission Expires:

N

- -'. S

- t

• 1..

-C\.

Attachment 1 - Non Proprietary Acceptability of RPSIESPS Common Processor Design Executive Summary The acceptability of the proposed Oconee Nuclear Station (ONS) Reactor Protection System (RPS)/Engineered Safeguards Protection System (ESPS) common processor design is systematically addressed by demonstrating conformance to regulatory guides and industry standards, similarity to systems previously approved by the NRC, and the reliability and operability merits of the RPS/ESPS integration.

The proposed ONS design has Protection System (PS) functions that are shared between RPS and ESPS (Subsystem 1) and fully redundant ESPS (Subsystem 2) functions that are not shared. The ESPS Subsystem 1 design combines the sense and command functions of the ESPS for protection channels A, B, and C with the corresponding protection channels A, B, and C for RPS functions. This results in ESPS functions of each respective protection channel sharing the same processor as RPS functions from the same channel. The ESPS Subsystem 2 consists of a set of protection channels A, B, and C, which perform ESPS functions alone (i.e., there is no sharing of processors with RPS functions).

The ONS RPS/ESPS conforms to all standards that require physical and electrical independence of redundant safety channels and conforms to all standards that require defense-in-depth for common mode failures postulated between those channels. The RPS/ESPS also conforms to all standards that require echelons of defense to ensure adequate accident mitigation. There are no industry standards that require a level of independence or separation that is not met in the proposed ONS RPS/ESPS design.

The requirements of GDCs 20, 21, 22, 23, 24, 27 and 29 discuss the Protection System in its entirety, which includes both the reactor trip system and the engineered safety feature system. IEEE Stds (279 and 603) referenced in 10 CFR 50.55a(h), state that the Protection System design consists of the reactor trip and engineered safety features functions. None of these regulations require independent or separate RPS and ESPS.

Independence and separation are only discussed by industry and NRC guidance documents as being between safety related channels and between safety and non-safety related systems. They do not discuss separation or independence between safety systems such as the RPS and ESPS. The proposed ONS design meets the requirements of these regulations. Guidance documents such as Regulatory Guide 1.75 and IEEE Stds 379, 384 and 7-4.3.2 discuss separation and independence as being between channels and between safety and non-safety related systems. Nothing in these documents precludes the integration of RPS and ESPS onto a common processor. The proposed ONS design follows these guidance standards.

HICB-BTP-19, NUREG/CR-6303 and NUREG-0493 recognize that the only regulatory requirements for separation or independence are between redundant safety divisions and between safety and non-safety divisions. Also implicit in these standards is the recognition that there are no regulatory requirements for separation or independence among the two safety echelons (RPS and ESF (ESPS for ONS)), and there are likely to be dependencies in these echelons due to process protection relationships and November 22, 2005 Page 2 commonality of implementation methods. These documents further recognize that even with these dependencies, the divisional redundancy within the safety systems, and their compliance to single failure requirements, result in a very low probability that any single failure would compromise both safety echelons. HICB-BTP-19, NUREG/CR-6303 and NUREG-0493 provide guidance for analysis of the interconnections and commonality between these safety echelons since these relationships usually exist in some form.

These documents provide guidance intended to ensure plants can cope with a common mode failure that adversely affects both safety echelons. This guidance includes both analysis methods and requirements for defensive design provisions.

Using the guidance provided in these documents, Duke has performed a Defense-in-Depth and Diversity assessment and has added a suitable diverse backup function to ensure that a safe shutdown can be achieved under the postulated initiating events and software common mode failure conditions (with credit for manual operator actions). A complete loss of RPSIESPS is assumed. The assessment re-analyzes the thermal-hydraulic response to a spectrum of transients and accidents, core and fuel response, and offsite and control room dose consequences. This assessment shows that there is sufficient defense-in-depth and diversity with the proposed ONS design to cope with even the most limiting software common mode failure (SWCMF) to the RPS and ESPS.

Therefore the guidance presented in HICB BTP-19 is met.

There is considerable precedence set for the use of components such as processors between RPS and ESFAS functions. This precedent has been set in operating plants, with both analog and digital based designs, in digital designs for ALWRs, and in the most recent SERs for generic PLC based platforms.

The reliability of the RPS and ESPS system is improved with the proposed design, and the ability to confirm that reliability, through on-line testing, is also improved. Combining RPS and ESFAS functions actually reduces the failure probability of the protection system for events that require both RPS and ESFAS functions. Improving reliability is the primary goal of the project, and is critical to improving nuclear safety.

In conclusion, regulatory requirements and guidance do not preclude sharing the same processor. In fact, significant regulatory guidance exists for coping with these interdependencies. As such, there is a sound technical basis for RPS/ESFAS interdependencies and precedence for these interdependencies in both operating plants and certified designs for new plants. These interdependencies result in designs that are more reliable and can be tested with minimal degradation to that reliability. The proposed design for the Oconee protection system meets the requirements necessary for protection functions to operate in a safe and reliable manner and complies with the requirements of all industry standards and criterion.

In consideration of the above, Duke concludes that the common processor design provides reasonable assurance of compliance with regulations of 10 CFR Chapter 1 and that public health and safety is maintained.

November 22, 2005 Page 3

Background

This Supplement provides a systematic basis for concluding that the Oconee common processor design meets regulatory requirements and provides reasonable assurance that the health and safety of the public will be protected.

The proposed Oconee ESPS design replaces the existing three channel system with two sets of ESPS channels (each set containing three channels with a two-out-of-three trip logic). One set of ESPS channels shares common processors with three of the four RPS channels. That is, Channel A of ESPS and Channel A of RPS share a common processor. The same is true for Channels B and C. Duke chose to add the second set of ESPS (the set that shares a processor with RPS) for maintenance and operational convenience and to improve overall system availability and reliability.

Currently, when an ESPS channel is out of service due to testing, maintenance or failure, Technical Specifications require the channel be placed in the tripped condition within one hour, effectively making the ESPS actuation logic one-out-of-two and increasing the probability of inadvertent actuation of an engineered safety feature. An inadvertent actuation is undesirable since it places an unnecessary challenge on plant systems. Since the proposed new design consists of two redundant sets of ESPS channels, with only one being required by Technical Specifications, there is no requirement (or need) to place a channel in trip when one or more channels of a redundant set are inoperable. Thus, the increased probability of inadvertent actuation is averted.

Duke introduced the common processor design concept in our initial planning meeting with the NRC in March of 2002 to discuss our licensing approach for the RPS/ESPS digital modification. Duke proceeded with that design because we considered it to be the most practical alternative to achieving our design objectives of replacing obsolete equipment and improving plant reliability. In addition, Duke did not sense any concerns on the part of the NRC staff associated with this design concept. Duke was also aware that there was precedence with conceptual advanced reactor designs that had similar combinations. The NRC indicated at the conclusion of that meeting that they found Duke's approach generally acceptable.

By letter dated September 6, 2005, the NRC requested additional information associated with the LAR. None of the questions were related to the sharing of processors between RPS and one set of ESPS. However, it appears that this remains an NRC staff concern based on recent meetings and conference calls.

The Oconee Defense-in-Depth and Diversity assessment performed by Duke assumes that a software common mode failure (SWCMF) causes a complete loss of RPS/ESPS and re-analyzes the thermal-hydraulic response to a spectrum of transients and accidents, the core and fuel response, and the offsite and control room dose consequences. This analysis shows that there is sufficient defense-in-depth and diversity with the proposed Oconee design to cope with even the most limiting SWCMF

I q.

November 22, 2005 Page 4 to both RPS and ESPS software. There is no difference in the results of this assessment with or without the use of the common RPS/ESPS processor.

Duke has reviewed applicable regulatory requirements and has concluded that the common RPS/ESPS processor design complies. In addition, the design provides capabilities and features that are beneficial to safe and reliable operation of Oconee.

The design is also similar to systems previously approved by the NRC.

1 Introduction The acceptability of the proposed Oconee Nuclear Station (ONS) Reactor Protection System (RPS)/Engineered Safeguards Protection System (ESPS) common processor design is systematically addressed by demonstrating conformance to regulatory guides and industry standards, similarity to systems previously approved by the NRC, and the reliability and operability merits of the RPS/ESPS integration.

• Section 2 describes the proposed design of the Oconee Reactor Protection System/Engineered Safeguards Protection System (RPS/ESPS).

• Sections 3 and 4 discuss conformance to regulatory criteria and industry standards.

• Section 5 compares the Oconee RPS/ESPS to designs previously approved by the NRC.

• Section 6 describes the positive attributes of the Oconee RPS/ESPS common processor design. The most significant benefit is that the reliability of the RPS and ESPS system is improved with the proposed design. This is the primary goal of the project, and is critical to improving nuclear safety.

• Section 7 provides the bases for Duke's conclusion that the Oconee common processor design complies with NRC regulations and protects the health and safety of the public.

• Section 8 provides a list of references.

2 Oconee RPS/ESPS Proposed Design

[Proprietary Information - Refer to Attachment 2]

3 Compliance with Regulatory Requirements NUREG-0800, Chapter 7,Section III states that the fundamental purpose of the NRC I&C review is to determine whether the facility or equipment, the proposed use of equipment, the operating procedures, the processes to be performed, and other technical requirements provide reasonable assurance that the licensee will comply with regulations of 10 CFR Chapter 1, and that the public health and safety will be protected (Reference 14). The upper tier document with respect to fundamental protection system November 22, 2005 Page 5 design requirements is 10CFR50.55a (h), which endorses both IEEE Standards 279-1971 and 603-1991 (References 1, 16, and 19, respectively). Each of these IEEE standards provides detailed guidance regarding protection system design requirements.

These two standards provide detailed design guidance for meeting the higher-level requirements of the General Design Criteria (GDC). Since both are endorsed by the CFR, they are requirements for all safety systems at nuclear plants.

3.1 10CFR50.55(a)(h), IEEE Std 279-1971, and IEEE Std 603-1991 10 CFR 50.55a (h) requires that plants either meet the provisions contained in IEEE Std 279-1971 or IEEE Std 603-1991. Digital platform modifications are typically designed to meet IEEE Std 603-1991, which provides the following fundamental statements regarding protection systems:

• In IEEE Std 603-1991 in Note (1) to Figure 1, the protection system is discussed as the sense and command features for both the reactor trip system and the engineered safety features.

• Figures 3 and 4 of IEEE 603 depict safety system partitions. RPS and ESFAS are shown within the same partition.

• Section 5.1 establishes the single failure criterion. There is no requirement that precludes a single failure impacting both RPS and ESFAS within the same channel, as long as that single failure does not impact RPS or ESFAS functions at the system level (i.e. multiple channels).

• Section 5.6 establishes safety system independence requirements. There is no discussion of a need for RPS/ESFAS independence.

• Figure A2 which shows a typical safety systems block diagram combines RPS and ESFAS in the same block.

Since IEEE 603 provides details that match up with the higher level GDC's, this leads to the conclusion that the 10CFR50 Appendix A General Design Criteria discussed below are describing requirements for the overall Protection System and not discussing requirements for only the reactor trip system or only the ESF system. RPS and ESF are in fact complementary systems within the protection system and therefore the two protections sub-systems are usually taken as one protection system when requirements are discussed. Using this definition, the single processor design for RPS and ESF at Oconee is acceptable in that the protection system functions are part of a unified sense and command feature for both RPS and ESFAS, which is the protection system per IEEE Std 603-1991.

Both of the IEEE Standards (IEEE Std 279-1971 and IEEE Std 603-1991) are in agreement that the RPS and the ESFAS are the protection systems at a nuclear plant.

Both state that redundant channels need to be independent. Neither standard includes any provision that the RPS and ESFAS need to be independent from each other. If the RPS and ESFAS as part of the protection system are required to be independent from November 22, 2005 Page 6 each other, this would be specifically addressed in both standards. The use of the same processor for RPS and ESFAS at Oconee meets the requirements of both IEEE standards.

3.2 10CFR50 Appendix General Design Criteria General Design Criteria (GDC) were selected that pertain to the protection system.

NUREG-0800 Chapter 7 provided guidance as to which GDC's (20, 21, 22, 23, and 24) were applicable to the Protection System. GDC's 27 and 29 were added based on discussions with the NRC Staff.

3.2.1. Criterion 20-Protection System Functions. The protection system shall be designed (1) to initiate automatically the operation of appropriate systems including the reactivity control systems, to assure that specified acceptable fuel design limits are not exceeded as a result of anticipated operational occurrences and (2) to sense accident conditions and to initiate the operation of systems and components important to safety (Reference 3)

Criterion 20 describes the protection system as the integration of RPS functions (item 1 above) and ESFAS functions (item 2 above). Therefore, this GDC does not address or preclude the separation or integration of RPS and ESFAS functions on one processor.

3.2.2. Criterion 21-Protection System Reliability and Testability. The protection system shall be designed for high functional reliability and in-service testability commensurate with the safety functions to be performed. Redundancy and independence designed into the protection system shall be sufficient to assure that (1) no single failure results in loss of the protection function and (2) removal from service of any component or channel does not result in loss of the required minimum redundancy unless the acceptable reliability of operation of the protection system can be otherwise demonstrated. The protection system shall be designed to permit periodic testing of its functioning when the reactor is in operation, including a capability to test channels independently to determine failures and losses of redundancy that may have occurred (Reference 4).

Criterion 21 treats the RPS and ESFAS as an integrated protection system. There is nothing that would preclude or discourage integration. The single failure requirement (item 1) pertains to the entire protection system. There is no requirement that would lead to partitioning single failures to impact only RPS or ESFAS. Similarly, the removal of service requirement (item 2) pertains to the entire protection system. There is nothing here that would allow removal of RPS functions, while maintaining ESFAS functions.

Both must meet the minimum redundancy requirements at all times.

November 22, 2005 Page 7 3.2.3. Criterion 22-Protection System Independence. The protection system shall be designed to assure that the effects of natural phenomena, and of normal operating, maintenance, testing, and postulated accident conditions on redundant channels do not result in loss of the protection function, or shall be demonstrated to be acceptable on some other defined basis. Design techniques, such as functional diversity or diversity in component design and principles of operation, shall be used to the extent practical to prevent loss of the protection function (Reference 5).

Criterion 22 treats the RPS and ESFAS as an integrated protection system. The TXS has been environmentally (including seismic and EMI/RFI) qualified to ensure the proposed Oconee design is capable of performing its safety functions while exposed to the effects of natural phenomena. As required in the above IEEE standards and in this GDC, the redundant channels are independent and separated from each other within the protection system. This Criterion does not require or encourage RPS/ESFAS independence. Functional diversity as required by this GDC implies functional diversity within the RPS or within the ESFAS and not between the two systems. Design techniques, as used in the original Oconee design have been reused to provide functional diversity to the extent practical and to prevent loss of the protective function within the RPS and within the ESFAS.

3.2.4. Criterion 23-Protection System Failure Modes. The protection system shall be designed to fail into a safe state or into a state demonstrated to be acceptable on some other defined basis if conditions such as disconnection of the system, loss of energy (e.g., electric power, instrument air), or postulated adverse environments (e.g., extreme heat or cold, fire, pressure, steam, water, and radiation) are experienced (Reference 6).

Criterion 23 treats the RPS and ESFAS as an integrated protection system. There is nothing that would preclude or discourage integration. The proposed Oconee protection system as implemented with the TXS platform remains a fail-safe system. The TXS has been designed to operate in all expected adverse environments. The common processor design does not prevent the protection system from failing into either a safe state or a state demonstrated to be acceptable as required by this GDC.

3.2.5. Criterion 24-Separation of Protection and Control Systems. The protection system shall be separated from control systems to the extent that failure of any single control system component or channel or failure or removal from service of any single protection system component or channel which is common to control and protection systems leaves intact a system satisfying all reliability, redundancy, and independent requirements of the protection system.

Interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly impaired (Reference 7).

November 22, 2005 Page 8 The Oconee common processor application does not impact this Criterion. Criterion 24 is a clear indication that separation and independence of functions was carefully considered when the GDC was written. Based on the well-defined scope of this Criterion, it is reasonable to conclude that if separation of RPS and ESFAS were also considered significant to nuclear safety, separation and independence requirements would also be specified; but they are not.

3.2.6. Criterion 27-Combined Reactivity Control Systems Capability. The reactivity control systems shall be designed to have a combined capability, in conjunction with poison addition by the emergency core cooling system, of reliably controlling reactivity changes to assure that under postulated accident conditions and with appropriate margin for stuck rods the capability to cool the core is maintained (Reference 8).

Criterion 27 treats the RPS and ESFAS as an integrated protection system. This criterion raises no concerns regarding the common processor application for RPS and ESFAS. To ensure a high degree of reliability the proposed TXS based application at Oconee is designed to meet the strict design criteria required for safety related hardware and software. As with the current Oconee design the reactivity control and boron addition functions provided by the ESFAS will operate in a reliable fashion.

3.2.7. Criterion 29-Protection against AnticipatedOperational Occurrences.

The protection and reactivity control systems shall be designed to assure an extremely high probability of accomplishing their safety functions in the event of anticipated operational occurrences (Reference 9).

Criterion 29 treats the RPS and ESFAS as an integrated protection system. To ensure a high degree of reliability the proposed TXS based application at Oconee is designed to meet the strict design criteria required for safety related hardware and software.

Evaluation of the software and hardware reliability with a common RPS/ESFAS processor shows that the Oconee TXS system has an extremely high probability of accomplishing its safety function and therefore meets the requirements of this GDC.

Conclusion Duke has provided reasonable assurance that the common processor design will comply with regulations of 10 CFR Chapter 1, and that the public health and safety will be protected. The design complies with both IEEE Standards 279-1971 and 603-1991 that are endorsed by 10CFR50.55a (h) and applicable General Design Criteria (GDC).

4 Conformance of Regulatory Guidance NRC and industry guidance documents that provide information regarding defense-in-depth and diversity (D-in-D&D), separation and independence, and software were November 22, 2005 Page 9 evaluated to determine whether guidance on the use of a common processor for ESFAS and RPS is addressed. The results of this evaluation are provided below.

4.1 NUREGICR-6303 The purpose of NUREG/CR-6303 is two-fold; it provides an analysis to be used to demonstrate adequate D-in-D&D and it is used as a constructive design technique to add diverse systems (Reference 15). NUREG/CR-6303 discusses the four echelons of defense (control system, reactor trip system, engineered safety features system, and monitoring and indication system) associated with instrumentation and control systems.

It recognizes the dependencies that commonly exist between these echelons such as the dependencies between RPS and ESF, and it describes necessary defense-in-depth provisions to cope with these dependencies.

NUREG/CR 6303 provides guidance for the independence and diversity between the four l&C echelons. This NUREG states that the control echelon should be independent and separate from the safety related echelons. NUREG 6303 further states that the monitoring, indication and manual echelons need to be diverse (and therefore independent from the safety echelons). This implies that the functions that are needed for diverse actions as part of the D-in-D&D analysis need to be diverse and independent.

It allows for a common mode failure (CMF) to disable both the RPS and ESFAS echelon and also allows for the loss of two of the echelons at the same time. To compensate for this lack of independence, NUREG 6303 provides a method to analyze these interdependencies and provide suitable alternate means to deal with CMF's that may impact both echelons Duke concluded that it is acceptable for the RPS and ESF to be combined as long as the D-in-D&D assessment described by NUREG-6303 is successful. The D-in-D&D assessment performed for Oconee concludes that adequate diversity exists to provide a safe shutdown. An additional non-safety related, diverse Low Pressure Injection actuation was added to the Oconee design, but not because of the common processor application. This diverse actuation is needed for compliance to NUREG/CR-6303 even if the RPS and ESPS processors were completely separate. The Oconee design meets the guidance provided in NUREG/CR-6303.

4.2 HICB BTP-19 This BTP establishes the four separate echelons as in NUREG/CR-6303. Section 3 is the only place where interconnections between the RPS and ESFAS are discussed.

Section 3 states that interconnections between RPS and ESFAS are permitted provided that it can be demonstrated that functions required by the ATWS rule (10 CFR 50.62)

(Reference 2) are not impaired. The Oconee design using common processors does not impair the functions required by the ATWS rule and the D-in-D&D analysis discussed in the BTP was successfully performed as discussed above. Therefore, the proposed Oconee design meets the guidance discussed in BTP-1 9. There is adequate diversity within the proposed Oconee design to provide for safe shutdown given a software November 22, 2005 Page 10 common mode failure to the TXS platform, including the common processor application.

Therefore, the Oconee design meets the guidance of BTP-1 9.

4.3 IEEE Standard379-1988, 1992 and 2000 This Standard (2000 version) in Paragraph 6.3.1 states that all non-safety systems or other safety systems (e.g. alternate channels) coupled in some manner to safety systems to which the single-failure criterion is applied shall be examined to establish whether any failure within these systems can degrade the safety systems to which they are coupled (Reference 17). If they can degrade any portion of the safety systems to the point of failure, those failures shall be assumed to exist as an initial condition to the single failure analysis of the safety system. IEEE Std 384-1992 provides additional guidance in this area.

The 1988 version of this standard used the term "other systems" and gave as an example "test circuitry". Other safety systems were not mentioned. The 1994 version of this standard used the term "all other systems" and also uses "non-safety test circuitry as an example.

The 2000 version of this standard has amplified these criteria by using both all non-safety systems and other safety systems. However the issue addressed by this standard is when a different channel of one safety system is dependent upon a different channel of another safety system, and then the single failure criterion should be taken after the channel failure of the different system. The proposed design for Oconee has the same ESPS channel and RPS channel sharing a processor. There are three ESPS channels, thus; this involves three separate processors-one for each ESPS channel. For the Oconee design, the RPS and the ESPS channelization process is maintained. There is no interaction between RPS and ESPS channels. Therefore, the failure preceding the single failure analyses does not have to be assumed. The first failure to be assumed is the single failure, which can be the entire processor or part of the RPS or ESPS actuation hardware/software. Nevertheless, the FMEA performed for the proposed Oconee design shows that the design requirements of both IEEE Standards 603-1991 and 279-1971 are met with regard to the single-failure criterion and that the proposed Oconee design complies with the guidance of IEEE Std 379.

4.4 NUREG-0493 (1979)

NUREG-0493 was the first Defense-in-Depth and Diversity NUREG that discussed causal failures between l&C echelons of defense (Reference 12). This NUREG states in Section 2 that the scram system plus the ESF actuation system comprise the 'protection system" as defined by the General Design Criteria and IEEE Standard 279. The NUREG states that the causal relationships between the echelons are examples of some form of independence. In the RESAR-414 review the NRC took an approach to diversity termed "approach using a specified degree of system separation," by which the NRC meant that the (then) three functional echelons of defense (control, RPS, and ESFAS) were to be sufficiently separated and diverse so that postulated CMF events did November 22, 2005 Page 11 not lead to unacceptable consequences. These consequences were to be analyzed using the guidance provided by the NUREG.

The NUREG states this it is not possible to have total independence between the three echelons because the different systems that comprise the three echelons of defense all form part of a single power plant-a single reactor. The problem becomes specifying the degree of independence that is acceptable and determining methods to maintain an acceptable level of safety in spite of the presence of a degree of dependence.

The NUREG states that interdependence between reactor trip and ESF actuation systems is considered in the "Technical Report on Anticipated Transients Without Scram for Light Water Reactors". It states that further guidance will be developed as a result of that rulemaking. This guidance was issued in 10 CFR 50.62 (ATWS Rule). The Oconee design meets the provisions of the ATWS rule and, with the D-in-D&D analysis, follows the guidance presented in this NUREG.

4.5 RG 1.75 and IEEE Standard 384 These guidance documents provide design information for separation and independence and only discuss maintaining acceptable levels between redundant channels and between safety related and non-safety related systems (References 10 and 18). They do not address separation or independence between any safety related systems such as the Oconee ESPS and RPS. A review of IEEE Standard 384shows that Class 1E circuits need to be separated from non-Class 1E circuits and that channel independence must be maintained. The Oconee design complies with this guidance. Channel separation is maintained with the proposed common processor design.

4.6 RG 1.152 and ANSI/IEEE Std 7-4.3.2 These guidance documents provide additional computer-specific requirements (incorporating hardware, software, firmware, and interfaces) to supplement the criteria and requirements of IEEE Standard 603-1998 (References 11 and 20).

A review of the latest version of IEEE Std 7-4.3.2 regarding separation and independence concludes that new requirements for independence were added to supplement IEEE-603. IEEE 7-4.3.2 adds, "in addition to the requirements of IEEE Std 603-1998, data communication between safety channels or between safety and non-safety systems shall not inhibit the performance of the safety function." IEEE Standard 603-1998 requires that safety functions be separated from non-safety functions such that the non-safety functions cannot prevent the safety system from performing its intended functions. In digital systems, safety and non-safety software may reside on the same computer and use the same computer resources.

IEEE 7-4.3.2 states that non-safety and safety software can reside on the same computer and use the same computer resources as long as the non-safety system does not inhibit the performance of the safety function. Again, the standard focuses on November 22, 2005 Page 12 separation of non-safety systems from safety systems. The proposed Oconee design complies with these guidelines.

Conclusion The Oconee RPS/ESPS common processor design complies with applicable NRC and industry guidance documents that provide information regarding defense-in-depth and diversity, separation and independence, and software.

5 Precedents for RPS/ESFAS Common Processor Design The sharing of components such as a processor between RPS and ESF is not a new concept. Traditionally, components have been shared in current reactor analog I&C configurations for many years. Both Combustion Engineering and Westinghouse designed nuclear plants have taken advantage of this shared component concept.

5.1 Westinghouse Plants Figure 5.1 below highlights the RPS/ESF shared component design in use at many Westinghouse designed plants.

November 22, 2005 Page 13 Westinghouse 7300 / SSPS - Catawba, McGuire, Comanche Peak, Byron, Braidwood, and others

>~~~~~~~~. P i ti s a- - ;;7300 7'7300 '

ivChannel Channel

.-B -

.1

. ' ,- 1, - -.7 -,, - ,

RPS Like 7 Coincidence

'-'SSPS tLogi 2/N Logic~ 2/NTri 1 - -Train T61n 2:"

ItReactor Trip- 7,77-.,.  :,AS- RPS Like

.-.. Switchgear-, 4

'; ""11!'.- -1.

9F.....,. ... Coincidence 2 Breakers Lopic 2/N

/2 ES Like ES Like Bistables are analog Coincidence Coincidence Logic is solid state Logic 2/N Logic 2/N discrete Trami Train 2.::

Shared between RPS & ESFAS Figure 5.1 Typical Protection System for Westinghouse Plants Shared RPS & SSPS Components (Steam Generator Low-Low Level Trip)

In Westinghouse designed nuclear plants, some process input sensors such as the transmitter shown in the above figure, are shared for both reactor trip and ESF functions.

A shared analog input card is used for signal conversion and scaling. This card acquires the transmitter signal and sends it to separate bistables for RPS and ESF functions. For one parameter where the setpoint is the same for RPS and ES (Steam Generator Low-Low Level) the same bistable is used for both RPS and ES as shown in Figure 5.1. The split signal is then sent to a shared solid state protection system (SSPS) voting logic where the output is directed to either a train of RPS Reactor Trip Breakers or ESF actuated components. Separate 2/4 voting cards are provided within the shared SSPS.

There is no electrical independence between RPS and ESFAS functions within a 7300 channel or within a single train of SSPS.

November 22, 2005 Page 14 5.2 CE Plants All Combustion Engineering plants built from ANO-2 forward (ANO-2, SONGS, Waterford, and Palo Verde) have a Plant Protection System (PPS). The PPS is a combination of the RPS and ESFAS systems (Figure 5.2), which were separated on previous generation plants. Within the PPS the same analog bistables, 2/4 relay matrices for like parameter coincidence and initiation relay logic are used commonly for RPS and ESFAS initiation. The ESFAS functions have an additional selective 2/4 relay coincidence matrix at the actuation level in each Train. The RPS has a separate selective 2/4 coincidence at the actuation level: this is through the arrangement of the trip breakers.

CE Plants: ANO-2, SONGS, Waterford, Palo Verde

' .,Channel' RP In, *;itiation Loi EA I 7 r I -. V>

I T

I 4I

.Reactor Trip Switchgear I

';*' 4 Breiakers!' - ,2 Selective 214 ..

]a.,. ~~ESFAS ,c',i i ,^;

,Selective 2/4 C. .:

Bistables are analog Logic is relays Train 4' Interchannel signals are hardwired "l Shared between RPS & ESFAS Figure 5.2 CE Plants (SONGS, Waterford, Palo Verde) typical protection system Shared RPS & ESFAS components November 22, 2005 Page 15 5.3 System 80 +

The Certified System 80+ ALWR has the same PPS design architecture (Figure 5.3) as previous CE plants. However, for System 80+, the analog bistables are implemented in a PLC and the 2/4 like parameter coincidence and initiation logic is in a separate PLC.

This PLC is shared between RPS and ESFAS. The ESFAS has separate PLC's in each Train for the selective 2/4 actuation logic. This one PLC is common to all ESFAS functions. The selective 2/4 actuation logic for the RPS is through the arrangement of the trip breakers, as in the earlier designs.

System 80+

Channel Cliiaine'l -.Channel:

--B. E .D >1.-.

.. . - . ., Is . ..

i .-  ;.

I

~. I . ~ 1I ..-......

.1

+

+ 7 v ;..'; .

. Y .; .- . - . . ' -. ' \: ' {' !._

= ,-,- :: J - .,, ,,.;,i;r.

9 ...........

I z

,: A-  ;  :,

so,

..  : A, A:

.  :. \.1,.

. f. ..

Jo

. .I I .I .

I I

. '"-1'-': i'-:

+

I . . . l

+

4- 1 - i"'

I'Reactor Trip Switchgear l

.z.4 Breakers . :.. .

Bistables and logic are software Intercnannel signals are fiber optic links [s.:- Train . . Train 2 l---l Shared between RPS & ESFAS Figure 5.3 System 80+ typical protection system Shared RPS & ESFAS components November 22, 2005 Page 16 5.4 Common Qualified Platform Several RPS/ESFAS configurations were recently approved by the NRC. One duplicates the System 80+ integrated RPS/ESFAS configuration. In this design the PLC's are simply replaced with the approved AC160 controller platform. This is shown in Figure 5.4. This recently approved configuration still integrates RPS and ESFAS functions in common AC1 60 controllers.

The Combustion Engineering Topical Report CENPD-396-P, Rev 01, with Appendices 1, 2, 3 and 4, was reviewed by the NRC. A Safety Evaluation Report was provided by the NRC under letter to Mr. Phil Richardson, Westinghouse Electric Company, on August 11, 2000. The Digital Plant Protection System concept in Appendix 3 of CENPD-396-P Rev. 01 describes certain RPS and ESFAS functions that are combined on a single processor in each channel (Reference 22). Section 4.4.3.3 of the SER, specifically concludes, for the described DPPS application:

"...On the basis of its review, the staff concludes that the DPPS design complies with the requirements of IEEE 603-1991 with regard to system independence and, therefore, satisfies the requirements of GDC 22."

".. the proposed DPPS design satisfies the requirements of GDC 24."

"On the basis of the above review, the staff concludes that the design approach to be used for the replacement of existing RPS, ESFAS, and PPS functions with the Common 0 platform as set forth in Appendix 3 is acceptable..."

November 22, 2005 Page 17 Common Q - ANO-2, Waterford, SONGS, Palo Verde, Sys 80+

3 i Channel.<.

-A .

. Channel -

.B

-Channel '.

..,.C' '-

,.'Channiel '

i~", '- ,,.

-. 4-4 I-

. ], + +  ; ,., ' .

vt.

' . n ,  ! .,

', '; 1v;'.-' '

- + Z r i

,' +..,'.'.'. -

. _i i _; ".E "'

.t @

r.. . ': , . x, t.. 8 >....

' ' ,' ' -. . 7 .. ' R.',

_ r_ ., _ '.

-1 1

-.Reactor Trip' Sitchgear .--

i - I-I-

.- I

.. _xl rz m _ __

lo,

'.. , I

- '4 Breakers -'

ESFAS t c

.".-Selective'2/4 . ' ACI Selective2/4- D

. 160 '

13 Bistables and logic are . I  :

software 'Train 2 Interchannel signals are fiber optic links Shared between RPS & ESFAS Figure 5.4 Common Q-ANO2, Waterford, SONGS, Palo Verde, Sys 80+

Shared RPS & ESFAS components.

Conclusion Precedent exists for the RPS/ESPS common processor design. NRC has approved shared component designs on many existing Westinghouse plants and Combustion Engineering plants. NRC has also approved common processor designs for the advanced light water reactor design for the System 80+ design. Additionally, several RPS/ESPS configurations were recently approved by the NRC. One duplicates the System 80+ integrated RPS/ESFAS configuration.

November 22, 2005 Page 18 6 Common Processor Benefits A redundant ESPS actuation system was incorporated into the Oconee design to provide protection against spurious trips and to reduce unavailability of the system. To implement this redundancy the common processor design approach was chosen over using separate processors for RPS and the second ESPS actuation train. Current regulations and guidance are met with this approach and design precedence using common components including processors has been set by other designs.

The common processor approach yields the simplest design with far fewer hardware components. To achieve this redundancy using separate processors for the redundant ESPS would at a minimum require new, input modules and output modules. The decision was made by Oconee personnel to limit the complexity of the redundant ESPS design by using the existing RPS processors and their associated devices thereby eliminating the additional hardware.

When there is less hardware, there are fewer components to fail. This leads to fewer component replacements that must be managed by plant technicians, planners and schedulers, and fewer spare parts that must be maintained in plant inventory.

Eliminating extra hardware also eliminates its configuration control and the configuration for the embedded software, thereby reducing the potential for configuration control errors. Fewer components make the modification easier to install and test during the transition outage. Less hardware reduces the manual testing required which also reduces the potential for spurious actuations and/or plant alarms that must be managed by plant operators.

Presently, the Oconee ESPS is a three channel system with "2-out-of-3" trip logic.

During testing and also under certain maintenance and/or failure conditions, the ESPS logic reverts to a "1-out-of-2" logic. The probability of inadvertent actuation of the Safety Features is increased during these periods of plant operation, which creates a safety concern since a single failure or a single sensor with an incorrect reading will cause an inadvertent actuation of a safety system(s). This is an undesired action because it causes an unnecessary challenge to plant systems. For example, RBS would be actuated and spray down containment unnecessarily.

One of the goals of this modification is to make the ESPS design less susceptible to inadvertent actuations while maintaining its reliability. After evaluating several design concepts, Duke concluded that a redundant ESPS actuation system was the best option available. The proposed Oconee design provides a redundant"2-out-of-3" ESPS subsystem. This design lowers the probability of inadvertent actuation while at the same time equaling or increasing the current ESPS actuation reliability.

The proposed Oconee design includes ESPS redundancy within each channel (i.e. two subsystems). This redundancy improves the actuation reliability of each channel. In addition, the redundancy allows one subsystem or a portion of a subsystem to be taken out of service for testing or repair without loss of function within the channel, since the other subsystem remains fully operable. Therefore, ESPS continues to be OPERABLE

Attachment 1 November 22, 2005 Page 19 in accordance with Technical Specifications (TS) and there is no need to enter the TS ACTIONS during testing and repair activities. By putting the ESFAS functions into the existing RPS processors, redundancy for ESFAS functions was achieved without adding additional hardware and significant complexity. Optimum design efficiency and reliability is achieved with this proposed design while maintaining increased costs at an acceptable level.

RPS and ESFAS functions are complementary functions and some Postulated Initiating Events (PIE) require only RPS actuation while others require both RPS and ESFAS actuations as mitigating functions in the Oconee accident analysis (Table 6.1). There are no PIE's that require an ESFAS actuation without RPS.

p i _; E > S - . ,.., .-; i,-

-. Section A Postulated Initiating Ev 15.2 '-Startup Accident '. no yes

[15.3 Po: i awti cien.~~,

l 15.4 - Moderator Dilution Accidents  :,no , ', yes Lij5Cl atrA cd n ZZ IL p~

W~~

15.6- Loss of Coolant Flow Accidents ,no , yes 5T7T-_-Y- LR~od Mhis~alignmenit A~cciden-ts7-- "~ -- UZZ7'IZ T - 9j7 Lys Ai 5.8 - Turbine Trip Accident ,  : ' ^ no yes a' Ta ubekR up.tu-r'Ac c ident LuE i/a' nI/a n/a J

1i5i 0-Waste Gas Tank'Rupture Accident ' ,! , , '

i 5.12 - Rod Ejection Accident ' yes, ' yes D 514- Loss of Coolant Accidents .yes yes 15.16 - Post Accident Hydrogen Control ,-.:n/a ' n/a 1 Sall earLi BreakAcid n/a - not applicable Table 6.1

!' i, November 22, 2005 Page 20  ! .

If both functions are implemented in the same hardware and both are required for mitigation, and if the unavailability of the hardware is U, then the probability of not mitigating an accident is P = U.

If Trip Functions and ESFAS functions are implemented in separate hardware, again with unavailability U for each processor, then the resulting probability that an accident is not mitigated when both functions are required is P = 2U. This means the separation of trip and ESFAS functions increases the failure probability by a factor of two for those initiating events requiring both functions for success.

The failure probability for an event requiring RPS or ESFAS only is unchanged since the failure probability is U for the function.

The TXS operating system software is the same for both RPS and ESPS functions. The ESPS application software is either the same or very similar to the RPS application software because of the similarity of the functions being processed. Only a small portion of the ESPS application, consisting of simple signal processing routines, is performed in the RPS/ESPS CPU while the application of ODD/EVEN actuation voting and component actuation is performed by separate CPUs. The voter logic in the application software is not shared between RPS and ESPS functions and is kept separate and November 22, 2005 Page 21 independent from each other. Therefore, the probability of any ESPS added software failure impacting the RPS functions is extremely small.

The Oconee Defense-in-Depth and Diversity assessment (Duke submittal dated March 20, 2003) assumes that a SWCMF causes a complete loss of RPS/ESPS and re-analyzes the thermal-hydraulic response to a spectrum of transients and accidents, the core and fuel response, and the offsite and control room dose consequences. This analysis shows that there is sufficient defense-in-depth and diversity with the proposed Oconee design to cope with even the most limiting SWCMF to both RPS and ESPS software. There is no difference in the results of this analysis with or without the use of the common RPS/ESPS processor.

A review of the proposed design shows that by combining functions on a common processor no new spurious actuation events are created that are not already covered in the Oconee design basis. The design meets the single failure criterion due to the use of redundancy within the RPS and ESPS. The probability of a component failure which results in the loss of RPS or ESPS function when both are required is reduced with the proposed design as compared to a design with separate RPS and ESPS processors.

Thus, the potential for inadvertent actuation due to component failure or testing by placing the system into a 1-out-of-2 state is reduced. Finally, operating data in worldwide applications demonstrate that for those plants which have a common processor for RPS and ESPS functions there have been no inadvertent actuations and no failures to respond when initiating conditions exist.

7 Conclusion The above GDC's clearly refer to the Protection System in its entirety, which includes both the reactor trip system and the engineered safety feature system. The IEEE Standards (IEEE Std 279-1971 and IEEE Std 603-1991) referenced in 10 CFR 50.55a (h) state that the Protection System design consists of the reactor trip and engineered safety features functions. None of the regulations require independent or separate RPS and ESFAS. Independence and separation are only discussed by industry and NRC guidance documents as being between safety related channels and between safety and non-safety related systems. These guidance documents do not discuss separation or independence between safety systems such as the RPS and ESFAS. The proposed Oconee design using the common processor application meets all regulations and follows the applicable guidance as discussed in this paper.

HICB-BTP-1 9, NUREG/CR-6303 and NUREG-0493 recognize that the only regulatory requirements for separation or independence are between redundant safety divisions and between safety and non-safety divisions. Also implicit in these standards is the recognition that there are no regulatory requirements for separation or independence among the two safety echelons (RPS and ESFAS), and there are likely to be dependencies in these echelons due to process protection relationships and commonality of implementation methods. These documents further recognize that even with these dependencies, the divisional redundancy within the safety systems, and their November 22, 2005 Page 22 compliance to single failure requirements, result in a very low probability that any single failure would compromise both safety echelons. In fact, this probability is so low that failures of this nature (SWCMFs) are considered to be outside the licensing design basis. Nevertheless, HICB-BTP-19, NUREG/CR-6303 and NUREG-0493 recognize the existence of dependencies between RPS and ESFAS, and they are written to analyze the interconnections and commonality between these safety echelons since these relationships usually exist in some form. These documents provide guidance intended to ensure plants can cope with a common mode failure that adversely affects both safety echelons. This guidance includes both analysis methods and requirements for defensive design provisions. Using the guidance provided in these documents Oconee has performed the analysis (Defense-in-Depth and Diversity) and has added a suitable diverse backup function to ensure that a safe-shutdown can be achieved under the postulated initiating events and common mode failure conditions (with credit for manual operator actions).

The Defense-in-Depth and Diversity methodology used assumes that SWCMF causes a complete loss of RPS/ESFAS and re-analyzes the thermal-hydraulic response to a spectrum of transients and accidents, the core and fuel response, and the offsite and control room dose consequences. This analysis shows that there is sufficient defense-in-depth and diversity with the proposed Oconee design to cope with even the most limiting SWCMF to the RPS and ESFAS TXS based functions and therefore the guidance presented in HICB BTP-19 can be met.

Considerable precedence exists for shared RPS and ESFAS components in many operating plants today. The sharing of components for RPS and ESF functions has been accepted both by industry and the NRC for the analog l&C designs. This precedence also extends into digital processors for integrated RPS/ESFAS designs in the certified ALWR's, and to the integrated RPS/ESFAS configurations most recently approved for generic digital safety platforms. Obviously all regulations and guidance have been followed with these shared designs or the designs would have changed to an independent and separate architecture for RPS and ESFAS. The continuation of this safe-design practice is being implemented with the Oconee common RPS and ESFAS processor application.

The advantages of using a shared processor have been presented in Section 6. The common processor approach yields the simplest design with far fewer hardware components. Sharing allows complete ESFAS redundancy to be achieved without adding more Class 1E equipment that must be maintained and can potentially fail causing adverse conditions. When there is less hardware, there are fewer components to fail. This redundancy results in higher reliability for ESFAS actuation and it allows components to be taken out of service for maintenance and testing, while maintaining full ESFAS functionality in all safety channels. This design lowers the probability of inadvertent actuation while at the same time equaling or increasing the current ESPS reliability.

In conclusion, regulatory requirements and guidance do not preclude sharing the same processor. In fact, significant regulatory guidance exists for coping with these November 22, 2005 Page 23 interdependencies. As such, there is a sound technical basis for RPS/ESFAS interdependencies and precedence for these interdependencies in both operating plants and certified designs for new plants. These interdependencies result in designs that are more reliable and can be tested with minimal degradation to that reliability. The proposed design for the Oconee protection system meets the requirements necessary for protection functions to operate in a safe and reliable manner and complies with the requirements of all industry standards and criterion.

In consideration of the above, Duke concludes that the common processor design provides reasonable assurance of compliance with regulations of 10 CFR Chapter 1 and that public health and safety is maintained.

8 References

1. Code of Federal Regulations Title 10 Part 50.55a(h), "Protection Systems,"

January 1, 2004.

2. Code of Federal Regulations Title 10 Part 50.62, "Requirements for Reduction of Risk From Anticipated Transients Without Scram (ATWS) Events for Light-Cooled Nuclear Power Plants".

3. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 20, "Protection System Functions", January 1, 2004.

4. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 21, "Protection System Reliability and Testability", January 1, 2004.

5. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 22, "Protection System Independence", January 1, 2004.

6. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 23, "Protection System Failure Modes", January 1, 2004.

7. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 24, "Separation of Protection and Control Systems", January 1, 2004.

8. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 27, "Combined Reactivity Control Systems Capability", January 1, 2004.

9. Code of Federal Regulations Title 10 Part 50, Appendix A, Criterion 29, "Protection Against Anticipated Operational Occurrences", January 1, 2004.

10. USNRC Regulatory Guide 1.75, Revision 2, "Physical Independence of Electrical Systems."

11. USNRC Regulatory Guide 1.152, Revision 1, "Criteria for Digital Computers in Safety Systems of Nuclear Power Plants," January1996.

12. NUREG-0493, "A Defense-in-Depth & Diversity Assessment of the RESAR-414 Integrated Protection System," March 1979.

. 1, November 22, 2005 Page 24

13. NUREG-0800, "Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants", Chapter 7, Revision 4, June, 1997.

14. NUREG-0800, "Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants", Branch Technical Position HICB-1 9, "Guidance for Evaluation of Defense-in-Depth and Diversity in Digital Computer-Based Instrumentation and Control Systems," Revision 4, June, 1997.

15. NUREG/CR-6303, "Method for Performing Diversity and Defense-in-Depth Analyses of Reactor Protection Systems," December 1994.

16. ANSI/IEEE Std 279-1971, "Criteria for Protection Systems for Nuclear Power Generating Stations."

17. ANSI/IEEE Std 379-1988,1992, and 2000, "Standard Application of the Single-Failure Criterion to Nuclear Power Generating Station Safety Systems."

18. ANSI/IEEE Std 384-1992, "Criteria for Independence of Class 1E equipment and Circuits."

19. IEEE Std 603-1991, "IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations."

20. ANSI/IEEE 7-4.3.2-1993, 2003, "IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations."

21. Safety Evaluation by the Office of Nuclear Reactor Regulation, Siemens Power Corporation Topical Report EMF-21 10(NP), 'TELEPERM XS: A Digital Reactor Protection System, Project No. 702.

22. Combustion Engineering Topical Report CENPD-396-P, Rev 01, with Appendices 1,2, 3 and 4.

AFFIDAVIT COMMONWEALTH OF VIRGINIA )

) ss.

CITY OF LYNCHBURG )

1. My name is Gayle F. Elliott. I am Manager, Product Licensing in Regulatory Affairs, for Framatome ANP ("FANP"), and as such I am authorized to execute this Affidavit.

2. I am familiar with the criteria applied by FANP to determine whether certain FANP information is proprietary. I am familiar with the policies established by FANP to ensure the proper application of these criteria.

3. I am familiar with Framatome ANP, Inc.'s input to the responses in of the letter to the NRC Document Control Desk from R.A. Jones, Vice President Oconee Nuclear Site, dated November 15, 2005 and entitled "Additional Information Pertaining to the License Amendment Request (LAR) for RPS/ESPS Digital Upgrade," Technical Specification Change (TSC) Number 2004-09, Supplement 3, 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 IovQK ver 2005.

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