ML083080453
| ML083080453 | |
| Person / Time | |
|---|---|
| Site: | Oconee  |
| Issue date: | 11/12/2008 |
| From: | Olshan L Plant Licensing Branch II |
| To: | Baxter D Duke Energy Carolinas |
| Olshan L N, NRR/DORL, 415-1419 | |
| References | |
| TAC MD7999, TAC MD8000, TAC MD8001 | |
| Download: ML083080453 (13) | |
Text
November 12, 2008 Mr. David Baxter Vice President, Oconee Site Duke Energy Carolinas, LLC 7800 Rochester Highway Seneca, SC 29672
SUBJECT:
TRIP REPORT FOR U.S. NUCLEAR REGULATORY COMMISSION (NRC)
STAFFS OCONEE NUCLEAR STATION, UNITS 1, 2, AND 3 (OCONEE) -
THREAD AUDIT AT AREVA FOR DIGITAL UPGRADE OF THE REACTOR PROTECTIVE SYSTEM (RPS) AND ENGINEERED SAFEGUARDS PROTECTIVE SYSTEM (ESPS) (TAC NOS. MD7999, MD8000, AND MD8001)
Dear Mr. Baxter:
By letter dated January 31, 2008, (ML080730339), you submitted a license amendment request (LAR) to accommodate replacement of the existing Oconee analog based RPS and ESPS with a digital computer based RPS/ESPS. Subsequent to the LAR acceptance, which was documented in our letter dated April 24, 2008 (ML081070521), we visited Oconee from May 19 through May 22, 2008, to discuss certain issues related to acceptance of the LAR to ensure that you had properly considered the requirements for effective digital system design in the upgrade and to review your oversight of the engineering practices used by AREVA NP, Inc. (AREVA) when developing the digital RPS/ESPS systems. The trip report was sent to you on July 23, 2008, (ML081900197).
We visited AREVA facility in Alpharetta, Georgia from September 15 through September 19, 2008 to perform a thread audit. The purpose of the audit was to determine if the life cycle processes used, and the outputs of those processes, will result in a RPS/ESPS system for use at Oconee which will meet regulatory requirements. Enclosed is the trip report for this visit.
Please contact me at 301 415-1419, if you have any questions on this trip report.
Sincerely,
/RA/
Leonard N. Olshan, Project Manager Plant Licensing Branch II-1 Division of Operating Reactor Licensing Office of Nuclear Regulation Docket Nos. 50-269, 50-270, and 50-287
Enclosure:
As stated
TRIP REPORT FOR U.S. NUCLEAR REGULATORY COMMISSION (NRC) STAFFS OCONEE NUCLEAR STATION, UNITS 1, 2, AND 3 (OCONEE) - THREAD AUDIT AT AREVA FOR DIGITAL UPGRADE OF THE REACTOR PROTECTIVE SYSTEM (RPS) AND ENGINEERED SAFEGUARDS PROTECTIVE SYSTEM (ESPS) (TAC NOS. MD7999, MD8000, AND MD8001)
Background
By letter dated January 31, 2008, (ML080730339), Duke Energy Carolinas, LLC (Duke , the licensee) submitted a license amendment request (LAR) to accommodate replacement of the existing Oconee analog based RPS and ESPS with a digital computer based RPS/ESPS.
Subsequent to the NRC staffs acceptance of the LAR, which was documented in the NRC letter dated April 24, 2008 (ML081070521), the NRC staff visited Oconee from May 19 through May 22, 2008, to discuss certain issues related to acceptance of the LAR to ensure that the licensee had properly considered the requirements for effective digital system design in the upgrade and to review your oversight of the engineering practices used by AREVA NP, Inc. (AREVA) when developing the digital RPS/ESPS systems. The trip report was issued on July 23, 2008, (ML081900197).
AREVA Visit The Instrumentation and Controls Branch (EICB) chief and staff (William Kemper, Paul Loeser, Norbert Carte, Iqbal Ahmed, and Richard Stattel) visited the AREVA facility in Alpharetta, Georgia from September 15 through September 19, 2008 to perform a thread audit. The purpose of the audit was to determine if the life cycle processes used, and the outputs of those processes, will result in a RPS/ESPS system for use at Oconee which will meet regulatory requirements.
The audit was conducted for the following aspects of the Oconee software life cycle:
- 1. Software Verification and Validation (V&V): Verification that the Oconee application software V&V program meets the requirements of IEEE 1012, and that the V&V program is implemented in a manner which will reliably verify and validate the design outputs of each stage of the design process.
- 2. Configuration Management (CM): Verification that the CM system has the appropriate hardware and software under configuration management, and the CM system is effectively controlling the items under configuration management.
- 3. Software Quality Assurance (SQA): Verification that the SQA program is effective in controlling the software development process to assure quality of the Oconee application software.
- 4. Software Safety (SQA): Verification that the software safety plans and the plans and procedures used during the software safety analysis activities were adequate to determine that the software was safe to be used in a safety related application at Oconee.
- 5. Hardware, Software, and Procedure Changes: Verification that the changes to the TELEPERM XS platform hardware, software, and development procedures since approval of the TXS Topical Report in 2000 are acceptable.
Audit Summary
- 1. Thread audit of the Oconee application Software V&V program A thread audit of a number of systems and software requirements was performed to track implementation of those requirements through each phase of the design process using the requirements traceability matrix (RTM), and to show how the design phase outputs were subject to the V&V process. The Software V&V plans for each phase of the software life cycle were tracked for establishing an effective implementation of V&V plans in the design and design acceptance process to determine if the AREVA V&V team was sufficiently independent in terms of cost, schedule and management. V&V team members explained identified problems and provided documentation of the changes, including CM documentation and changes to the specification.
AREVA has used a software program called RequisitePro, which maintains a database of the Oconee RTM (AREVA Doc. No. 51-9002060) that includes the Hardware Requirement Matrix (HRM) and Software Requirement Matrix (SRM). The SRM lists Software Requirement Specification (SRS), provides the requirements text, and leads to tracing the Functional Requirement Specification (FRS), the Software Design Description (SDD), and I&C replacement system specifications and Function Block Diagrams. In the year 2007, the AREVA V&V team verified the entire database and the thread audit documentation were provided to the audit team from this database.
Audit was performed on the following four threads:
- 1. This thread was performed by selecting a set of function blocks shown in the SDD (Figure 4.1), tracing these function blocks backwards to find the requirements for them in the customer specifications, and tracing the function blocks forwards to the code, and the review of the code by V&V. The selected thread was: What requirements do the analog input upper core and lower core limit violation function blocks in the RPS Trip #1 implement?
The NRC staff was able to successfully trace this thread forwards and backwards through the design documentation, without using the RTM (i.e., by reading the design documents). However, during the course of performing the trace using the RTM several discrepancies were observed; therefore, AREVA initiated three corrective actions (CR 2008-5083, CR 2008-5104, & CR 2008-5109) in accordance with AREVA internal procedures. The attachment contains the detailed audit results, including description of these discrepancies. The discrepancies are summarized below:
- 1) The design phase and implementation phase V&V activity summary reports did not contain revision indications in the reference lists and AREVA could not identify which version of the code document was reviewed or what version of the SDD it was reviewed against, based on V&V reports provided to the NRC staff during the audit.
- 2) The V&V team was not aware that any system requirements existed in change orders and did not trace the requirements that exist in any change order.
- 3) The design phase and implementation phase V&V activity summary reports contained signatures verifying that certain persons independently reviewed the reports, and the reports document that these same persons also performed some of the work described in the reports.
Based on the audit performed, the following conclusions were reached:
- 1) All requirements are not in the RTM; e.g., commercial and process requirements.
- 2) Most software parameters have not been included in the RTM.
- 3) Several design input documents were not traced in the RTM (e.g., Software Parameters, Change Orders, and Clarification memos).
- 2. This trace started with Duke Function Description (FRS) Section 1.5 which states: When an adjustable parameter can be entered from a Graphic Service Monitor (GSM) screen the GSM screen shall enforce the range limits on the entered value. The NRC staff was able to successfully trace this thread forwards and backwards through the design documentation, without using the RTM (i.e., by reading the design documents).
This requirement was traced with the design team to the GSM SRS (AREVA Doc. No.: 51-9051854-003) Section 3.2.3.3 where the requirements are restated, and reference is made to the GSM SRS, Section 3.3, which contains specific parameters and values.
It was established that details of what is changeable on a GSM screen and the enforcements of limits is documented in two change orders (2005-08 and 2005-10, 12, & 13) and an associated clarification memo. The requirements in these change orders have not been traced by V&V. The values of the Flux flow parameter limits were not traced by V&V.
The flux gain parameter of Trip #1 was identified in the GSM SRS as a GSM Screen changeable parameter, but this was not documented in the code document. There is an open item to remove the flux gain from the GSM screens.
- 3. This thread was performed for the RPS Nuclear Overpower (Neutron Flux) Trip function specified in Software Requirements Specification (LAR document # 51-9054435-02). The trace was for the condition that when shutdown bypass is initiated, the High Flux Trip setpoint is lowered to the S/D Bypass High Flux Trip Setpoint. When any of the power signals reach the new trip setpoint, the associated channel is tripped. The SRM listed applicable sections of LAR AREVA documents 51-9054435-001(SRS description) and 51-5065423-07 (SDD with function block diagram) and Duke documents OSC-8623, Rev. 5 (FRS calculations) and OSS-0311.00-00-0013(system functional Requirement description- Enhancement in RPS functional capability were reviewed for consistency and traceability.
No anomaly was identified in this trace. However, during the course of the trace, two AREVA Operating Instructions OI-1618-01,Independent V&V Engineering/Design Engineering Interface and OI-1457-05,TELEPERM XS Software Quality Assurance Plan were reviewed. Some ambiguous wording in Section 6.2 of OI-1618-01 and insufficient information to justify certain statements in Sections 3.2.2 and 4.2.2 of OI-1457-05 were identified. The AREVA V&V group initiated the necessary changes to both documents.
4 This thread was performed for the System Functional Testing Requirement SRS 3.1.6.5 which states, Calibration of instrument loops or other analog input simulation shall be accomplished without having to use sliding links or lifting leads. No anomaly was identified in this trace.
During the trace of this thread from the SRS requirement to the function block diagram, the NRC staff compared the SRM statement with those in the applicable LAR documents. It was noted that the SRM statement for this requirement and the sections of the documents listed in the SRM for traces are consistent with the LAR document No. 51- 9054435-001, ONS-1 RPS/ESF Software Requirement Specification, Section 3.1.6.5, Duke document No. OSS-0311.00-00-0012, ESFAS Replacement Project Specification, Duke document No. OSS-0311.00-00-0013,RPS Replacement Project Specification, and IEEE Std 338,IEEE Standard Criteria for the Periodic Surveillance Testing of Nuclear Generating Station safety Systems, endorsed by the Regulatory Gide RG1.118.
- 2. Configuration Management (CM)
The Staff reviewed AREVAs Software Configuration Management Plan (AREVA Doc.
No. 51-9006444-005) and determined that AREVA does not maintain a separate Software Configuration Management organization for the Oconee project; therefore, individuals from Design Engineering as well as the Software Librarian were interviewed to assess the Software Configuration Management functions that are performed for the Oconee RPS/ESFAS upgrade project.
A process walk-through for software document control was performed for this assessment. During this walk-through, a hypothetical software document revision was postulated. AREVA personnel described the processes and controls that are in place to ensure that the document configuration would be maintained throughout the change process. The document archival system called Documentum was demonstrated to provide revision control, as well as rules for approval to coincide with the Operating Instructions (OIs) that are used by the engineering team. Several of the Documentum configuration rules were challenged. One such challenge involved attempting to check a document out for a new revision when it had already been checked out to another engineer. The Documentum system did not allow this action. The Documentum program accomplished this by disabling certain options or graying out the associated buttons so that they could not be selected when the rights or rules for configuration control were not met.
A second process walk-through was performed for a software program component. A change to the application code was postulated. The Software Librarian described the software check-out and check-in processes that would have to be followed by the
program development engineer for this change. This included the authorization and sign out requirements, as well as disk labeling requirements. Copies of the approved software were provided to the engineer responsible for the change while originals were maintained in the locked climate controlled storage area. The process for backing up and storing all software at the remote Lynchburg facility was also reviewed.
A postulated parallel software transaction request was then proposed while the software was in the checked out or development status. Though the Software Librarian explained that he would not allow a second issuance of the checked-out software, there were no procedural controls in place to prevent such a situation from occurring. It was explained that this situation would be self revealing when the two versions of the same revision of the software component were checked in. In this instance, a Condition Report would have been written to address the situation and direct resolution thereof. This was identified as a program weakness and AREVA personnel agreed to add measures to the governing OI to prevent this occurrence.
Future Action: Review Additional requested AREVA documentation listed below as well as Oconee software configuration management program to determine degree of compliance to industry standards.
OI-1583 Software Library and Control OI-1460 Software Configuration Management Plan
- 3. Software Quality Assurance The NRC staff determined that AREVA does not maintain a separate Software Quality Assurance (SQA) organization; therefore, individuals from Design Engineering, and Project Quality Assurance were interviewed to assess the SQA functions that are performed by those organizations.
The Quality Assurance (QA) organization does not have personnel with Software Development proficiency; therefore, they rely on the Software V&V team to perform software specific QA functions. The overall SQA program is owned by the Instrumentation and Control Systems Manager for implementation.
It was determined that the QA manager does have the authority to halt the design process when conditions are warranted. The QA manager is independent from the Design Authority and reports to the QA department in Lynchburg Va.
The review team requested that a random Condition Report (CR) be provided for review.
CR 2008-3296 was selected for this purpose. The subject CR was written by QA during system hardware testing to identify several deficiencies that were noted during test performance.
Item one identified a potential personnel qualification discrepancy.
Item two identified a potential M&TE calibration discrepancy.
Item three identified a software version discrepancy.
Item four identified a document release discrepancy.
Evaluations of the identified issues were provided, as well as descriptions of corrective actions taken. Corrective actions included procedure revisions, personnel training, obtaining appropriate certification documentation, and software revision re-verification.
Some preventive measures were put into place, however, no follow-up effectiveness evaluation was provided. It is therefore difficult to assess the effectiveness of these measures.
An Open Item report was also selected at random for review and evaluation. The document selected was Open Item report No. O1.0984 FU-0009 Application Code Error.
This report identified an error that occurred when a software diagram was being transferred from the Software Design Description to the Function Block Diagram in the SPACE tool. This discrepancy was discovered during the preparation of the RPS SW functional Test Specification. The error involves an incorrect connection to the input of an SBB filter when the correct connection was to the output. The Open Item report documented the extent of the error by including the Function Block diagrams for all four divisions of coding. Proposed corrective actions were documented; however, no requirement to perform Retest of the modified function block was identified.
Future Action: Review the AREVA-submitted documentation listed below as well as Oconee QA program to determine the degree of compliance to industry standards.
OI-1618 Independent V&V Engineering / Design Engineering Interface OI-1457 Software Quality Assurance Manual
- 4. Software Safety The NRC staffs review of information previously submitted by the licensee indicated that AREVA does not have a separate software safety group, and these duties are assigned to the technical manager and the design organization, with the V&V group reviewing these activities. AREVA stated that the software safety plan follows the concepts of IEEE 1228 but does not fully comply.
AREVA did not perform a separate software safety analysis, but believes that the Criticality Analysis, the Defense-in-Depth and Diversity Report, the SRM, the FMEA, the Response Time Analysis, the V&V reports, the Test Summary Report (SIVAT), and the Factory Acceptance Test Summary Report made a software safety analysis unnecessary.
The NRC staff did not agree, and after discussion with AREVA personnel, it was agreed that AREVA would produce a software safety analysis which would discuss each of the reports mentioned above, and show how the information in these reports contributed to software safety, and how the information, when considered together, would adequately demonstrate that the software has not introduced discrepancies that could contribute to a hazard.
The NRC staff agreed to review this analysis, and to determine if it meets the regulatory requirements. The NRC staff has also determined that it will compare the requirements of IEEE-1228 with ONS Units 1, 2, & 3 RPS/ESFAS Controls Upgrade Software Safety Plan, AREVA Doc. No.51-9005043 to determine whether the Software Safety Plan meets the appropriate regulatory requirements.
- 5. Hardware, Software, and Procedure Changes The intent of this activity was not to review individual changes, but to come to an agreement with AREVA on the level of detail needed for the NRC staff to determine that the changes were appropriate and did not invalidate the approval of the TXS system as documented in the May 5, 2000 safety evaluation.
This issue had been the subject of RAI question No. 52, and AREVA provided a draft response to this question. The NRC staff reviewed the draft response, and determined that while the information provided was appropriate, it was not sufficient for the required NRC staffs determination. The NRC staff discussed with AREVA personnel what additional information would be required.
The final agreement was that AREVA would modify the draft response to RAI question No. 52 to specifically address differences in the lifecycle for hardware and software design, how those differences meet the standard review plan, meet the endorsed standards, meet the qualification process approved in the TXS Topical Report, and satisfy the established qualification requirements. The NRC staff would review this information, and in those cases where other AREVA documentation is referenced, would review that other documentation on a sampling basis, similar to the sampling of requirements and documentation performed during the original review of the TXS system and during the thread audit. The physical location of where these documents would be available for NRC staff review was left as an open item.
Principal Contributors: Paul Loeser, NRR/DE/EICB Norbert Carte, NRR/DE/EICB Iqbal Ahmed, NRR/DE/EICB, Richard Stattel, NRR/DE/EICB William Kemper, NRR/DE/EICB
DETAIL AUDIT ISSUES FROM THE FIRST THREAD This attachment contains details related to the first thread reviewed as part of the thread audit.
These details are being recorded so that a specific record of these details exists.
The limit violation function blocks driving computer points depicted in SDD Figure 4.1 were traced (backwards) in the RTM to be an implementation of SRS Section 3.1.1.5, which states:
- Computer Point No. 13 - NI-5 Upper UCIC Limit Violation shall be sent to OAC...
- Computer Point No. 14 - NI-5 Lower UCIC Limit Violation shall be sent to OAC....
These statements were traced (backwards) in the RTM to be an implementation of the following three customer requirements:
(1) RPS Specification (OSS-0311.00-00-0013) Section 5.8, OAC Interface, states:
The replacement RPS/ESFAS channels shall interface with the OAC. Data shall be transferred from each RPS/ESFAS channel to the OAC in a secure and reliable manner for all modes of operation including normal operation, testing and calibration. The Supplier shall ensure that communication between the RPS/ESFAS and OAC is accomplished in a manner that ensures that no creditable OAC fault or failure can adversely affect the ability of the RPS/ESFAS to perform their safety functions when required.
The Oconee OAC is a Science Applications International Corp. (SAIC) Plant Monitoring System (SAIPMS). Additional information relating to the OAC interface can be found in Attachment C. The OAC interface shall use OPC gateway(s) except for SOE points, which shall remain twisted shielded pairs.
(2) RPS Specification Attachment C (RTM No. RPS1.19 on PDF pg 858)
Note: Attachment C contains one page of description of the RPS/ESFAS to OAC Data-Link Details and a one page figure of the gateway to be provided by AREVA.
(3) System Description (DUKE Doc. No OSC-8623 Rev. 5) Section 25.4.2 states:
Analog signals from field sensors that deviate from predetermined parameters shall be alarmed to the OAC gateway.
These three general requirements are for the OAC Interface, not the data that the interface will transmit. The function blocks being traced generate the data that will be transmitted. From these general requirements for an interface, it is not possible to un-ambiguously determine what data to transmit through the interface. The design team stated that AREVA and Duke determined and documented (per Change Order 2005-08 and Supplemental Clarification #1 to the change order) what data to include in the OAC Interface. This change order and associated clarification memo were not identified by the V&V team and were not included (i.e., traced) in the RTM. The V&V team stated that it did not trace any requirements from change orders; AREVA wrote CR 2008-5104 to track this item.
AREVA stated that there were 1400 points transmitted over the OAC Interface. If each of the three general requirements (identified above) is traced to each of these points, there would be 4200 traces. All of these traces are unnecessary.
AREVA stated that there exists a documented agreement (between Duke and AREVA) that identifies all of the 1400 points to be transmitted over the OAC interface. If each of the points is traced to the documentation that requires that it be transmitted, this would be only 1400 traces.
All of these traces are necessary.
The RTM did not trace the analog input upper core and lower core limit violation function blocks back to specific requirements that this data be transmitted through the interface. There exist at least one other specific requirement (that was also not traced in the RTM) related to these function blocks; the software parameters document (Duke Doc. No. OSC-8695 Rev. 2, page 21) states:
Parameter #5 Basis: The A-MRC block monitors for AO1 <limit>. An out of range signal is not desirable on low NI Flux. A -1% RTP setting would ensure this. By using a negative number the parameter would be obviously unreachable however, the parameter is available for future use by the end user if desired.
The last clause of this quotation provides a feature (in addition to the change order and clarification memo) that could also have been traced; however, the V&V team did not find this feature. A related issue is that the V&V team did not trace the requirements of the software parameters document in accordance with the software V&V plan (see related description of RAI Question Nos. 55 and 58 below). The design team pointed to change orders and a clarification memo as the requirement for the traced function blocks.
If there are two different locations (in the customer requirements documentation) for a particular function requirement, then both of these locations should be traced (for configuration management purposes).
Since there were three general requirements traced to the function block, it appeared to the V&V team that the tracing of these requirements was complete. It appears to the NRC that too many, or unnecessary links, make it hard to determine: (a) what is required to implement a requirement, and (b) that all requirements are implemented.
The RTM did not trace the alarm limit violation functionality to the Software Parameters document (OSC-8695) where the values of the limits were specified. This issue was already generally identified by the NRC in RAI Question No. 58. From the documentation available at site (i.e., AREVA Doc. No. 51-5072680-005, ...Design Phase V&V Activity Summary Report) it appears that the traceability of the Software Parameters was not done in accordance with the software V&V plan (SVVP), but rather as part of the SDD review (Task 2, Section 4.2).
The RTM did not trace the alarm limit violation functionality to RPS Specification Section 7.2, which is RTM Requirement No. RPS2.7.2.4 (RTM PDF pg 921). The RPS Specification (in Section 7.2) states:
d) Data Validity The software shall contain logic to perform checks on the validity of the input values, including user entries, and on the validity of any intermediate results. This system check
shall try to limit/inhibit the output of erroneous results. There shall be no known input value or combination of known input values to the system that will cause any system processor to cease functioning. Also, the removal of a channel's instruments while on-line shall not inhibit the overall system functional design performance in other channels.
This requirement traces to SRS2.4.4 (RTM PDF pg 936) which is SRS Section 2.4 d)
(SRS PDF page 45) and then traces to SDD5 (RTM PDF pg 2104) which states Not Applicable.
Since the code is represented in graphical form online in SPACE, or printed in graphical for in
.PDF format, the RequisitePro tool is not very effective for tracing individual requirements to the code; therefore a MS word file was created that contains all of the sheet names of the functional block diagrams, and the requirements were traced to these sheet names.
In the process of tracing the activities associated with this thread, the V&V review of the code was considered. The V&V review of the code is documented in the implementation phase V&V activity summary report (AREVA Doc. No. 136-9086711-000, Section 4.2), which does not contain document revision indication for those in its reference list. Therefore it was not possible to determine, from the summary report, which versions of documents were used in the review in this activity. Subsequently the V&V team relied on a list to identify the versions used, but upon examination, felt that this list was not accurate; AREVA wrote CR 2008-5083 to track this item.
The forward tracing to the test documentation has not yet been performed by AREVA.
Related process aspects learned There is no GSM SDD (Just a code document). There was a document that was called a SDD, and an open item was generated to change this to a code document since it more correctly reflected the contents of a code document rather than a SDD.
The V&V team gets a completed (through 10 CFR 50 Appendix B Independent Review) design document from the design team (per OI 1618-01 Section 7.2.3.3).
Documents are manually updated in RequisitePro separately from the design team updates of the design documents.
The NRC asked AREVA to identify what procedural requirements apply to the review of the V&V reports; AREVA stated that AREVA Administrative Procedure 0403-11 Rev. 27, applies.
Section 7.0 C of 0403-11 Rev. 27 states that the reviewer of the V&V phase summary reports is required to be independent (i.e., 10 CFR 50 Appendix B Independent Review). The implementation phase V&V report documents that an independent reviewer performed the work described in the report; AREVA wrote CR 2008-5109 to track this item. (Subsequent review by the staff, at headquarters, identified that the same condition exists in the requirements phase V&V report and the design phase V&V report.) The discussion of this issue identified two aspects:
(1) The AREVA conventions enable one to clearly document the functions (i.e., preparer or reviewer) performed by each person signing the document, on a section or page basis; therefore, it is possible for a person to be an author of one part of a document and an independent reviewer of another part, and this can be clearly documented.
(2) In the discussion of the issue documented in CR 2008-5109 AREVA personnel said that if someone documents (i.e., PREPARED BY:) a task performed by another, then one would want the performer of the task to review the description of the task. This is obviously true; however, there are procedural requirements on those who independently review (i.e., sign as REVIEWED BY:). It appeared as though AREVA personnel did not understand the distinction between informally reviewing a document and independently reviewing a document.
Conclusions In many instances, individual requirements are not identified in the RTM, but rather blocks of text are identified as requirements.
The SW parameter values that are only in the DUKE Software Parameters document are not contained in the SRS or the RTM; therefore, the software parameters contained in the DUKE Software Parameters document are not traced into the SRS as represented in RTM trace topology shown on Page 2 of Attachment F (AREVA Doc. No. 50-9062040-002). This issue is also discussed in RAI Question Nos. 55 & 58 and the associated response.
Traceability of the SW Parameters is addressed in the Design Phase V&V summary report, but is not performed in accordance with the SVVP. This report also does not contain a statement of the traceability evaluation performed by V&V. This issue is also discussed in RAI Question Nos.
55 & 58 and the associated response.
The V&V phase summary reports do not contain all of the statements of the results of the evaluations required by the SVVP.
The author of the design phase V&V summary report and V&V Supervisor could not produce the information requested by the NRC staff; therefore, it was not clear to the NRC staff who did what, and when, for the code review. CRs 2008-5083 and 2008-5109 were generated to address issues, and the results of these CRs and affected report changes will be sent to the NRC staff.
Mr. David Baxter Vice President, Oconee Site Duke Energy Carolinas, LLC 7800 Rochester Highway Seneca, SC 29672
SUBJECT:
TRIP REPORT FOR U.S. NUCLEAR REGULATORY COMMISSION (NRC)
STAFFS OCONEE NUCLEAR STATION, UNITS 1, 2, AND 3 (OCONEE) -
THREAD AUDIT AT AREVA FOR DIGITAL UPGRADE OF THE REACTOR PROTECTIVE SYSTEM (RPS) AND ENGINEERED SAFEGUARDS PROTECTIVE SYSTEM (ESPS) (TAC NOS. MD7999, MD8000, AND MD8001)
Dear Mr. Baxter:
By letter dated January 31, 2008, (ML080730339), you submitted a license amendment request (LAR) to accommodate replacement of the existing Oconee analog based RPS and ESPS with a digital computer based RPS/ESPS. Subsequent to the LAR acceptance, which was documented in our letter dated April 24, 2008 (ML081070521), we visited Oconee from May 19 through May 22, 2008, to discuss certain issues related to acceptance of the LAR to ensure that you had properly considered the requirements for effective digital system design in the upgrade and to review your oversight of the engineering practices used by AREVA NP, Inc. (AREVA) when developing the digital RPS/ESPS systems. The trip report was sent to you on July 23, 2008, (ML081900197).
We visited AREVA facility in Alpharetta, Georgia from September 15 through September 19, 2008 to perform a thread audit. The purpose of the audit was to determine if the life cycle processes used, and the outputs of those processes, will result in a RPS/ESPS system for use at Oconee which will meet regulatory requirements. Enclosed is the trip report for this visit.
Please contact me at 301 415-1419, if you have any questions on this trip report.
Sincerely,
/RA/
Leonard N. Olshan, Project Manager Plant Licensing Branch II-1 Division of Operating Reactor Licensing Office of Nuclear Regulation Docket Nos. 50-269, 50-270, and 50-287
Enclosure:
As stated Accession Number: ML083080453 NRR/LPL2-1/PM NRR/EICB/BC NRR/LPL2-1/BC OFFICE NAME LOlshan WKemper MWong DATE 11/4/08 10/10/08 11/12/08 OFFICIAL AGENCY RECORD