ML080840044

Corrected NRC Handout from 03/18/2008 Meeting, Draft

ML080840044
Person / Time
Site:	Oconee
Issue date:	03/20/2008
From:	- No Known Affiliation
To:	Office of Nuclear Reactor Regulation
References
Download: ML080840044 (4)

Text

'Draft The Instrumentation and Controls Branch is nearing completion of the acceptance review of the license amendment request (LAR) in accordance with revision 3 of LIC 101, License Amendment Review Procedures (ML040060258) and believes at this time that the licensee has provided sufficient information to accept this LAR and begin a comprehensive review. However, this review has identified several significant challenges to further review and acceptance of this LAR. The issues involved were communicated in weekly TELECONS (see Issues 1-6 below).

The staff expects the licensee to provide a schedule for the submission of information to resolve these issues by April 1, 2008.

Issues

1.

Section 3.2.3 of Enclosure 1 of the LAR provides a summary of the Diversity and Defense-in-Depth (D3) assessment and states that the methodology and acceptance criteria of BTP HICB-1 9 were used in the original assessment (reference was made to the analysis that was submitted in the previous submittal). Section 3.2.3 provides a qualitative analysis of the current operator action response time of two minutes versus the Interim Staff Guidance (ISG) on D3 for a minimum of 30-minute operator action time.

Section 3.2.3 also explains the benefits of the diverse LPI and HPI actuation for software common mode failure concern. The staff will evaluate D3 assessment in accordance with the ISG on D3; additional information to support this evaluation may be required.

2.

Bidirectional communications among safety divisions and between safety and non-safety equipment (interdivisional communication) is acceptable provided certain restrictions are enforced to ensure that there will be no adverse impact on safety systems. The ISG on Highly-Integrated Control Rooms - Communications Issues (HICRc), describes the methods that the staff will use to evaluate licensee compliance with NRC requirements

'vith respect to interdivisional communication. The ISG section on interdivisional communication contains 20 staff positions for which the staff needs information beyond what is in the LAR in order to evaluate the communications strategy of the application.

3.

The LAR states that the TXS application software development was performed in accordance with the Software Program Manual (SPM). The Office of New Reactors (NRO) is currently reviewing the referenced SPM; however, this is not an approved program at this time. Therefore, the licensee should provide stand alone documents for application software quality assessment.

4.

Section 2.7 of Enclosure 1 of the LAR identifies various TXS system hardware, software, and development procedure changes. Those changes are listed and explained in Tables 2-3, 2-4, and 2-5. The differences are between the approved TXS topical report and the Oconee digital platform design. The LAR does not contain enough information for the staff to reach a determination of the acceptability of these deviations. Therefore the staff needs information to make an acceptability determination.

LIC-1 01 (ML040060258) provides framework for processing license amendment,(and other licensing actions, where applicable) and states: "If a licensee in their application or the NRC staff during its review identifies a deviation from the process or limitations associated with a topical report, the staff should address the deviation in its SE for the plant-specific license amendment application. To address deviations from approved topical reports, the SE for the.subject amendment should identify the limitation or

Draft condition, evaluate the proposed deviation against appropriate regulatory criteria, and specifically explain why the deviation is acceptable (or not acceptable)"

5.

Regulatory Guide 1.168, Revision 1, dated February 2004 endorses IEEE 1012-1998 and IEEE 1028-1997 with the exceptions stated in the Regulatory Position of the regulatory guide describes a method acceptable to the NRC staff for complying with parts of the NRC's regulations for promoting high functional reliability and design quality in software used in safety systems. SRP Table 7-1 and Appendix 7.1-A identify Regulatory Guide 1.168 as SRP Acceptance criteria for reactor trip systems (RTS) and for engineered safety features systems (ESF). The LAR and other associated documents have described certain exceptions to IEEE 1012-1998. In particular, IEEE 1012 makes the generation of various test plans the duty of the V&V organization. The Areva V&V plan, document 51-9010419-005, "Oconee Nuclear Station Unit 1 RPS/ESFAS Controls Upgrade Software Verification and Validation Plan," makes this test plan generation the responsibility of the design or test organizations. The information provided in the LAR and in Areva document 51-9047317-009, "Position Paper: Conformance of TELEPERM XS Application Software with IEEE Ste 1012-1998,"

