ML022730151
| ML022730151 | |
| Person / Time | |
|---|---|
| Site: | Ginna  |
| Issue date: | 10/08/2002 |
| From: | Clark R NRC/NRR/DLPM/LPD1 |
| To: | NRC/NRR/DLPM/LPD1 |
| Clark R, NRR/DLPM, 415-2297 | |
| References | |
| TAC MB1887 | |
| Download: ML022730151 (11) | |
Text
October 8, 2002 FACILITY: R. E. Ginna Nuclear Power Plant LICENSEE: Rochester Gas and Electric Corporation
SUBJECT:
SUMMARY
OF MEETING HELD ON SEPTEMBER 24, 2002, WITH ROCHESTER GAS AND ELECTRIC CORPORATION RE: PROPOSED DIGITAL UPGRADES TO THE EMERGENCY CONTROL ROOM AIR TREATMENT SYSTEM ACTUATION INSTRUMENTATION (TAC NO. MB1887)
On September 24, 2002, representatives of the Rochester Gas and Electric Corporation (RG&E or licensee) and their contractors met with the members of the Nuclear Regulatory Commission (NRC) staff in Rockville, Maryland. The purpose of the meeting was to discuss RG&Es proposed response to the Request for Additional Information (RAI) dated August 28, 2002 (ADAMS Accession No. ML022120249). This RAI was related to RG&Es license amendment request to upgrade the Emergency Control Room Air Treatment System Actuation Instrumentation using digital equipment. Meeting slides were used to address each RAI question for the purpose of gaining NRC staff feedback on the level of detail required, and to provide a schedule for the submittal. A list of attendees is given in Enclosure 1, a copy of the handouts provided by RG&E is given in Enclosure 2, and a copy of the handout provided by the NRC staff summarizing the level of detail required to complete the design review is given in .
/RA/
Robert Clark, Project Manager, Section 1 Project Directorate I Division of Licensing Project Management Office of Nuclear Reactor Regulation Docket No. 50-244
Enclosures:
As stated cc w/encls: See next page
ML022120249). This RAI was related to RG&Es license amendment request to upgrade the Emergency Control Room Air Treatment System Actuation Instrumentation using digital equipment. Meeting slides were used to address each RAI question for the purpose of gaining NRC staff feedback on the level of detail required, and to provide a schedule for the submittal. A list of attendees is given in Enclosure 1, a copy of the handouts provided by RG&E is given in Enclosure 2, and a copy of the handout provided by the NRC staff summarizing the level of detail required to complete the design review is given in .
/RA/
Robert Clark, Project Manager, Section 1 Project Directorate I Division of Licensing Project Management Office of Nuclear Reactor Regulation Docket No. 50-244
Enclosures:
As stated cc w/encls: See next page DISTRIBUTION PUBLIC PDI-1 Rdg File S. Little R. Clark E. Marinos M. Reinhart S. Richards J. Zwolinski R. Laufer M. Hart P. Loeser TBergman OGC B. Platchek, RI ACRS/ACNW Accession No.: ML022730151 OFFICE PDI-1/PM PDI-1/LA EEIB/SC PDI-1/SC NAME RClark SLittle EMarinos RLaufer DATE 10/02/02 10-2-02 10/3/02 10/3/02 R.E. Ginna Nuclear Power Plant cc:
Kenneth Kolaczyk, Sr. Resident Inspector Mr. Paul Eddy R.E. Ginna Plant New York State Department of U.S. Nuclear Regulatory Commission Public Service 1503 Lake Road 3 Empire State Plaza, 10th Floor Ontario, NY 14519 Albany, NY 12223 Regional Administrator, Region I U.S. Nuclear Regulatory Commission 475 Allendale Road King of Prussia, PA 19406 Mr. William M. Flynn, President New York State Energy, Research, and Development Authority 17 Columbia Circle Albany, NY 12203-6399 Charles Donaldson, Esquire Assistant Attorney General New York Department of Law 120 Broadway New York, NY 10271 Daniel F. Stenger Ballard Spahr Andrews & Ingersoll, LLP 601 13th Street, N.W., Suite 1000 South Washington, DC 20005 Ms. Thelma Wideman, Director Wayne County Emergency Management Office Wayne County Emergency Operations Center 7336 Route 31 Lyons, NY 14489 Ms. Mary Louise Meisenzahl Administrator, Monroe County Office of Emergency Preparedness 1190 Scottsville Road, Suite 200 Rochester, NY 14624
MEETING BETWEEN NRC AND ROCHESTER GAS AND ELECTRIC CORPORATION ATTENDANCE LIST September 24, 2002 NRC RG&E INDUSTRY R. Laufer, NRR M. Flaherty A. Lasko, Syncor E. Marinos, NRR J. Pacher J. Ellis, Plexar Associates P. Loeser, NRR P. Swift R. Clark, NRR T. Quinn M. Hart, NRR S. Athavale, NRR Enclosure 1
NRC SAMPLE DOCUMENTS Enclosure 3
This is a example of the documents I expect to see, and that I will review. Licensees and vendors often combine two or more of these into one document, and therefore not all of these would necessarily be separate documents. I would expect the information normally contained within each document to be covered somewhere within the submittals.
- 1. SYSTEM DESCRIPTION
- i. System Specification ii. Processor subsystem iii. Input/Output Subsystem iv. Test Subsystem
- v. Other Subsystems as needed
- a. Hardware Description
- i. System architecture and system specification. Signal paths for normal and emergency operation (trip conditions) ii. Hardware quality - Discuss level of quality and commercial dedication of components or boards. If commercial hardware is used, look at the history, including failure rate.
iii. Environmental Qualifications IEEE Std 323-1974/1983. The environmental qualification includes temperature, humidity, electromagnetic compatibility (EMC), and radiation. For plant specific reviews, the qualifications must bound worst case plant conditions for all accidents and transients where the digital system is required to mitigate or trip. Discuss test methodology.
(1) Temperature and Humidity (2) Seismic Qualification - IEEE Std 344-1987.
(3) Radiation (4) EMI, RFI (EPRI Report TR-102323 "Guide to Electromagnetic Interference (EMI) Susceptibility Testing for Digital Safety Equipment in Nuclear Power Plants," may be used in lieu of testing provided that adequate similarity can be established between the proposed installation and the tested installations.)
(5) Power and grounding iv. Isolation and Interaction Between 1E and Non-1E - The protection system must be designed to ensure that the effects of normal operating and postulated accident conditions do not result in the loss of the protective function and that a failure of a control system does not adversely effect the protection system.(10 C.F.R. Part 50, Appendix A, GDC 22 and 24). This may be covered in depth here, or in the section on IEEE 603.
- v. Physical description - discuss cabinets used, I/O cabling, interconnect wiring, and their general layout.
(1) Power Quality requirements
- b. Software. The intent of the review is to be able to do the following:
- following the code development,
- reviewing software problem/error reports and resulting corrections,
- comparing the V&V process to IEEE Std 7-4.3.2-1982,
- interviewing personnel involved in the software design and V&V processes,
- verifying the independence of the software verifiers
- reviewing the development of the functional requirements and subsequent software development documents,
- reviewing software life-cycle and future vendor/licensee interface for configuration management, and
- reviewing the V&V results.
- i. Software Description Start with a description of the overall software, including the operating system (if any), subsystems such as runtime modules or safety kernels, and any other software included in the system.
(1) 1E Software Description (2) I/O Software Description (3) Communications Software Description (4) Test and diagnostic Software Description (5) Such other software as may be present ii. Software Documentation (Make sure these include the date, author and revision level.)
(1) Vendor / Customer System Specification (2) Software Management plan (3) Software Development plan (RG 1.173 & IEEE 1074)
(4) Software Quality Assurance Plan (5) Software Configuration Management Plan (RG 1.169 & IEEE 828)
(6) Hardware and Software Specification (7) Software Requirements Specification (SRS) (RG 1.172 & IEEE 830)
(8) Software Requirements Review (SRR)
(9) Software Design Description (SDD)
(10) Software Design Review (SDR)
(11) Source Code Listing (12) Source Code Review (13) Safety analyses of the SRS, SDD, source code and system test reports which verified that requirements, features and procedures required for the protection functions of the software have been adequately specified, implemented and tested.
(14) Software Test Plan (RG 1.170 & IEEE 829)
(15) User Instruction Manual (16) External Reviews and Audits (17) The User Instruction Manual, containing instructions, including prerequisites and precautions, for the installation, checkout and operation iii. Development and V&V Organization and Process - Describe briefly -
evaluation will come later iv. Verification and Validation - discuss the V&V process, and development team. There should be an evaluation on the adequacy of:
(1) The degree of independence of the V&V team and process see RG 1.162.
(2) Software Verification and Validation Plan (SVVP) (RG 1.168, IEEE 1012)
(3) test plans for all system components (4) tests as part of the V&V process, including static and dynamic testing, as well as standard testing methodologies such as unit, integration, regression, and final acceptance testing occurred throughout the development process.
(5) the development of a tracking matrix,(to be used to map the requirements through the software development phases (this is to assure that all requirements are traceable to the end product.
(6) Discrepancy Reporting and Corrective Action - All discrepancies identified during the software development, verification, validation or audit activities were documented on a discrepancy report, and tracked until corrected by the development organization. A log of the reports should be kept and their status was tracked by the V&V group. The developer of the software had the responsibility to resolve these reports and if a code modification was required, the verifier performed regression testing until the module satisfactorily passed the test. The V&V Report contains a listing of all discrepancy reports including their disposition.
(7) Verification and Validation Report, providing the results of the verification reviews, inspections, tests, and analyses, and the validation test.
- v. Configuration Management Plan, showing the following:
C Method for change control of development and V&V documentation C version control of pre-released source code; version control C historical recording and archiving of released verified source code modules; historical recording and archiving of verified and validated absolute code C control of firmware manufacturing.
C How and where the software under configuration management is stored.
C Access to the software C The software librarian, who should not also be a developer of the software.
Software which was placed into library storage should include:
(1) released source code for each version.revision, (2) verified and validated absolute code (including release notes containing pertinent compiling, linking and loading procedures, and checksum or CRC), and (3) compilers, linkers, and libraries used in the creation of the absolute code.
- c. System level
(1) Section 4.1 identification of the design basis events BTP HICB-4, BTP HICB-5 (2) Section 4.4 identification of variables monitored (3) Section 4.5 minimum criteria for manual initiation and control of protective actions BTP HICB-6 (4) Section 4.6 identification of the minimum number and location of sensors (5) Section 4.4 identification of the analytical limit associated with each variable.
(6) Section 4.7 range of transient and steady-state conditions (7) Section 4.8 identification of conditions having the potential for causing functional degradation of safety system performance (8) Section 4.9 identification of the methods used to determine reliability of the safety system design IEEE Std 603 and IEEE Std 7-4.3.2, (9) Section 5.1 Single-Failure Criterion (10) Section 5.2 Completion of Protective Action (11) Section 5.3 Quality (12) Section 5.4 Equipment Qualification (13) Section 5.5 System Integrity (14) Section 5.6 Independence
- Physical independence.
- Electrical independence.
- Communications independence.
(15) Section 5.7 Capability for Test and Calibration (16) Section 5.8 Information Displays (17) Section 5.9 Control of Access (18) Section 5.10 Repair (19) Section 5.11 Identification (20) Section 5.12 Auxiliary Features (21) Section 5.13 Multi-Unit Stations (22) Section 5.14 Human Factors Considerations (23) Section 5.15 Reliability (24) Sections 6.1 and 7.1 Automatic Control (25) Sections 6.2 and 7.2 Manual Control (26) Section 6.3 Interaction Between the Sense and Command Features and Other Systems (27) Section 7.3 Completion of Protective Action (28) Section 6.4 Derivation of System Inputs (29) Section 6.5 Capability for Testing and Calibration (30) Sections 6.6 and 7.4 Operating Bypasses (31) Sections 6.7 and 7.5 Maintenance Bypass (32) Section 6.8 Setpoints (33) Section 8 Power Source Requirements ii. Software and hardware system review, looking for potential timing and software / hardware problems.
iii. Human / Machine interface and other human factors considerations. Include changes to control room displays, new administrative control requirements, and changes to technicians and operators procedures iv. Response time characteristics and testing requirements. This should include a discussion of the microprocessor cycle times, sampling rates, and testing procedures.
- v. Post accident monitoring provisions and changes.
vi. Technical Specification changes which may be required.
vii. Modifications of Setpoints values, if required. A review of Setpoints procedures may be required if the methodology is being modified or is not already approved.
viii. Training - This covers not only training for the operators and maintenance personnel, but should also cover training for anyone performing surveillance on the equipment, or performing repairs.
If all repair to failed boards and software modifications are being handled by the vendor, this may be shorter than otherwise required.
ix. Repair and maintenance of components, PC boards and software.
What provisions have been made for repair? Who will modify software if errors are discovered? If the licensee is expecting to do their own repairs, do they have sufficient information on the equipment, i.e., detailed drawings and parts lists for the boards and annotated code listing for the software? If the vendor is planning to do repair and maintenance, what will happen if the vendor goes out of business?
- x. Such other review as may be required.