ML20216J261
| ML20216J261 | |
| Person / Time | |
|---|---|
| Issue date: | 09/30/1999 |
| From: | Kalyanam N NRC (Affiliation Not Assigned) |
| To: | Mallay J SIEMENS POWER CORP. (FORMERLY SIEMENS NUCLEAR POWER |
| References | |
| PROJECT-702 TAC-MA1983, NUDOCS 9910040267 | |
| Download: ML20216J261 (12) | |
Text
September 30, 1999 i
_ Mr James F.- Mallay Director, Nuclear Regulatory Affairs Siemens Power Corporation
~ 2101 Horn Rapids Road Richland, WA 99352
SUBJECT:
REQUEST FOR ADDITIONAL INFORMATION ON SIEMENS TOPICAL REPORT, EMF-2110, REVISION 1, "TELEPERM XS: A DIGITAL REACTOR PROTECTION SYSTEM"(TAC NO. MA1983)
Dear Mr. Mallay:
By letter dated September 1,1999, the Siemens Power Corporation (SPC) submitted Revision 1 to Topical Report EMF-2110 (NP), "TELEPERM XS: A Digital Reactor Protection System" for staff review. On September 9,1999, the staff proposed that Siemens use a staff generic digital Safety Evaluation (SE) outline to identify pertinent sections of the topical report that address
' information expected in sections of the outline and to the extent possible provide specific narrative that describes the information required to support conclusions of the SE. Areas not in the scope of the topical report should be clearly identified as plant specific. The staff's generic
' digital SE outline is enclosed.
1 In addition, please provide a detailed diversity design comparison between TELEPERM XS (safety protection system) and TELEPERM XP (non-safety control system) to demonstrate the total diversity between the two systems.
The enclosed request was discussed with your staff on September 23,1999. A mutually agreeable target date of within 30 days of the date of this letter for your response was established. If circumstances result in the need to revise the target date, please call me at the earliest opportunity at 301-415-1480.
Sincerely, original signed by:
N. Kalyanam, Project Manager, Section 2
' Project Directorate IV & Decommissioning g-Q Q f % h F D ~~
Division of Licensing Project Management Office of Nuclear Reactor Regulation i
Project No. 702 DISTRIBUTION:
4 '
Central File '
Enclosure:
Digital SE Outline.
PUBLIC PDIV-2 Reading f/[/#
n.4r m ;
9910040267 990930 SRichards '
PDR TOPRP EMVEKXN
-HLi (9-D-11)
-C PDR p
1o receive a copy of mis document, indicate v in the box a
OFFICE PDIV-2/PM -
,C PDIV-2/LA C
PDIV-2/SC NAME NKalyanam M EPeyton W SDembek /N DATE 9l b 199 9 /&Cl/99 9 / 3 0/99 DOCUMENT NAME: G;\\PDIV-2\\Siemens\\MA1983._RAI ON EMF-2110 Revision 1.wpd L
OFFICIAL RECORD COPY l
(M 7o 2.
Yvyd f%J70 2--
p cen g
4 UNITED STATES s
j NUCLEAR REGULATORY COMMISSION 2
WASHINGTON, D.C. 20066 4001
\\.....,o8 September 30, 1999 Mr. James F. Mallay Director, Nuclear Regulatory Affairs Siemens Power Corporation 2101 Horn Rapids Road Richland, WA 99352
SUBJECT:
REQUEST FOR ADDITIONAL INFORMATION ON SIEMENS TOPICAL REPORT, EMF-2110, REVISION 1,"TELEPERM XS: A DIGITAL REACTOR PROTECTION SYSTEM" (TAC NO. MA1983)
Dear Mr. Mallay:
By letter dated September 1,1999, the Siemens Power Corporation (SPC) submitted Revision 1 to Topical Report EMF-2110 (NP), "TELEPERM XS: A Digital Reactor Protection System" for staff review. On September 9,1999, the staff proposed that Siemens use a staff generic digital Safety Evaluation (SE) outline to identify pertinent sections of the topical report that address information expected in sections of the outline and to the extent possible provide specific narrative that describes the information required to support conclusions of the SE. Areas not in the scope of the topical report should be clearly identified as plant specific. The staff's generic digital SE outline is enclosed.
In addition, please provide a detailed diversity design comparison between TELEPERM XS (safety protection system) and TELEPERM XP (non-safety control system) to demonstrate the total diversity between the two systems.
The enclosed request was discussed with your staff on September 23,1999. A mutually agreeable target date of within 30 days of the date of this letter for your response was established if circumstances result in the need to revise the target date, please call me at the earliest opportunity at 301-415-1480.
Sincerely, N. Kalyanam, Project Manager, Section 2 Project Directorate IV & Decommissioning Division of Licensing Project Management Office of Nuclear Reactor Regulation Project No. 702
Enclosure:
Digital SE Outline
r GENERIC DIGITAL SE OUTLINE This outline is a suggestion only, and is based upon previous SEs. This is by no means the only way a SE can be 0,ganized, and in some instances, may not make sense for any particular subject. The information contained within is, however, a good indication of the type of information which should be covered for a reasonably complex digital upgrade to an I&C system.
1 INTRODUCTION - General description of plant modifications. Description of what the modification is intended to do. Mention plant and vendor, major submittals with dates, and the schedule for the modification.
2 SYSTEM DESCRIPTION (this portion may be many pages long. The organization may be different from that listed below, but in general, all major portions of the system must be discussed) 2.0.1 System specification 2.0.2 Processor subsystem 2.0.3 Input / Output subsystem 2.0.4 Test subsystem 2.0.5 Other subsystems as needed 2.1 Hardware Description 2.1.1 Physical description - discuss cabinets used, I/O cabling, interconnect wiring, and their generallayout.
2.1.2 System architecture 2.1.3 Environmental qualifications 2.1.3.1 Temperature and humidity l
2.1.3.2 Seismic qualification l
2.1.3.3 Radiation l
2.1.3.4 EMilRFI 2.1.3.5 Power quality requirements 2.1.4 iso!ation and interaction between 1E and Non-1E (this is a statement of what is required-analysis will come later-The protection system shall be designed to
\\
ensure that the effects of normal operating and postulated accident conditions do l
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 CFR Part 50, Appendix A, GDC 22 and 24).
Enclosure
i 1
j i
2-t 2.2 Software I
l.
2.2.1' Software description l
2.2.1.1 1E software description l
2.2.1.2 1/O software description l
- 2.2.1.3 Communications software description l
2.2.1.4 Test and diagnostic software description 2.2.1.5 Such other software as may be present 2.2.2 Software documentation (briefly discuss existence of documents, date and l
author, and which standard was used in development - In-depth review will come later) l-2.2.2.1 Vendor / customer system specification 2.2.2.2 Software management plan l-2.2.2.3 Software development plan 2.2.2.4 Software quality assurance plan 2.2.2.5 Software configuration management plan 2.2.2.6 Hardware and software specification i
2.2.2.7 Software requirements specification (SRS) l l
2.2.2.8 Software requirements review (SRR) 2.2.2.9 Software design description (SDD) 2.2.2.10 Software design review (SDR) l 2.2.2.11 Source code listing 2.2.2.12 Source code review i
2.2.2.13 Safety analyses l
2.2.2.14 Software verification and validation plan (SWP) 2.2.2.15 Verification and validation report i
2.2.2.16 User instruction manual j
2.2.3 Development and V&V organization and process - Describe briefly-evaluation will come later.
2.2.4 Configuration management - Brief 3
Technical Review - Discuss the review methodology and the standards or requirement used. A faidy complete list of standards and references is listed at the end of this i
outline, but as these are continually being updated, check on the revision level and date l
Ofissue.
3.1 Hardware 3.1.1 System architecture and system specification. Signal paths for normal and emergency operation (trip conditions) c
. 3.1.2 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.
3.1.3 Environmental Qualifications IEEE Std 323-1974/1983. The environmental qualification includes temperature, humidity, electromagnetic compatibility (EMC), and radiation. Forplant 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.
3.1.3.1 Temperature and humidity 3.1.3.2 Seismic qualification - IEEE Std 344-1987.
3.1.3.3 Radiation 3.1.3.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.)
3.1.3.5 Power and grounding 3.1.4 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 CFR Part 50, Appendix A, GDC 22 and 24). This may be covered in depth here, orin the section on IEEE 603.
3.2 Software (The key to this review is the V&V plans and procedures. As there aro no physicalitems to inspect, most of this reviewis of documentation and specification. All l
of this should have already been done and documented by the V&V group, therefore a l
review of those evaluations, if done correctly and documented adequately, may be all that is required). In general:
(1) following the code development, (2) reviewing software problemlerror reports and resulting corrections, (3) comparing the V&V process to IEEE Std 7-4.3.2-1982, l
(4) interviewing personnel involved in the software desiga and V&V l
processes, i
(5) verifying the independence of the software verifiers (6) reviewing the development of the functional requirements and subsequent software development documents, (7) reviewing software life-cycle and future vendor / licensee interface for configuration management, and (8) reviewing the V&V results.
3.2.1 Software documentation (This may not all be present, and several documants may be combined, but the check is that the information required in each document is contained somewhere).
I, o
1
\\
f 4
3.2.1.1 Software requirements specification (SRS), (Reg Guide 1.172, IEEE Std 830-1984, "lEEE Guide for Software Requirements Specifications" 3.2.1.2 A software requirements review 3.2.1.3 A software design description (SDD) 3.2.1.4 A software design review (SDR) on the SDD to verify that it satisfies the SRS requirements 3.2.1.5 The source code 3.2.1.6 The source code (Review to verify that the source code correctly, consistently, completely and accurately incorporates the requirements from the SDD.).
3.2.1.7 A 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.
3.2.1.8 A software verification and validation plan (SWP), which describes the verification and validation methods used (e.g.,
inspection, analysis, or test).
3.2.1.9 Verification and validation report, providing the results of the verification reviews, inspections, tests, and analyses, and the validation test.
3.2.1.10 External reviews and audits 3.2.1.11 The user instruction manual, containing instructions, including prerequisites and precautions, for the installation, checkout and operation.
3.2.2 Verification and validation - discuss the V&V process, and development team.
There should be an evaluation on the adequacy of:
3.2.2.1 The degree of independence of the V&V team and process (see RG 1.162).
3.2.2.2 Development of the SWP 3.2.2.3 Test plans for all system components 3.2.2.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 tho development process.
3.2.2.5 The development of a tracking matrix (to 60 used to map the requirements through the software development phases (this is to assure that all requirements are traceable to the end product).
3.2.2.6 Discrepancy reporting and corrective action - All discrepancies identified during the software development, verification, validairon or audit activities were documented on a discrepancy report, and tracked until corrected by the development organization. A log of the repods 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 I
j l
5-satisfactorily passed the test. The V&V Report contains a listing of all discrepancy reports including their disposition.
3.2.3 Thread audit - This consists of picking a sample of plant parameters and tracing the software implementation of these parameters from the original (purchase) specification and development of the functional requirements to the writing and testing of the code. This review included reviewing actual sections of the code on a sample basis, examining the various levels of software development documents and comparing them to the code, examining problem reports and verifying the corrections, examining the engineering cross-discipline interfaces to ensure that nuclear specific needs were correctly incorporatedinto the code, examining the licensee interface to ensure plant specific requirements were correctly incorporated, ensuring that the venfication and validation process was followed according to the vendor's plan, and reviewing the finalresults of the process.
3.2.4 Configuration management - List the software and documentation associated with the software development. Includedin the discussion should be:
method for change control of development and V&V documentation version control of pre-released source code; version control historical recording and archiving of released verified source code modules; historical recording and archiving of verified and validated absolute code control of firmware manufactunng a
how and where the software under configuration management is stored access to the software the software librarian, who 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), and (3) compilers, linkers, and libraries used in the creation of the absolute code.
3.3 System Level 3.3.1 Review of IEEE 603 requirement (depending on plant, this may be IEEE 279 requirements) 3.3.1.1 Section 4.1 identification of the design basis events BTP HICB-4, BTP HICB-5 3.3.1.2 Section 4.4 identification of variables monitored 3.3.1.3 Section 4.5 minimum criteria for manual initiation and control of protective actions BTP HICB-6
. I 3.3.1.4 Section 4.6 identification of the minimum number and location of sensors 3.3.1.5 Section 4.4 identification of the analyticallimit associated with each variable.
3.3.1.6 Section 4.7 range of transient and steady-state conditions 3.3.1.7 Section 4.8 identification of conditions having the potential for causing functional degradation of safety system performance 3.3.1.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, 3.3.1.9 Section 5.1 single-failure criterion 3.3.1.10 Section 5.2 completion of protective action 3.3.1.11 Section 5.3 quality 3.3.1.12 Section 5.4 equipment qualification 3.3.1.13 Section 5.5 system integrity 3.3.1.14 Section 5.6 independence physicat independence.
4 electricalindependence.
communications independence.
3.3.1.15 Section 5.7 capability for test and calibration 3.3.1.16 Section 5.8 information displays 3.3.1.17 Section 5.9 control of access 3.3.1.18 Section 5.10 repair 3.3.1.19 Section 5.11 identification 3.3.1.20 Section 5.12 auxiliary features 3.3.1.21 Section 5.13 multi-unit stations 3.3.1.22 Section 5.14 human factors considerations 3.3.1.23 Section 5.15 reliability 3.3.1.24 Sections 6,1 and 7.1 automatic control 3.3.1.25 Sections 6.2 and 7.2 manual control 3.3.1.26 Section 6.3 interaction between the sense and command features and other systems 3.3.1.27 Section 7.3 completion of protective action 3.3.1.28 Section 6.4 derivation of system inputs 3.3.1.29 Section 6.5 capability for testing and calibration 3.3.1.30 Sections 6.6 and 7.4 operating bypasses 3.3.1.31 Sections 6.7 and 7.5 maintenance bypass 3.3.1.32 Section 6.8 setpoints 3.3.1.33 Section 8 power source requirements 3.3.2 Software and hardware system review, looking for potentiai timing and software / hardware problems.
3.3.3 Such other review as may be required.
h,
, 4 Approval (if everything in the above checks out, this should just be a statement that:
" Based on the above, the staff concludes that the reviewed system is acceptable for use in safety-related reactor systems. (Sbje:t to satisfactory licensee compliance with the following prerequisites. // any) The staff, i
therefore, concludes that the STAR system meets the requirements of 10 CFR Part 50, General Design Criteria 2,4,20,21,22,23, and 24, and IEEE Std 603(what is referenced here will vary) for design of safety-related (reactor protection systems or engineered safety feature systems) and the guidelines of Regulatory Guide 1.152 and supporting industry standards for design of digital systems, and is therefore acceptable. If this is a generic, non-plant review, then state something like " Referencing licensees must, however, address the i
above prerequisites to ensure compliance with theirplant specific licensing
\\
bases.'
References:
The following is a comparatively complete list of references. Since references and new guidance is being written and modified, it is suggested you check to see if the version you are using is the latest, or the one used by the utility or vendor when the system was built. Not all of these references will be applicable to any particular SER.
10 CFR Part 50, Appendix A, GDC 2 10 CFR Part 50, Appendix A, GDC 4 10 CFR Part 50, Appendix A, GDC 17 10 CFR Part 50, Appendix A, GDC 19 10 CFR Part 50, Appendix A, GDC 20 10 CFR Part 50, Appendix A. GDC 21 10 CFR Part 50, Appendix A, GDC 22 10 CFR Part 50, Appendix A, GDC 23 10 CFR Part 50, Appendix A, GDC 24 10 CFR Part 50, Appendix A, GDC 25 10 CFR Part 50, Appendix B Generic Letter 88-20," Individual Plant Examination for Severe Accident Vulnerabilities."
Generic Letter 83-28," Required Actions Based on Generic implications of Salem ATWS Event."
Generic Letter 89-02," Actions to improve the Detection of Counterfeit and Fraudulently Marketed Products,"
Generic Letter 91-05. " Licensee Commercial-Grade Procurement and Dedication Programs."
Generic Letter 95-02,"Use of NUMARC/EPRI Report TR-102348, ' Guideline on Licensing Digital Upgrades',in Determining the Acceptability of Performing Analog-to-Digital Replacements under 10 CFR 50.59."
Information Notice 83-83,"Use of Portable Radio Transmitters Inside Nuclear Power Plants."
NUREG-0493,"A Defense-in-Depth and Diversity Assessment of the RESAR-414 Integrated Protection System."
t
- NUREG-0700, Rev.1," Human-System Interface Design Review Guideline."
NUREG-0711," Human Factors Engineering Program Review Model."
NUREG-0800," Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants," Chapter 13.2, Training, and Chapter 13.5, Plant Procedures.
NUREG-0800, " Standard Review Plan for the Review of Safety Analysis Reports for Nuclear l'
Power Plants," Chapter 18, Human Factors Engineering.
NUREG-0800," Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants," Chapter 7, Instrumentation and Controls.
NUREG CR-3270, " Investigation of Electro-magnetic Interference (EMI) Levels in Commercial Nuclear Power Plants."
NUREG CR-4640," Handbook of Software Quality Assurance Techniques Applicable to the Nuclear industry."
NUREG CR-6303," Method for Performing Defense-in-Depth and Diversity Analyses of the Reactor Protection System."
l Regulatory Guide 1.22," Periodic Testing System Actuation Functions."
I Regulatory Guide 1.47," Bypassed and Inoperable Status Indication for Nuclear Power Plants."
Regulatory Guide 1.53, " Application of the Single Failure Criterion to Nuclear Power Plant Systems."
q Regulatory Guide 1.75, " Physical Independence of Electrical Systems."
j Regulatory Guide 1.97, " Instrumentation for Light-Water Cooled Nuclear Power Plants To Assess Plant and Environs Conditions During and Following an Accident."
Regulatory Guide 1.118," Periodic Testing of Electric Power and Protection Systems."
l Regulatory Guide 1.152, Revision 1, " Criteria for Digital Computers in Safety Systems of i
Nuclear Power Plants."
Regulatory Guide 1.153, Revision 1, " Criteria for Power, Instrumentation, and Control Portions of Safety Systems."
Regulatory Guide 1.168, " Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants."
Regulatory Guide 1.169, " Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants."
Regulatory Guide 1.170, " Software Test Documentation for Digital Computer Software Used in l
Safety Systems of Nuclear Power Plants."
I Regulatory Guide 1.171, " Software Unit Testir.g for Digital Computer Software Used in Safety Systems of Nuclear Power. Plants."
g Regulatory Guide 1.172," Software Requirements Specifications for Digital Computer Software j
Used in Safety Systems of Nuclear Power Plants."
Regulatory Guide 1.173," Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants."
i Safety Evaluation by the Office of Nuclear Reactor Regulation, "EPRI Topical Report TR-106439," May 1997.
I i
1 l
l l
'1
k n
.g-l SECY-91-292, " Digital Computer Systems for Advanced Light-Water Reactors," September I
1991.
SECY-93-087, " Policy, Technical, and Licensing issues Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs," April 2,1993.
Staff Requirements Memorandum on SECY-93-087," Policy. Technical, and Licensing issues Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs," July 15,1993.
ANSI /IEEE-ANS-7-4.3.2-1993," Application Criteria for Programmable Digital Computer Systems in Safety Systems of Nuclear Power Generating Stations."
ANSI /IEEE Std. 279-1971," Criteria for Protection Systems for Nuclear Power Generating Stations."
ANSI /IEEE Std. 603-1991,"lEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations, institute of Electrical and Electronic Engineers."
l ANSI /IEEE Std. 1012-1986, "lEEE Standard for Software Verification and Validation Plans."
IEEE Std. 323-1974,."lEEE Standard for Qualifying Class 1E Equipment for Nuclear Power j
Generating Stations."
IEEE Std. 338-1977, "lEEE Standard Criteria for Periodic Testing of Nuclear Power Generating Station Safety Systems."
IEEE Std. 344-1975,"lEEE Recommended Practices for Seismic Qualification of Class 1E Equipment for Nuclear Power Generating Stations."
IEEE Std. 379-1977," Application of the Single Failure Criterion to Nuclear Power Generating Station Class 1E Systems."
IEEE Std. 384-1977," Criteria for !ndependence of Class 1E Equipment and Circuits."
IEEE M1472-1974, " Guide for Surge Withstand Capability Tests."
lEEE Std. 610.12-1990,"lEEE Standard Glossary of Software Engineering Terminology."
IEEE Std. 934-1987, " Requirements for Replacement Parts for Class 1E Equipment in Nuclear Power Generating Stations."
lEEE Std.1050-1989,"lEEE Guide for Instrumentation and Control Equipment Grounding in Generating Stations."
IEEE Std. 518-1982, " Guide for the Installation of Electrical Equipment to Minimize Electrical Noise inputs to Controllers from External Sources."
lEEE Std. 730-1989," Software Quality Assurance Plans."
lEEE Std. 828-1983, " Software Configuration Management Plans."
IEEE Std. 829-1983," Software Test Documentation."
IEEE Std. 830-1984, " Guide to Software Requirements Specifications."
IEEE Std. 1016-1987," Recommended Practice For Software Design Descriptions."
lEEE Std. 1028-1988," Standard For Software Reviews And Audits."
IEEE Std. 1074-1995," Standard For Developing Software Life Cycle Processes."
lEEE Std. 1228-1991," Standard For Software Safety Plans."
l IEC Std. 880, Supplement 1 Draft, " Software for Computers in the Safety Systems of Nuclear l
Power Stations," IEC Publication, October 1996.
ASME Std. NOA-1-1994," Quality Assurance Requirements for Nuclear Facility Applications."
ASME Std. NOA-2a-1990, Part 2.7," Quality Assurance Requirements of Computer Systems for Nuclear Facility Applications, American Society of Mechanical Engineers."
t
b a l EPRI Topical Report TR-102323, " Guide to Electromagnetic interference (EMI) Susceptibility Testing for Digital Safety Equipment in Nuclear Power Plants."
EPRI Topical Report TR-106439," Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Sa'ety Applications," Electric Power Research Institute, October 1996.
EPRI NP-5652, " Guideline for the Uti'ization of Commercial Grade items in Nuclear Safety Related Applications," Final Report, Electric Power Research Institute, June 1988.
MIL-STD-462," Electro-magnetic Interference Characteristics Measurement."
MIL-STD-461(A,B,C), " Electro-magnetic Emission and Susceptibility Requirements for the Control of Electro-magnetic Interference."
MIL-STD-1399, " Interface Standard for Shipboard Systems, DC Magnetic Field Environments."
NRC Inspection Manual, Chapter 52001, " Digital Retrofits Receiving o ior Approval."
r i
SAMA PMC 33.1-1978, " Electro-magnetic Susceptibility of Process Control Instrumentations."
j i
1 1
1 i