ML20198F757
| ML20198F757 | |
| Person / Time | |
|---|---|
| Issue date: | 09/30/1997 |
| From: | NRC OFFICE OF NUCLEAR REGULATORY RESEARCH (RES) |
| To: | |
| References | |
| TASK-*****, TASK-RE REGGD-01.172, REGGD-1.172, NUDOCS 9801120146 | |
| Download: ML20198F757 (8) | |
Text
________
l U.S. NUCLEAR REGULATORY COMMISSION September 1997 (3 A *,
u glrueg)REGULATORY GUIDE
- ++ OFFICE OF NUCLEAR REGULATORY RESEARCH REGULATORY GUIDE 1.1*i2 (Draft was DG-1058)
SOFTWARE REQUIREMENTS SPECIFICATIONS FOR DIGITAL COMPUTER SOFTWARE USED IN SAFETY SYSTEMS OF NUCLEAR POWER PLANTS A. INTRODUCTION insv' ling, testing, operating, maintaining, or modify-ing. A specific requirement is contained in 10 CFR in 10 CFR Part 50, " Domestic Licensing of Pro- 50.55a(h), which requires that r. actor protection sys-duction and Utilization Facilities," paragraph 55a(a)(1) tems satisfy the criteria of IEEE Std 279-1971,"Crite-requires, in part,I hat t systems and components be de- ria for Protection Systems for Nuclear Powee Genua-signed, tested, and inspected to quality standards com- ting Stations."2 Paragraph 4.3 ofIEEE Std 2d-1971 3 mensurate with the safety function to be performed. states that quality of components is to be achieved Criterion 1," Quality Standards and Records," of Ap- through the specification of requirements known to pendix A," General Design Criteria for Nuclear Power pmmote high quality, such as requirements for design Plants," to 10 CFR Part 50 requires, in part,1 that inspection, and test.
appropriate records of the design and testing of systems O)
\
and components important to safety be maintained by or under control of the nuclear power unit licensee Several of the General Design Criteria (GDC) of Appendix A, including Criteria 12,13,19,20,22,23, throughout the life of the unit. Appendix B," Quality 24,25, and 28, describe functions that are part of the de Assurance Criteria for Nuclear Power Plants and Fuel sign bases of nuclear tmwer plants and that would be in-Reprocessing Plants," to 10 CFR Part 50 describes er , cluded in the software requirements specification teria that a quality assurance program for systems and (SRS) of any digital computer software that is part of components that prevent or mitigate the consequences basic components that perform thee functions. In addi-of postulated accidents must meet, in particular, tion to the criteria of Appendix A, Appendix B to besides the systems and components that directly pre- 10 CFR Part 50 provides quality assurance criteria that vent or mitigate the consequences of postulated acci- 2 Revision i or Regulatory cuide i.153,*Cniena for safety systems? en-dents, the criteria of Appendix B also apply to all activi- dorses ll:EE std 603-1991,* Criteria for safety Sys.er is for Nuclear Pow.
ties affecting the safety relaied functions of such , '* '8 "f,"*3, "'gC$*N"b"n* **Ir 'I'*desInIt t i a iNy,q'u"I$.
systems and components as designing, purchasing, canon, and ie tabihty of the power, instrumentation, and control no tions of the safety systems of nuclear power plants.
3 lin this regulatory guide, many of the regulations have been paraphrased, 1EEE publications may : ; obtained from the IEEE Service Center,445 see 10 Cl R Part 50 for the full text. Ilocs Lane, Piscataway, NJ 08854.
UNRC REOt1ATORY GUtDE5 The ges .ro maued e the Woe 9 ter1 Dro.d amone
= = = = = = = = = ,_ . - .
===== ===r.=== : === : :=_
==rm==== =r.= n=a ,: = - -
' = = = = = = - ~ - -
O v
is s g _r5L=; m g yd:
FrA M E R E E I ~*
- _ ._. _e_.__e_ s._
==:.::==== g=r==~- ~~~ c(,
si" M a g 97ovao
'*a eon .ll ll1lll[ ll]l1!7ij'
..a . . .. .
W-
design documcotation for nuclear reactor safety sys- processes used to design safety systems. These prac-tems must meet. Criterion 111. " Design Control," tices are based on past experience and represent indus-requires measures for design documentation and identi- try consensus on approaches used for development of fication and control of design interfaces, as well as such systems, measures for verifying or checking the adequacy of the design. Software incorporated into instrumentation and his regulatory guide endorses IEEE Std c ntrolsystems covered by Appendix Bwillbe referred 83G-1993,"lEEE Recommended Practice for Software to in this regulatory guide as safety system software.
Requirements Specifications,"3 with the exceptions The software requirements specification is an essential stated in the Regulatory Position. IEEE Std 830-1993 p rt of the record of the design of safety system soft-describes a .netnod acceptable to the NRC staff for ware. Associated with system requirements allocated complying with the NRC's regulations for echieving t s ftware subsystems, software requirements serve as high functiona' reliability and design quality in soft- the design bases for the software to be developed.
ware used in safety systems.4 in particular, the method Therefore, software requirements specifications are a is consistent with GDC 1 and the criteria for quality as- crucial design input to the remainder of the software surance programs in Appendix B as they apply to the development process. Software requirements specifi-development of software requirements specifications. c tions should exhibit charactenstics, such as correct-The criteria of Appendices A and B apply to systems ness and completeness, that will facilitate the imple-and related quality assurance processes, and if those mentation of a carefully planned ed controlled systems include software, the requirements extend to software development process.
the software elements.
One consensus standard on software engineering, in general, information provided by regulatory IEEE Std 830-1993, describes current practice for writ-guides is reflected in the Standard Review Plan ing software requirements specifications for a wide (NUREG-0800), which is use . by the Office of Nu- variety of systems. It is not specifically aimed at safety clear Reactor Regulation in the review of applications applications; however, it does provide guidance on the to construct and operate nuclear power plants. This reg- development of software requirements specifications ulatory guide will apph to the revised Chapter 7 of that that will exhibit characteristics important for develop-document-ing safety system software. This is consistent with the The information colic ctions contained in this regu- NRC staff's goals of ensuring high-integrity software latory guide are covered by the requirements of 10 CFR in reactor safety systems.
Part 50, which were approved by the Office of Manage-ment and Budget, apprmal number 3150-0011. The Other standards mention software requirements NRC may not conduct or sponsor, and a person is not specifications but do not provide detailed guidance for required to respond to, a collection of information un- writing them. IEEE Std 7-4.3.2-1993, " Standard Cri-less it displays a currently valid OMB control number, teria for Digital Computers in Safety Systems of Nu-clear Power Generating Stations,"3 which is endorsed 11, DISCUSSION by Revision 1 of Regulatory Guide 1.152," Criteria for Digital Computers in Safety Systems of Nuclear Power The use of industry consensus standards is part of Plants," mentions unambiguous software requirements an overall approach to meeting the requirements of as a prerequisite for high quality software develop-10 CFR Part 50 when developing safety systems for ment. IEEE Std 1012-1986, "lEEE Standard for Soft-nuclear power plants. Compliance with standards does ware Verification and Validation Plans,"3 mentions un-not guarantee that regulatory requirements will be met. ambiguous software requirements as a prerequisite for llowever, compliance does ensure that practices ac- verification and validation. IEEE Std 1074-1991, cepted within various technic 6 communities will be in. "lEEE Standard for Developing Software Life Cycle corporated into the development and quality assurance Processes,"3 describes software requirements specifi-cations as an essential input at the beginning of a soft-ware development life cycle. Correct, complete, well-written and unambiguous software requirements are
+rwe ierm uren syueme n synonymous *nh sareiy-reinied systemt. eneW bps m h main Mgn and venah pm.
The ceneui peugn cniera cover sysiems, situciures. ina components cesses that are accepted as necessary to produce high.
- impodant to ufey ? The scopc oi this regulatory guide is, however. hm-nied to " safety systems /' which are a subset of " systems importani to integrity software products (see NUREG/CR-6101, ureiy - " Software Reliability and Safety in Nuclear Reactor
/
1.172 - 2
l' Protection Systems"(November 1993),5 and NUREO/ 2. SOITWARE REQUIREMENTS CR-6263,"Iligh Integrity Software for Nuclear Power SPECIFICATIONS
/' Plants: Can(YJate Guidelines, Technical Basis and Re- Section 4.3 of IEEE fad 830-1993 defines a set of Q] - search Needc (June 1995)5]. characteristics of a good software requirements specifi-cation (SRS). The first sentence of this section should C. REGUIATORY POSITION be modified to read "An SRS must be.. ." The follow-ing clarifications and additional informatian should be The recommended practices in IEEE Std provided for this set of characteristics for safety system 830-1993 provide an approach that is acceptable to the software.
NRC staff for meeting the requirements of 10 CFR Part 50 as they apply to the preparation of software require- 2.1 Traceability and Accuracy ments specifications for safety system software, sub- When specification or representation tools are used ject to the exceptions listed below, for requirements, as described in sections 4.3.2.2 and 4.3.2.3 of IEEE Std 830-1993, traceability should be To meet the requirements of 10 CFR 50.55a(h) and maintained between these representations and the natu-Appendix A to 10 CFR Part 50 as assured by complying with the criteria of Appendix B applied to the verifica. ral language desenptions of the software requirements tion, validation, reviews, and audits of soft'vare used in that are derived from system requirements and system or affecting basic components of nuclear power plants, safety analyses.
the following exceptions are necessary and will be cori- 2.2 Completeness sidered by the NRC staff in the review of submittals F r safe'y system software, the description of func-from applicants and licensees. (in this Regulatory Posi-ti n I requirements should specify how functions are tion,the cited criteria are in Appendix Aor B of 10 CFR initiated and terminated as well as the system status at Part 50 unless otherwise noted.) termination. Accuracy requirements, including units, I. DEFINITIONS error bounds, data type, and data size, should be pro-vided for each input and output variable. Variables con-Section 3 of IEEE Std 830-1993 refers to 1EEE trolled or monitored in the physical environment Std 610.12-1990, "lEEE Standard Glossary of Soft-should be fully described. Functions exprcssly prohib-D ware Engineering Terminology,"3 for definitions of ited should also be described.
technical terms. These definitions are acceptable with the following clarifications or additions. Timing information is particularly important in specifying software requirements for safety system 1.1 llaseline software. Functions with timing constraints should be Meaning l of baseline in lEEE Std 610.12-1990 is identified and criteria for each mode of operation to be used in IEEE Std 830-1993. Formal review and should be provided. Timing requirements should be de-agreement S taken to mean that responsible manage- terministic and specified for both 1.ormal and antici- ;
ment has reviewed and approved a baseline, pated failure conditions.
1.2 Interface 2.3 Consistency All four variations of meaning in IEEE IEEE Std 830-1993 restricts the term to mean in-610.12-1990 are to be used in IEEE Std 830-1993, de- ternal consistency, noting that an external pending on the context. Meaning 1,"A shared bound- inconsistency is actually an incorrect specification of a ary across which information is passed," is interpreted requirement. The term is used in this regulatory guide broadly according to Criterion til to include design in- to mean both interna.1 and external consistency. Exter-terfaces between participating design organizations, nal consistency implies that the SRS is consistent with associated software products and system products, such as safety system requirements and design. Internal consistency means that no requirement in the require-
-- ments specification conflicts with any other require-5 Copies are available ai curreni rates from the U.s. covemmeni Priniing ment in the specification.
Othe, P.O. Hos 37082, Washington. DC 2N02-9328 (telephone
]) (202)512-2249); or from the National Techical information service by writing NTis at 5285 Port Royal Road. sprmgrield. VA 22161. Copics are 2.4 Ranking for Importance or Stabil~ty 3
sv avadable for inspection or copy mg for a fee trom the NRC Public oocu- For safety system software, this characteristic ment Rc.>m at 2120 L street Nw., washmgton. DC; the PDR's mailmg ad.
dress h Mad stop 1.L-6. Washington, DC 20535-0001; telephone means that software requirements important to safety (202pw32n raq202M34-3343. must be identified as such in the SRS. Criterion 20 of 1.172 - 3
Appendix A,amongothers, describes the functions that under a general software cor' figuration management reactor protection systems must perform. Section program as a configuration iteat.
4.3.5.2 of IEEE Std 830-1993 suggests three degrees of necessity of requirement: essential, conditional, and 4. INCOMPLETE SRS ENTRY optional. As used in IEEE Std 830-1993, the terrus Any entry in an SRS that is incompL'e (uses conditional and optional refer to requirements that are "TBD"), as described by section 4.3.3.1 of IEEE Std not necessary for the software to be acceptable. For 830-1993, must describe the applicable design bases safety system software, unnecessary requirements and commitments to standards or regulations that gov-should not be imposed.There may be documented vari, ern the final determinatioa of the requirement entry, ations in essential requirements, but the variations must
- 5. DESIGN-SPECIFIC ISSUES be linked in the software requirements specifications either to site and equipment variations or to specific Section 4.7 of IEEE Std 830-1993 recommends plant design bases and regulatmy provisions. that design-specific issues such as module partition-ing, function allocation, and information flow be 3.5 Verifiability omitted from SRSs. Section 4.7.1 of IEEE Std 830-1993 states some exceptions to this policy,includ-IEEE Std 830-1993 recommends the removal or ing reasons of security or safety. When specific design revi ion of unverifia% requirements. This is clarified techniques or features such as independence, separa-to mean that all requirements should be verifiable and tion, diversity, and defense-in-depth are required by the should be mcdified or restated as necessary so that it is safety system design bases or by regulation, these are possible to verify each one, an appropriate part of an SRS and they abould be de-2.6 Modifiability
. 6. SOFTWARE A'ITRillUTES This term ts closely related to the style (form, struc-ture, and modularity), readability, and understandabil- S"ction 5.3.6 of IEEE Std 830-1993 lists software ity of the SRS. With respect to these characteristics, it is attributes that car serve as requirements. Attributes of important that precise definitions of technical terms be particular interesi for safety system software are safety, available, either in the SRS or in a glossary. security, and reliability or robustness.
6.1 Safety 2.7 Traceab!!ity .
Software requirements important to safety aie de-Section 4.3.8 of IEEE Std 830-1993 describes two rived from system requirements and safety analyses types of traceability, and both types are required. Each and should be identified as such in the SRS. These re-identifiable requirement in an SRS must be traceable quirements should include considerations based on the backwards to the system requirements and the design safety analysis report (S AR) as well as abnormal condi-bases or regulatory requirements that it satisfies. Each tions and events (ACES) as described in IEEE Std identifiable requirement should be written so that it is 7-4.3.2-1993, as endarsed by Revision 1 of Regula-also " forward traceable" to subsequent design outputs, tory Guide 1.152.
e.g., from SRS to software design and from software design to SRS. 6.2 Security Security threats to the computer system should be Forward traceability to all documents spawned by .
identified and classified according to impact on safety the SRS includes verification and validation materials.
nd likelihood of occurrence. Actions required of the Far example, a forward trace c.hould exist from each re-quirement in the SRS to the specific inspections, analy- s hware to detect, prnent; or mitigate such security threats should be specified, including access control m-ses, or tests used to confirm that the requirement has stricti as. For mstance, modification of instrument cal.
been met' ibration data might be protected by a password system.
- 3. CilANGE CONTROL IN SRSs 6.3 Robustness Section 4.5(b) of IEEE Std 830-1993 recomrnends Software requirements for fault tolerance and fail-that SRSs be baselined and subject to a formal process ure modes, derived either from consideration of system for control of changes. The SRS must be subject to con- level hazards analyses or from consideration of soft-trol of changes. Although this could be met directly by ware internals, should be specified for each operating a change control procedure unique to IEEE Std 830- mode. Software behavior in the presence of unex-1993, it may also be accomplished by taking the SRS pected, incorrect, anomalous, and improper input, 1.172 - 4 i I
l
l hardware behavior, or software behavior should be the NRC's regulations, licensees and applicants must fully specified. Software requirements for responding cor fy with that standard as set forth in the regulation.
If th..cferenced standard has been endorsed in a regula-
[] to both hardware and software failures should be pro-Q vided, including requirements for analysis of and re- tory guide, the standard constitutes a method accept-covery from computer system failures. Requirements able to the NRC staff of meeting a regulatory require-for on line in service testing and diagnostics should be ment as described in the regula'ory guide. 'f a .
specified. referenced standar.1 has been neither incorporated into the NRC's regulations nor endorsed in a regulatory
- 7. NONAPPLICABILITY guide, licensees and applicants may consider and use Because of its generality, IEEE Std 830-1993 dis- the information in the referenced standard,if appropri-cusses or recom,nends a number of content items that ately justified, consistent with current regulatory may be inappropriate to real time, embedded safety practice.
systems. lleadings for such inappropriate subjects in an D. IMPt.EMENTATION SRS that is compliant with IEEE Std 830-1993 should be listed, followed by "Not applicable." For example, a The purpose of this section is to provide informa-graphical user interface may be inappropriate for a real- tion to applicants and licensees regarding the NRC time, embedded reactor trip system. staff's plans for using this regulatory guide. No backfit-ting is intended or approved in connection with the
- 8. APPLICABILITY OF ANNEX A issuance of this proposed guide.
Annex A to IEEE Std 830 1993 is not endorsed by Except in those cases in which an applicant pro-this regul,. tory guide and may be taken only as exam- poses an acceptable alternative method for complying ples. Directions to use an outhne from Annex A, such with the specified portions of the NRC's regulations, as those directions found in section 5.3.7 of IEEE Std the methods described in this guide will be used in the 830-1993, may be take:: as advisory only, evaluation of submittals in connection with applica.
tions for construction permits and operating licenses.
- 9. OTilER CODES AND STANDARDS This guide will also be used to evaluate submittals from Various tections in IEEE Std 830-1993 reference operatir:g reactor licensees that propose system modifi-(' cations voluntarily initiated by the licensee if there is a several industry codes and standards. These referenced standards should be considered individually. If a refer- clear connection between the proposed modifications enced standard has been incorporated separately 'nto and this guidance.
N
[d 1.172 - 5
IllllLIOGRAPilY llecht, II., A.T. Tai, K.S. Tso, " Class IE Digital Sys- Lawrence, J.D., and G.G. Preckshot, " Design Factors tems Studies," NUREG/CR-6113, USNRC, October for Safety-Critical Software," NUREG/CR-6294, 1993.1 USNRC, December 1994.1 Institute of Elect-ical and Electronics Engineers,"Stan- Seth, S., et al., "lligh Integrity Software for Nuclear dard Criteria for Digital Computers in Safetv Systems Power Plants: Candidate Guidelines, Technical Basis of Nuclear Power Generating Stations," IEEE Std and Research Needs," NUREG/CR-6263, USNRC, 7-4.3.2, 1993. June 1995.1 Lawrence, J.D., " Software Reliability and Safety in USNRC, " Criteria for Digital Computers in Safety Nuclear Reactor Protection Systems," NUREG/ Systems of Nuclear Power Plants," Regulatory Guide CR-6101 (UCRI.-ID-117524, Lawrence Livermore 1.152, Revision 1, January 1996.2 National 1 aboratory), USNRC, November 1993.1 USNRC, " Standard Review Plan," NUREG-0800, February 1984.
I 25ngle copics of regulatory guides may be obtained free of charge by w tit-Copics may be purchased at current rates from the U.S. Government Pnn-ting Oflice. PO. Ilos 37082, W. shit ston DC 20402-9328 (telephone ing the Office of Administration. Pnnting, Graphics and f'istnbution (202)512-2249); of from the National Techripcal Information Service by Hranch, U.S. Nuclear Regulatory Commission, Wa hington. DC
- riting NTis at 5285 Port Roy al Road. Spnngfield. VA 22161. Copics are 2055541001; or by fas at (301%I5-5272. Copics are avsilable for in-available for inspection or copying for a fee from the NRC Public rkw u- spection or copying for a fee from the NRC Public Document Room at me nt Room at 2120 L Street NW., Washington. DC; the PDR's mailing ad- 2120 L Street NW, Washington. DC; the PDR's mailing addres is Mail dress is Mail Stop 11-6. Washington. DC 20555 41001; telephonc Stop 11-6, Was hington, DC 20555-0001; telephone (202)634-32'3, fas (202)634-3273; fa s (202)634-3343. (202)634-3343.
O O
1.172 - 6 l
1
REGULATORY ANALYSIS A separate regulatory analysis was act prepared for this regulatory guide.The
\ regulatory analysis prepared for Draft Regulatory Guide DG-1058," Software Re-quiremems Specifications for Digital Computer Software Used in Safety Systems of Nuclear Power Plants," provides the regulatory basis for this guide, A copy of the regulatory analysis is available for inspection and copying for a fee at the NRC Public Document Room,2120 L Street NW., Washington, DC; the PDR's mailing address is Mail Stop LL-6, Washington, DC 20555-0001; phone (202)634-3273; fax (202)6'+4-3343.
f Printed on recycled paper
(
\
Federal Recyclu1g Program 1.172 - 7
l; l1 l\
N
- U C
P WL E A A O
E S N
A HR L
T I R U N
R OUT LE P
f
T E
U
- 2 Y T 0CE S 5
,E 5O S 5 5M 0
3 0
0 0M I 0
1 S S
I O
N W
O i
P O
S F P
E R
Tm A
Gs M U Er TS Ac I
N N Nu O
G 47 R Ds
. CFs E
EM Su P t O
A I
D 06 0e .!E 8 ." ,. O
- a
- 8,
- l: l) ,1 -
\