does not contain sufficient detail to allow the staff to determine the acceptability of this deviation. The staff will require additional information to determine if the proposed alternative to the requirements of IEEE 1012 will provide an equivalent confidence in a high quality test process, and therefore an equivalent confidence in the safety of the resultant system. The additional information to be provided should include that information provided to the licensee for their determination that this alternative to IEEE 1012 was acceptable, and may include the following:

- Documentation of independent V&V Group's Assessment of Testing

- Documentation of V&V Group's Role/Interaction with the Test Group

- Documentation of how Problems identified by the test were Resolved

- Documentation of Duke's Review of the V&V Testing Practices

6.

The LAR documentation indicates that use of the SIVAT tool (Simulation and Validation Tool) makes Component and Integration tests unnecessary. This approach is unfamiliar to the staff and does not appear to be consistent with industry standards and regulatory guidance. The use of the SIVAT tool was not identified in the TXS topical report, and the software tested by SIVAT is not the actual compiled operational code, but is rather an adapted version of the application code. It appears that the first time the actual operational code is tested is during the Factory Acceptance Test (FAT), and this test was developed by the design and test group, not the Verification and Validation (V&V)

Group.

The LAR states that SIVAT is a qualified tool for testing. NRC has not reviewed and approved SIVAT, and therefore does not understand why SIVAT is considered qualified.

Topical Report EMP-21 10, "TELEPERM XS: A Digital Reactor Protection System," and the staff SER on the topical report do not mention SIVAT. The validation tool which is mentioned in the TXS topical report is RETRANS (report section 2.4.3.3.3, Page 2-61).

The report states:

Draft "As a diverse measure to detect potential software faults not found by the means described in Section 3.2.1, the verification tool "RETRANS" developed by GRS-ISTec is used as an independent testing tool."

An additional issue which the staff does not understand is that on page 11 of the Areva Software V&V Plan, it states, "The test verifies that the requirements have been translated, without errors, into function diagrams, and that the software automatically generated from these function diagrams provides the functionality required in terms of I/O response." The staff does not understand how the proposed software testing using SIVAT can demonstrate that system requirements specification have been correctly translated into the code?

The staff believes that testing performed by unit and integration tests should be performed on the actual operational code, and therefore it may be necessary to perform additional software testing such as the following:

1.

Perform unit and integration test on the actual operation code instead of simulation. This would require developing test procedures, test results, and V&V reports on the test of actual operational code.

2.

Expand. the FAT to include testing that are normally done during unit and integration testing. This may include a) fault injection by deliberately passing bad information from one software unit to another, b) simulating hardware failures, c) communications errors, and d) diagnostic failures. This is only a short example of the types of testing the staff would expect to be added to FAT.

The licensee may choose to provide such additional information as needed for the staff to reach a conclusion that the SIVAT testing already planned will provide an equivalent confidence in a high quality test process, and therefore an equivalent confidence in the safety of the resultant system. One of the items required for this determination would be a determination that the SIVAT tool was qualified in a manner similar to that required for software performing safety-related functions, and that the software lifecycle process of the SIVAT tool development meet the requirements for that type of software.

Review Schedule Based on timely submittal of satisfactory responses to the items above, the staff has developed a review plan for the LAR in accordance with the following milestones:

1.

Duke provides information requested above TBD (Schedule by 4/1/08)

2.

Audit Trip to Areva/Framatome July 2008

3.

First RAI to Licensee July, 2008

4.

Receive response to first RAI September, 2008

5.

Second RAI to Licensee October, 2008

6.

Second Audit Trip to Areva/Framatome December 2008

7.

SER to DORL End June, 2009

Draft This review schedule is based on the acceptable resolution of the above identified six issues.