ML032270204
| ML032270204 | |
| Person / Time | |
|---|---|
| Site: | University of California-Davis |
| Issue date: | 08/19/2003 |
| From: | Alexander Adams NRC/NRR/DRIP/RORP |
| To: | Richards W McClellan Nuclear Research Center |
| Adams A, NRC/N RR/DRIP/RNRP, 415-1127 | |
| References | |
| Download: ML032270204 (4) | |
Text
August 19, 2003 Dr. Wade J. Richards, Chair ANS 15 Subcommittee on Operation of Research Reactors UCD/MNRC 5335 Price Avenue Building 258 McClellan, CA 95652
SUBJECT:
ANS-15.16 and ANS-15.20, ANS-15 COMMITTEE BALLOTS
Dear Dr. Richards:
Enclosed is my ballot for ANS-15.16, American National Standard for Emergency Planning for Research Reactors, and ANS-15.20, Control and Safety Systems for Research Reactors. I have voted "approved with comments" for both standards. Furthermore, I have reviewed the Scope of the standards, and have no objections.
If you have any questions concerning these ballots, please contact me at 301-415-1127.
Sincerely,
/RA/
Alexander Adams, Jr., Senior Project Manager Research and Test Reactors Section New, Research and Test Reactors Program (RNRP)
Division of Regulatory Improvement Programs Office of Nuclear Reactor Regulation cc: Please see next page
August 19, 2003 Dr. Wade J. Richards, Chair ANS 15 Subcommittee on Operation of Research Reactors UCD/MNRC 5335 Price Avenue Building 258 McClellan, CA 95652
SUBJECT:
ANS-15.16 and ANS-15.20, ANS-15 COMMITTEE BALLOTS
Dear Dr. Richards:
Enclosed is my ballot for ANS-15.16, American National Standard for Emergency Planning for Research Reactors, and ANS-15.20, Control and Safety Systems for Research Reactors. I have voted "approved with comments" for both standards. Furthermore, I have reviewed the Scope of the standards, and have no objections.
If you have any questions concerning these ballots, please contact me at 301-415-1127.
Sincerely,
/RA/
Alexander Adams, Jr., Senior Project Manager Research and Test Reactors Section New, Research and Test Reactors Program (RNRP)
Division of Regulatory Improvement Programs Office of Nuclear Reactor Regulation cc: Please see next page DISTRIBUTION:
PUBLIC RNRT\\R&TR r/f PDoyle WEresian PIsaac TDragoun MMendonca AAdams OGC EHylton JLyons PMadden FGillespie SHolmes CBassett DMatthews ADAMS ACCESSION NO.: ML032270204 TEMPLATE #: NRR-106 OFFICE RNRP:LA RNRP:PM RNRP:SC NAME EHylton:rdr AAdams PMadden DATE 08/ 15 /03 08/ 18 /03 08/ 19 /03 C = COVER E = COVER & ENCLOSURE N = NO COPY OFFICIAL RECORD COPY
NRC COMMENTS ON ANS-15.16 EMERGENCY PLANNING FOR RESEARCH REACTORS 1.
Section 3.3(3): Please clarify the intent for the deletion. Without further explanation, this section should not be deleted. It may be advisable to relocate it out of Section 3.3, Organization and Responsibilities. Perhaps it should become a Section of its own, 3.11 under the title, Arrangements and Agreements, or a Subsection under 3.10, Maintaining Emergency Preparedness, 3.10.4, Arrangements and Agreements.
Where and how it is maintained is not critical as long as it is maintained.
2.
Table 1, Notice of Unusual Event, Action level column: The word severe is misspelled.
3.
Table 2, Acceptable EPZ size for greater than 2 MW... : Replace 1OO meters with 100 meters.
4.
Table 1, Alert: There is a ***, but it is not found in the footnotes.
5.
Section 3.4.2: Replace {1) with (1).
6.
The second page of the Foreword describes the contents of this revision, but it implies that the guidance and criteria are new in this revision. However, it appears that the actual changes to the standard are not substantial.
NRC COMMENTS ON ANS-15.20 CONTROL AND SAFETY SYSTEMS FOR RESEARCH REACTORS 1.
Question-Section 3-safety interlock. Is this definition in addition to or a replacement of the definition in the Appendix B of 15.21?
2.
Suggestion-Section 3-control interlock. An interlock which, on failure, could allow a reactor condition to exceed a limiting condition for operation (LCO) but would not allow the occurrence of an event leading to a reactor LSSS being exceeded.
3.
Question-Section 3. At what level is an interlock that is intended to prevent a potential unplanned exposure to a radiation worker or a member of the public?
4.
Question-Section 3. The definition of reactor safety system (RSS) includes those systems that....provide information for initiation of manual protective action, yet the standard appears to be silent on the topic of standards for monitoring and display systems that may be the basis for operator action or inaction. Is it appropriate not to specifically address in the standard those systems that only monitor and display operational parameters? Or by this definition do the monitor and display only systems become part of the reactor safety system? (See also 5.2 (12)- Include systems the operator may use as a basis for initiating or not initiating manual protective actions.)
5.
Suggestion-Section 4.2 (4). It is important that as much as possible the RCS shall be designed such that unanticipated as well as anticipated malfunctions or consequences from unanticipated operator action will not result in significant failures.
6.
Question-Section 5.2 (8). The RSS shall provide simple and direct means for the reactor operator to initiate manual protective action. What is implied, if anything, by the use of manual? Is this a hardwired system? If not, what redundancy requirements shall be imposed?
7.
Section 5.2 (12). See question above concerning the definition of a RSS.
8.
Statement-Section 9.2 Software Development. In this section, in each instance, replace should with shall.
9.
Statement-Section 9.3 Verification and Validation. When referring to the RSS in this section, in each instance, replace should with shall.
10.
Statement-Section 9.3 (1) Address the level of independence required for the reviewers.
11.
Statement-Section 10 Autonomous Operation. The shall criteria in this section apply to non-autonomous operation if the RSS and RCS must function faster than the operator response time to prevent a significant failure. By strict definition the system is autonomous during the typical reaction time interval of an operator.
12.
General Suggestion. There are some digital issues that should be addressed in the standard such as aliasing, display lockup, software and hardware crashes, and system response times.