Regulatory Guide 1.173
| ML003740101 | |
| Person / Time | |
|---|---|
| Issue date: | 09/30/1997 |
| From: | Office of Nuclear Regulatory Research |
| To: | |
| References | |
| DG-1059 RG-1.173 | |
| Download: ML003740101 (8) | |
U.S. NUCLEAR REGULATORY
COMMISSION
REGULATORY
September
1997 GUIDE OFFICE OF NUCLEAR REGULATORY
RESEARCH REGULATORY
GUIDE 1.173 (Draft was DG- 1059) DEVELOPING
SOFTWARE UFE CYCLE PROCESSES
FOR DIGITAL COMPUTER SOFTWARE USED IN SAFETY SYSTEMS OF NUCLEAR POWER PLANTS A. INTRODUUTION
In 10 CFR Part 50, "Domestic Licensing of Pro duction and Utilization Facilities," paragraph
55a(a)(1)
requires, in part,1 that systems and components be designed, tested, and inspected to quality standards commensurate with the safety function to be per forme
d. Criterion
1, "Quality Standards and Records," of Appendix A, "General Design Criteria for-Nuclear Power Plants," to 10 CFR Part 50 requires, in part, 1 that a quality assurance program be established and imple mented in order to provide adequate assurance that sys tems and components important to safety will satisfac torily perform their safety functions.
Appendix B, "Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants," to 10 CFR Part 50 de scribes criteria that a quality assurance program for sys tems and components that prevent or mitigate the con sequences of postulated accidents must meet. In particular, besides the systems and components that directly prevent or mitigate the consequences of postu lated accidents, the criteria of Appendix B also apply to all activities affecting the safety-related functions of such systems and components as designing, purchas lIn this regulatory guide, many of the regulations have been paraphrased;
see 10 CFR Part 50 for the full text.ing, installing, testing, operating, maintaining, or mod ifying. A specific requirement is contained in 10 CFR 50.55a(h), which requires that reactor protection sys tems satisfy the criteria of IEEE Std 279-1971, "Crite ria for Protection Systems for Nuclear Power Generat ing Stations." 2 Paragraph
4.3 of IEEE Std 279-19713 states that quality of components is to be achieved through the specification of requirements known to promote high quality, such as requirements for design, inspection, and testing.
In Appendix B to 10 CFR Part 50, many of the cri teria contain requirements closely related to software life cycle activities.
Criterion I, "Organization," de scribes the establishment and execution of a quality as surance program. Criterion II, "Quality Assurance Pro gram," states, in part, that activities affecting quality must be accomplished under suitably controlled condi tions, which include assurance that all prerequisites for a given activity have been satisfied.
This criterion also 2 Revision I of Regulatory Guide 1.153, "Criteria for Safety Systems," en dorses IEEE Std 603-1991,"Criteria for Safety Systems for NuclearPow er Generating Stations," as a method acceptable to the NRC staff for satis fying the NRC's regulations with respect to the design, reliability, qualifi cation, and testability of the power, instrumentation, and control portions of the safety systems of nuclear power plants. 31EEE publications may be obtained from the IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 0885
4. USNRC REGULATORY
GUIDES The guides we issued In the following ton broad ivasions:
Regulatory Guides we Issued to describe and make available to the public such Informe tlion as methods acceptable to the NRC staff for Implementing specific parts of te Com- 1. Power Reactors 6. Products mission's regulations,r techiques used bythe st in evaluating specific problems or pos- 2. Research and Test Reactors 7. Transportation tuiated accidents, and data needed by the NRC staff In its review of applications for per- I Fuels and Materials Facilities
8. Occupational Health mits nd licenses.
Regulatory guides ae not substitutes for regulations.
and comp~lance
4 Environmetal and Siting 9. Antitrust and Financial Review with them Is not reqird. Methods and solutions different from those set outin teguides 5. Materasand Plant Protection
10. General will be acceptable If they provide a basis for the findings requisite to the issuance or con tInuence of a permit or license by the Commission.
Single copies of regulatory guldes may be obtained free of charge bywriting the Printing, Ths guide was issued after considerstion of comments received from the public. Corn- Graphics and Distribution Branch, Ofice of Admrinistiaon, U.S. Nuclear Regulatory Com mentsandsuggestions forlmprovements Intheseguides are encouraged atalltimes, and mission, Washington, OC 20555-0001;
or by tax at (301)415-5272.
will be revised, as appropriate, to accommodate comments and to reflect new In on or expeience.
Issued guides may also be purchased from the National Technical Information Service on Written correnants may be submitted to the Rules Review arnd Directives Branch. DFIPS, a steanding order basis. Details on this service may be obtained by wrlting NTIS. 5285 Poit ADM, U.S. Nuclear Regulatory Commission, Waeslington.
DC 20555-0001.
Royal Road, Springfield, VA 22161.
calls for taking into account the need for special con trols and processes to attain the required quality. Crite rion III, "Design Control," states, in part, that measures must be established for the identification and control of design interfaces and for coordination among partici pating design organizations.
Criterion XV, "Noncon forming Materials, Parts, or Components," requires measures to be established to control materials, parts, or components that do not conform to requirements in order to prevent their inadvertent use or installation.
Finally, Criteria VI, "Document Control," and XVII, "Quality Assurance Records," provide for the control of the issuance of documents, including changes there to, that prescribe all activities affecting quality and pro vide for the maintenance of sufficient records to furnish evidence of activities affecting quality.
This regulatory guide endorses IEEE Std 1074-1995, "IEEE Standard for Developing Software Life Cycle Processes," 3 subject to the exceptions stated in the Regulatory Position.
IEEE Std 1074-1995 de scribes a method acceptable to the NRC staff for com plying with parts of the NRC's regulations for promot ing high functional reliability and design quality in software used in safety systems.4 In particular, the method is consistent with the previously cited General Design Criteria and the criteria for quality assurance programs of Appendix B as they apply to software de velopment processes.
The criteria of Appendices A and B apply to systems and related quality assurance processes, and if those systems include software, the re quirements extend to the software elements.
In general, information provided by regulatory guides is reflected in the Standard Review Plan (NUREG-0800).
NRC's Office of Nuclear Reactor Regulation uses the. Standard Review Plan to review applications to construct and operate nuclear power plants. This regulatory guide will apply to the revised Chapter 7 of the Standard Review Plan. The information collections contained in this regu latory guide are covered by the requirements of 10 CFR Part 50, which were approved by the Office of Manage ment and Budget, approval number 3150-0011.
The NRC may not conduct or sponsor, and a person is not required to respond to, a collection of information un less it displays a currently valid OMB control number. 4 The term "safety systems" is synonymous with "safety-related systems." The General Design Criteria cover systems, structures, and components "important to safety." The scope of this regulatory guide is, however, lim ited to "safety systems," which are a subset of "systems important to safety."
B. DISCUSSION
The use of industry consensus standards is part of an overall approach to meeting the requirements of 10 CFR Part 50 when developing safety systems for nuclear power plants. Compliance with standards does not guarantee that regulatory requirements will be met. However, compliance does ensure that practices ac cepted within various technical communities will be in corporated into the development and quality assurance processes used to design safety systems. These prac tices are based on past experience and represent indus try consensus on approaches used for development of such systems.
Software incorporated into instrumentation and control systems covered by Appendix B will be referred to in this regulatory guide as safety system software.
The development of. software for high-integrity applications, such as safety system software, requires the use of a carefully planned and controlled develop ment process that incorporates the best available ap proaches to the various aspects of software engineer ing. There are a number of consensus standards that provide guidance on implementing currently accepted approaches to specific software engineering activities such as software requirements specification or software configuration management.
A carefully planned and controlled software development effort must incorpo rate these specific activities into an orderly process to be followed in the software life cycle, including pre software-development and post-software-development processes.
This regulatory guide addresses the subject of designing software life cycle processes appropriate for the development of safety system software.
IEEE Std 1074-1995 describes, in terms of inputs, development, verification or control processes, and outputs, a set of processes and constituent activities that are commonly accepted as composing a controlled and well-coordinated software-development process. It de scribes inter-relationships among activities by defining the source activities that produce the inputs and the des tination activities that receive the outputs. The standard specifies activities that must be performed and their inter-relationships;
it does not specify complete accep tance criteria for determining whether the activities themselves are properly designed.
Therefore, the stan dard should be used in conjunction with guidance from other appropriate regulatory guides, standards, and software engineering literature.
IEEE Std 1074-1995 can be used as a basis for developing specific software life cycle processes that are consistent with regulatory requirements, as applied to software, for controlling and coordinating the design of safety system software.1.173-2 K
Software development processes are intimately re lated to system development processes.
In the system design phase, system safety requirements are allocated
/2 to hardware, software, and human elements.
In the sys tem integration and testing phases, these elements are combined and tested. Consequently, a standard for soft ware development processes is intimately related to system-level standards, such as IEEE Std 7-4.3.2 1993, "Standard Criteria for Digital Computers in Safe ty Systems of Nuclear Power Generating Stations," which is endorsed by Revision 1 of Regulatory Guide 1.152, "Criteria for Digital Computers in Safety Sys tems of Nuclear Power Plants." IEEE Std 1074-1995 describes a complete set of software life cycle processes;
however, its system-level view is a generic view from a software perspective.
To employ IEEE Std 1074-1995 for developing safety system software, the system-level activities described in IEEE Std 1074-1995 must be addressed within the context pro vided by regulation and by nuclear industry standards.
Examples of system-level issues from this context are the need for software safety analyses as part of system safety evaluation and the need for determining the ac ceptability of pre-existing software for use in safety systems. Information on software safety activities and software life cycle activities in general can be found in Revision 1 of Regulatory Guide 1.152; NUREG/ CR-6101, "Software Reliability and Safety in Nuclear Reactor Protection Systems" 5 (November
1993); and NUREG/CR-6263, "High Integrity Software for Nu clear Power Plants: Candidate Guidelines, Technical Basis and Research Needs" 5 (June 1995). The second area, the acceptability of pre-existing software, is par ticularly important in the nuclear context. Guidance on this subject is in Revision 1 of Regulatory Guide 1.152. C. REGULATORY
POSITION The requirements contained in IEEE Std 1074-1995, "IEEE Standard for Developing Software Life Cycle Processes," 3 provide an approach accept able to the NRC staff for meeting the requirements of 10 CFR Part 50 and the guidance in Revision 1 of Regu latory Guide 1.152, "Criteria for Digital Computers in Safety Systems of Nuclear Power Plants," as they apply to development processes for safety system software, subject to the provisions listed belo
w. The appendices
5 Copies are available at current rates from the U.S. Government Printing Office, P.O. Box 37082, Washington, DC 20402-9328 (telephone
(202)512-2249);
or from the National Technical Information Service by writing NTIS at 5285 Port Royal Road, Springfield, VA 22161. Copies are available for inspection or copying for a fee from the NRC Public Docu ment Room at 2120 LStreet NW., Washington, DC; the PDR's mailing ad dress is Mail Stop LL-6, Washington, DC 20555-0001;
telephone
(202)634-3273;
fax (202)634-3343.
to IEEE Std 1074-1995 are not endorsed by this regula tory guide. To meet the requirements of 10 CFR 50.55a(h)
and Appendix A to 10 CFR Part 50 as ensured by comply ing with the criteria of Appendix B applied to the devel opment processes for safety system software, the fol lowing provisions are necessary and will be considered by the NRC staff in the review of applicant submittals. (In this Regulatory Position, the cited criteria are in Ap pendix B to 10 CFR Part 50 unless otherwise noted.)
1. CLARIFICATIONS
Because IEEE Std 1074-1995 was not written spe cifically for nuclear safety, the following clarifications apply to the standard.
1.1 Regulatory Requirements Identified Criterion III, "Design Control," requires measures to ensure that applicable regulatory requirements and the design basis for those structures, systems, and com ponents to which Appendix B applies are correctly translated into specifications, drawings, procedures, and instructions.
The descriptions of input information, life cycle activity, and output information that are re quired by IEEE Std 1074-1995 must identify applica ble regulatory requirements, design bases, and related guidance.
1.2 Consistency Various statements in the standard imply or state that life cycle activities should be consistent with bud get and schedule or that contingency actions may be taken to meet schedule or budget (paragraphs
3.2.3 and 3.2.4 of IEEE Std 1074-1995).
All such activities and contingency actions must be consistent with and justifi able with 10 CFR 50.57(a)(3), which requires that there be reasonable assurance that the activities authorized by the operating license can be conducted without en dangering the health and safety of the public. 1.3 Commercial Software Criterion III, "Design Control," states that measures are to be established for the selection and re view for suitability of application of materials, parts, equipment, and processes that are essential to the safe ty-related functions of the structures, systems, and components.
Criterion VII, "Control of Purchased Ma terial, Equipment, and Services," states that measures are to be established to ensure that purchased material, whether purchased directly or through contractors and subcontractors, conforms to the procurement docu ments. If pre-existing software (i.e., reusable software or commercial off-the-shelf software)
is incorporated into a safety system developed under the method de-1.173-3 scribed by this regulatory guide, an acceptance process must be included at an appropriate point in the life cycle model to establish the suitability of the pre-existing software for its intended use. The acceptance process, its inputs, outputs, activities, pre-conditions, and post conditions, must meet the applicable regulatory re quirements and design bases for the safety system. Re vision 1 of Regulatory Guide 1.152 provides information on the acceptance of pre-existing software.
Additional detailed information on acceptance processes is available in EPRI TR 106439, "Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications" (October 1996).6 1.4 Definitions The following definitions are used in this regulato ry guide. Accident An unplanned event or series of events that result in death, injury, illness, environmen tal damage, or damage to or loss of equip ment or property.
Hazard A condition that is a prerequisite to an accident.
2. COMPLIANCE
WITH IEEE Std 1074-1995 Criterion II, "Quality Assurance Program," requires all activities affecting quality to be accom plished under suitably controlled conditions.
Section 1.5.1, "Applicability," of IEEE Std 1074-1995 permits elimination of some life cycle activities, although com pliance with the standard may not then be claimed.
According to this regulatory guide, compliance with IEEE Std 1074-1995 means that all mandatory activi ties are performed, that the requirements described as 'shall' are met, and that all the inputs, outputs, activi ties, pre-conditions, and post-conditions mentioned by IEEE Std 1074-1995 are described or accounted for in the applicant's life cycle model. IEEE Std 1074-1995 is an organizing standard that ensures that activities deemed important to software quality are performed and related properly to each other; it does not provide detailed information regarding the implementation of specific life cycle activities.
6 Electric Power Research Institute documents may be obtained from the EPRI Distribution Center, 207 Coggins Drive, P.O. Box 23205, Pleasant Hill, CA 94523. EPRI TR 106439 is also available forinspection or copy. ing for a fee in the NRC Public Document Room at 2120 L Street NW., Washington, DC; the PDR's mailing address is Mail Stop LL-6, Washing ton, DC 20555-0001;
telephone
(202)634-3273;
fax (202)634-3343.
3. SOFTWARE SAFETY ANALYSES Criterion III, "Design Control," requires measures to ensure that applicable regulatory requirements and the design basis are correctly translated into specifica tions, drawings, procedures, and instructions.
To ensure that safety system software development is con sistent with the defined system safety analyses, addi tional activities beyond those specified in IEEE Std 1074-1995 are necessary.
Planned and documented software safety analysis activities should be conducted for each phase of the software development life cycle. Therefore, these analyses should be identified in the applicant's life cycle model, including the following inputs, activity description, and outputs.3.1 0 Input Information Regulatory requirements and guidance,"* Information reported for the system safety analysis, " Information from previous phases for the software safety analysis, " The design information from previous and current system and software phase activities.
3.2 Description The analyses must ensure that:
- System safety requirements have been correctly addressed,
- No new hazards have been introduced,
- Software elements that can affect safety are identified, "* There is evidence that other software elements do not affect safety, and "* Safety problems and resolutions identified in these analyses are documented.
These activities must be conducted according to a Software Safety Plan addressing the organization to perform the analyses, the responsibilities of its safety officer, the management of the software safety activi ties, and the analyses to be performed for each phase to address hazards and abnormal conditions and events. 3.3 Output Information Information for the current phase activities is re ported in the software safety analysis.
This information should be used for the design activities of the current life cycle phase, subsequent software safety analysis activities, the software configuration management process, and the verification and validation process.1.173-4 K
4. NEW OR MODIFIED SAFETY SYSTEM SOFTWARE Criterion XV, "Nonconforming Materials, Parts, or J' Components," requires measures to be established to control materials, parts, or components that do not con form to requirements in order to prevent their inadver tent use or installation.
The following clarifications should be made to IEEE Std 1074-1995 with respect to the installation and operation of new or modified safety system software.
4.1 Temporary "Work-Around" In its overview discussion of the "Installation Process," section 6.1.1 of IEEE Std 1074-1995 states: "If a problem arises, it must be identified and reported;
if necessary and possible, a temporary
'work-around'
may be applied." For the purposes of this regulatory guide, the term 'work-around'
is defined as follows.
A temporary change, to either the software or its configuration, that is made for the purpose of allowing the continuation of installation activi ties and testing of parts of the software that are unaffected by the temporary change. 4.2 Installation Installation of new or modified safety system soft ware may only be performed when all functions affected by the software have been declared inoperable according to the plant technical specifications.
When software is involved, particularly for distributed soft ware architectures, the determination of affected func tions can depend on extremely subtle considerations.
An example would be two programs related to each oth er only through use of a single data item, which might not be evident from the examination of architecture dia grams. As a minimum, all functions performed, in part, by a given software executable should be declared in operable if the software executable, its configuration, or its operating platform is to be altered; interconnec tions of all types with other software, hardware, or hu man elements should also be examined.
Any work arounds employed during installation must be accompanied by a disposition plan, rework procedures that conform to configuration control, verification and validation procedures agreed to under the licensing ba sis, and a resolution schedule.
Before affected func tions may be declared operable, the currently approved software, under the control of configuration manage>/ ment, must be installed according to the procedures specified in the installation process. This ensures that the intended software is installed and that any work-arounds employed during the installation activities are removed.
4.3 Operation Section 6.2.3, "Operate the System," of IEEE Std 1074-1995 requires the identification and reporting of anomalies as well as invocation of the verification and validation (V&V) process and the software configura tion management process. Section 6.3, "Maintenance Process," requires the software life cycle to be "re mapped and executed, thereby treating the Mainte nance Process as iterations of development." This process will produce revisions to software executables and configurations that may then be installed according to the installation process. Maintenance activities must conform to the configuration control and V&V proce dures agreed to under the licensing basis.
5. TAILORING
SOFTWARE Criterion V, "Instructions, Procedures, and Draw ings," requires that activities affecting quality be pre scribed by, and accomplished in accordance with, doc umented instructions, procedures, or drawings.
Section 6.1.5.2 of IEEE Std 1074-1995 permits cus tomer tailoring in the 'Install Software'
activity.
Any tailoring of packaged software or data in the data base at installation must be consistent with the packaged installation planned information of IEEE Std 1074-1995.
Criterion III, "Design Control," requires design changes to be subject to design control measures commensurate with those applied to the original de sign. Tailoring that constitutes design changes, includ ing configurations not part of the original system de sign, is not permitted unless such tailoring is subject to the full range of design and quality assurance measures applicable to the development of safety system software.
6. OTHER CODES AND STANDARDS
Various sections of IEEE Std 1074-1995 reference industry codes and standards.
These referenced stan dards should be treated individually.
If a referenced standard has been incorporated separately into the NRC's regulations, licensees and applicants must com ply with that standard as set forth in the regulation.
If the referenced standard has been endorsed in a regulatory guide, the standard constitutes a method ac ceptable to the NRC staff of meeting a regulatory re quirement as described in the regulatory guide. If a ref erenced standard has been neither incorporated into the NRC's regulations nor endorsed in a regulatory guide, licensees and applicants may consider and use the in formation in the referenced standard, if appropriately justified, consistent with current regulatory practice.1.173-5
D. IMPLEMENTATION
The purpose of this section is to provide informa tion to applicants and licensees regarding the NRC staff's plans for using this regulatory guide. No backfit ting is intended or approved in connection with the issuance of this proposed guide. Except in those cases in which an applicant pro poses an acceptable alternative method for complying with the specified portions of the NRC's regulations, the methods described in this guide will be used in the evaluation of submittals in connection with applica tions for construction permits and operating licenses.
This guide will also be used to evaluate submittals from operating reactor licensees that propose system modifi cations that are voluntarily initiated by the licensee if ihere is a clear nexus between the proposed modifica tions and this guidance.1.173-6 BIBLIOGRAPHY
Hecht, H., A.T. Tai, K.S. Tso, "Class 1E Digital Sys tems Studies," NUREG/CR-6113, USNRC, October 1993.1 Institute of Electrical and Electronics Engineers, "Stan dard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Stations," IEEE Std 7-4.3.2, 1993. Lawrence, J.D., "Software Reliability and Safety in Nuclear Reactor Protection Systems," NUREG/ CR-6101 (UCRL-ID-117524, Lawrence Livermore National Laboratory), USNRC, November 1993.1 lCopies may be purchased at current rates from the U.S. Government Prin ting Office, P.O. Box 37082, Washington, DC 20402-9328 (telephone
(202)512-2249);
or from the National Technical Information Service by writing NTIS at 5285 Port Royal Road, Springfield, VA22161. Copies are available for inspection or copying for a fee from the NRC Public Docu ment Room at 2120 LStreet NW., Washington, DC; the PDR's mailing ad dress is Mail Stop LL-6, Washington, DC 20555-0001;
telephone
(202)634-3273;
fax (202)634-3343.
Lawrence, J.D., and G.G. Preckshot, "Design Factors for Safety-Critical Software," NUREG/CR-6294, USNRC, December 1994.1 Seth, S., et al., "High Integrity Software for Nuclear Power Plants: Candidate Guidelines, Technical Basis and Research Needs," NUREG/CR-6263, USNRC, June 1995.1 USNRC, "Criteria for Digital Computers in Safety Systems of Nuclear Power Plants," Regulatory Guide 1.152, Revision 1, January 1996.2 USNRC, "Standard Review Plan," NUREG-0800, February 1984. 2 Single copies of regulatory guides may be obtained free of charge by writ ing the Printing, Graphics and Distribution Branch, Office of Administra tion, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001;
or by fax at (301)415-5272.
Copies are available for in spection or copying for a fee from the NRC Public Document Room at 2120 L Street NW, Washington, DC; the PDR's mailing address is Mail Stop LL-6, Washington, DC 20555-0001;
telephone
(202)634-3273;
fax (202)634-3343.
REGULATORY
ANALYSIS A separate regulatory analysis was not prepared for this regulatory guide. The regulatory analysis prepared for Draft Regulatory Guide DG-1059, "Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Sys tems of Nuclear Power Plants," provides the regulatory basis for this guide. Acopy 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)634-3343.
Federal Recycfng Program 1.173-7
-y UNITED STATES NUCLEAR REGULATORY
COMMISSION
WASHINGTON, DC 20555-0001 FIRST CLASS MAIL POSTAGE AND FEES PAID USNRC PERMIT NO. G-67 OFFICIAL BUSINESS PENALTY FOR PRIVATE USE, $300 C 0 co 0 C9 _z I_z ci C.) I11 z cc 09