ML003739146

Draft Regulatory Guide DG-1056 Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants,

ML003739146
Person / Time
Issue date:	08/31/1996
From:	Office of Nuclear Regulatory Research
To:
References
DG-1056
Download: ML003739146 (19)

Text

U.S. NUCLEAR REGULATORY COMMISSION August 1996 0 OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 Draft DG-1056 DRAFT REGULATORY GUIDE

Contact:

J. Kramer (301)415-5891 DRAFT REGULATORY GUIDE DG-1056 SOFTWARE TEST DOCUMENTATION FOR DIGITAL COMPUTER SOFTWARE USED IN SAFETY SYSTEMS OF NUCLEAR POWER PLANTS A. INTRODUCTION In 10 CFR Part 50, "Domestic Licensing of Production and Utilization Facilities," paragraph 55a(a)(1) requires, in part, that systems and components be designed, tested, and inspected to quality standards commensurate with the safety function to be performed.' Criterion 1, "Quality Standards and Records,"

of Appendix A, "General Design Criteria for Nuclear Power Plants," to 10 CFR Part 50 requires, in part, that a quality assurance program be established and implemented in order to provide adequate assurance that systems and components important to safety will satisfactorily perform their safety functions.'

Appendix B, "Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants," to 10 CFR Part 50 describes criteria that must be met by a quality assurance program for systems and components that prevent or mitigate the consequences of postulated accidents. In particular, besides the systems and components that directly prevent or mitigate the consequences of postulated accidents, the criteria of Appendix B also apply to all activities affecting the safety-related functions of such systems and components, such as designing, IIn this draft regulatory guide, many of the regulations have been paraphrased; see 10 CFR Part 50 for the full text.

This regulatory guide is being issued in draft form to involve the public in the early stages of the development of a regulatory position in this area. It has not received complete staff review and does not represent an official NRC staff position.

Public comments are being solicited on the draft guide (including any implementation schedule) and its associated regulatory analysis or value/impact statement. Comments should be accompanied by appropriate supporting data. Written comments may be submitted to the Rules Review and Directives Branch, DFIPS, Office of Administration, U.S. Nuclear Regulatory Commission, Washington, DC 20555. Copies of comments received may be examined at the NRC Public Document Room, 2120 L Street NW., Washington, DC. Comments will be most helpful ifreceivedby October 31, 1996.

Requests for single copies of draft or final guides (which may be reproduced) should be made in writing to the U.S. Nuclear Regulatory Commission, Washington, DC 20555, Attention: Office of Administration, Distribution and Mail Services Section, or faxed to (301)415-2260.

Requests for placement on an automatic distribution list for single copies of future draft guides in specific divisions should be made to the same address.

purchasing, installing, testing, operating, maintaining, or modifying. A specific requirement is contained in 10 CFR 50.55a(h), which requires that reactor protection systems satisfy the criteria of IEEE Std 279-1971, "Criteria for Protection Systems for Nuclear Power Generating 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 test.

Many of the criteria in Appendix B to 10 CFR Part 50 contain requirements closely related to the activities of verification and testing. I Criterion I, "Organization," requires the establishment and execution of a quality assurance program. Criterion II, "Quality Assurance Program," requires the quality assurance program to take into account the need for verification of quality by inspections and tests. Criterion III, "Design Control," requires, in part, that measures be established for verifying and checking the adequacy of design, such as by the performance of a suitable testing program, and that design control measures be applied to items such as the delineation of acceptance criteria for inspections and tests. Criterion V, "Instructions, Procedures, and Drawings,"

requires activities affecting quality to be prescribed by documented instructions, procedures, or drawings of a type appropriate to the circumstances and that these activities be accomplished in accordance with these instructions, procedures, or drawings. Criterion V further requires that instructions, procedures, and drawings include appropriate quantitative or qualitative acceptance criteria for determining that important activities have been satisfactorily accomplished. Criterion XI, "Test Control," requires establishment of a test program to ensure that all testing required to demonstrate that structures, systems, and components will perform satisfactorily in service is identified and performed in accordance with written test procedures that incorporate the requirements and acceptance limits contained in applicable design documents. Test procedures must include provisions for ensuring that all prerequisites for the given test have been met, that adequate test instrumentation is available and used, and that the test is performed under suitable environmental conditions. Criterion XI also requires that test results 2Revision 1 of Regulatory Guide 1.153, "Criteria for Safety Systems," endorses IEEE Std 603-1991, "Criteria for Safety Systems for Nuclear Power Generating Stations," as a method acceptable to the NRC staff for satisfying the NRC's regulations with respect to the design, reliability, qualification, and testability of the power, instrumentation, and control portions of the safety systems of nuclear power plants.

3 IEEE publications may be obtained from the IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854.

2

be documented and evaluated to ensure that test requirements have been satisfied.

Finally, Criteria VI, "Document Control," and XVII, "Quality Assurance Records,"

provide for the control of the issuance of documents, including changes thereto, that prescribe all activities affecting quality and provide for the maintenance of sufficient records to furnish evidence of activities affecting quality.

The latter requires test records to identify the inspector or data recorder, the type of observation, the results, the acceptability of the results, and the action taken in connection with any deficiencies noted.

This draft regulatory guide, which endorses ANSI/IEEE Std 829-1983, "IEEE Standard for Software Test Documentation,, with the provisions stated in the Regulatory Position, describes a method acceptable to the NRC staff for complying with parts of the NRC's regulations for achieving 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 the documentation of software testing activities. The criteria of Appendices A and B apply to systems and related quality assurance processes, and if those systems include software, the requirements extend to the software elements.

In general, information provided by regulatory guides is reflected in the Standard Review Plan (NUREG-0800, "Standard Review Plan for the Review of Safety Analysis Reports for Nuclear Power Plants," currently under revision),

which is used by the Office of Nuclear Reactor Regulation in the review of applications to construct and operate nuclear power plants. This regulatory guide will apply to Chapter 7 of that document.

Regulatory guides are issued to describe and make available to the public such information as methods acceptable to the NRC staff for implementing specific parts of the Commission's regulations, techniques used by the staff in evaluating specific problems or postulated accidents, and guidance to applicants.

Regulatory guides are not substitutes for regulations, and compliance with regulatory guides is not required. Regulatory guides are issued in draft form for public comment to involve the public in the early stages of developing their regulatory positions. Draft regulatory guides have not received complete staff review and do not represent official NRC staff positions.

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 draft regulatory guide is, however, limited to "safety systems," which are a subset of "systems important to safety."

3

guide are The information collections contained in this draft regulatory by the Office covered by the requirements of 10 CFR Part 50, which were approved may not conduct or of Management and Budget, approval number 3150-0011. The NRC of information sponsor, and a person is not required to respond to, a collection unless it displays a currently valid OMB control number.

B. DISCUSSION approach to The use of industry consensus standards is part of an overall safety systems for meeting the requirements of 10 CFR Part 50 when developing guarantee that nuclear power plants. Compliance with standards does not does ensure that regulatory requirements will be met. However, compliance be incorporated into practices accepted within various technical communities will safety systems.

the development and quality assurance processes used to design industry consensus on These practices are based on past experience and represent approaches used for development of such systems.

covered by Software incorporated into instrumentation and control systems safety system Appendix B will be referred to in this regulatory guide as an important part of software. For safety system software, software testing is Software the effort to achieve compliance with the NRC's requirements.

meet general quality engineering practices rely, in part, on software testing to 21 of Appendix A to and reliability requirements consistent with Criteria 1 and and XVII in 10 CFR Part 50, as well as Criteria I, II, III, V, VI, XI, Appendix B.

Current practice for the development of software for high-integrity that incorporates applications includes the use of a software life cycle process for software testing activities, e.g., IEEE Std 1074-1991, "IEEE Standard 3 is a key element in Developing Software Life Cycle Processes."' Software testing by IEEE Std 1012 software verification and validation activities, as indicated Plans," 3 and IEEE 1986, "IEEE Standard for Software Verification and Validation Safety Systems of Std 7-4.3.2-1993, "Standard Criteria for Digital Computers in 3 The latter is endorsed by Revision 1 of Nuclear Power Generating Stations."

Safety Systems of Regulatory Guide 1.152, "Criteria for Digital Computers in 829-1983, "IEEE Nuclear Power Plants." The consensus standard, ANSI/IEEE Std defines software Standard for Software Test Documentation" (reaffirmed in 1991),

'documentation' test documentation and specifies.its form and content. The term 4

is used here in accordance with the first meaning given in IEEE Std 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology," which defines documentation as a collection of documents on a given subject. IEEE Std 829-1983 describes a method for software test documentation consistent with the previously cited regulatory requirements as they apply to safety system software.

The documentation identified in IEEE Std 829-1983 falls into three categories: test planning, test specification, and test reporting.

All three categories provide for test information consistent with the requirements of Appendix B to 10 CFR Part 50, in particular, with the requirements of Criterion XI, "Test Control," as applied to software. The test planning category consists of a test plan that addresses key aspects of the test program, such as scope, risks, tasks, resources, responsibilities, and acceptance (pass or fail) criteria for the software item being tested. The test specification category consists of test designs, test cases, and test procedures that contain the detailed procedures and instructions for testing as well as the feature or test case acceptance criteria to be employed during the testing effort. This category is particularly relevant to Criterion V, "Instructions, Procedures, and Drawings."

The test reporting category consists of transmittal reports, test incident reports, test logs, and test summary reports that provide for the recording and summarization of test events and that serve as the basis for evaluating test results. All information in this category is summarized in the test summary report. This category addresses the requirements of part of Criterion XI, "Test Control," Criterion VI, "Document Control," and Criterion XVII, "Quality Assurance Records," as applied to software. The documentation in the test reporting category contains most of the specific information itemized in Criterion XVII (although anomaly resolution typically will be handled through the change process of the software configuration management (SCM) function).

IEEE Std 829-1983 also provides for the inclusion of additional material in any of its defined documentation; therefore, any special testing information associated with unique circumstances may also be included.

5

C. REGULATORY POSITION The requirements' contained in IEEE Std 829-1983, "IEEE Standard for to the NRC staff for Software Test Documentation," provide an approach acceptable test meeting the requirements of 10 CFR Part 50 as they apply to the listed below.

documentation of safety system software subject to the provisions guide. (In The appendices to this standard are not covered by this regulatory B to 10 CFR Part 50 this Regulatory Position, the cited criteria are in Appendix unless otherwise noted.)

10 CFR Part To meet the requirements of 10 CFR 50.55a(h) and Appendix A of to the test 50 as assured by complying with the criteria of Appendix B applied are necessary documentation of safety system software, the following provisions submittals.

and will be considered by the NRC staff in the review of applicant

1. Criterion XI, "Test Control," requires that a test program be established to components ensure that all testing required to demonstrate that systems and in will perform satisfactorily in service is identified and performed and accordance with written test procedures that incorporate requirements acceptance limits contained in applicable design documents. Criterion I, III, "Organization," Criterion II, "Quality Assurance Program," Criterion "Design Control," Criterion V, "Instructions, Procedures, and Drawings,"

Criterion VI, "Document Control," and Criterion XVII, "Quality Assurance with testing.

Records," contain requirements regarding information associated test IEEE Std 829-1983 does not mandate the use of all of its software the documentation in any given test phase. It directs the user to specify documents required for a particular test phase. If a subset of the IEEE Std 829-1983 documentation is chosen for a particular test phase, information necessary to meet regulatory requirements regarding software test documentation must not be omitted. As a minimum, this information includes:

"* Qualifications, duties, responsibilities, and skills required of persons and organizations assigned to testing activities,

"* Environmental conditions and special controls, equipment, tools, and instrumentation needed for accomplishing the testing, imposed by the NRC's regulations as 5

1n this regulatory guide, the term 'requirements" refers to requirements requirements that must be met in order to comply with a standard.

well as to 6

"* Test instructions and procedures incorporating the requirements and acceptance limits in applicable design documents,

"* Test prerequisites and the criteria for meeting them,

"* Test items and the approach taken by the testing program,

"* Test logs, test data, and test results,

"* Acceptance criteria, and

"* Test records indicating the identity of the tester, the type of observation, the results and acceptability, and the action taken in connection with any deficiencies.

Any of the above information items that are not present in the subset selected for a particular test phase must be incorporated into the appropriate documentation as an additional item.

2. Criterion VI, "Document Control," and Criterion XVII, "Quality Assurance Records," as well as 10 CFR 21.51, "Maintenance and Inspection of Records,"

of 10 CFR Part 21, "Reporting of Defects and Noncompliance," require the control and retention of documents and records affecting quality. Since design control measures must be applied to acceptance criteria for tests and since some software test documentation is re-used and evolves during the course of software development and software maintenance (for example, regression test documentation), such test documentation should be controlled as one or more configuration items under a software configuration management system. Test records, such as test reports, must be maintained as quality records and should be controlled by the software configuration management system.

3. IEEE Std 829-1983 describes software test documentation as a set of individual documents. It is acceptable for the individual documents to be incorporated into larger test documents, provided the identity of each component document is retained. For example, test plans and test designs may be packaged as a single document as long as the plan sections are clearly distinguishable from the test design sections.

4. Criterion XI, "Test Control," requires that testing demonstrate that systems, and components will perform satisfactorily in service. In section 4.2.2 of 7

IEEE Std 829-1983, in describing the features to be tested by a given test design, it is noted that other features may be exercised but not identified.

Each feature in safety system software is to be formally tested under at least one test design.

5. Criterion XI, "Test Control," requires that testing demonstrate that systems and components will perform satisfactorily in service. Traceability analyses, relating functions and test cases, provide a means for ensuring that all functions are tested. These analyses are addressed in planning for software verification and validation. 6 In section 5.2.2, IEEE Std 829-1983 suggests consideration of supplying references to item documentation as part of test case documentation. These references must be included in the test case documentation unless equivalent traceability information is maintained elsewhere in the verification and validation records.

6. Standards endorsed by regulatory guides sometimes refer to other standards.

These references to other standards should be treated individually. If a referenced standard has been incorporated separately into the NRC's regulations, licensees and applicants must comply 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 acceptable to the NRC staff of meeting a regulatory requirement as described in the regulatory guide. If a referenced standard has been neither incorporated into the NRC's regulations nor endorsed in a regulatory guide, licensees and applicants may consider and use the information in the referenced standard, if appropriately justified, consistent with current regulatory practice.

D. IMPLEMENTATION The purpose of this section is to provide information to applicants and licensees regarding the NRC staff's plans for using this regulatory guide. No backfitting is intended or approved in connection with the issuance of this proposed guide. Any backfitting that may result from applying this new guidance to operating plants would be justified in accordance with established NRC backfitting guidance and procedures.

6 For example, see IEEE Std 1012-1986, 'IEEE Standard for Software Verification and Validation Plans."

8

This draft guide has been released to encourage public participation in its development. Except in those cases in which an applicant proposes an acceptable alternative method for complying with specified portions of the NRC's regulations, the method to be described in the active guide reflecting public comments will be used in the evaluation of submittals in connection with applications for construction permits, standard design certifications and design approvals, and combined operating licenses. The active guide will also be used to evaluate submittals from operating reactor licensees that propose modifications that go beyond the current licensing basis if those modifications are voluntarily initiated by the licensee and there is a clear connection between the proposed modifications and this guidance. This guide will be used in conjunction with, and will eventually be reflected in, the Standard Review Plan, which is currently under revision.

9

E. REGULATORY ANALYSIS Id

1. PROBLEM Because traditional and well-understood methods of design and quality assurance for developing and manufacturing hardware apply imperfectly to software design and development, additional guidance beyond standard approaches for hardware is necessary if the intent of the NRC's regulations is to be achieved.

This problem is faced in many industries where computers and software are replacing traditional hardware-only instrumentation and control (I&C) designs.

To this extent, the nuclear industry is not very different from any industry associated with high-consequence hazards. While additional guidance is necessary to help prevent failures of digital I&C safety systems, the potential benefits of these systems make their use highly desirable.

The use of computers and software in safety-related I&C designs is part of the larger problem of ensuring long-term safety of nuclear power plants, and it is seen as part of the solution as well. It is not just digital systems themselves that give rise to concerns about design verification and quality assurance, but the increase in complexity of the system designs (including software) being attempted is also a factor. The NRC staff discussed its concerns in SECY 91-292, "Digital Computer Systems for Advanced Light Water Reactors,"' and again in parts of SECY 93-087, "Policy, Technical, and Licensing Issues Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs."'

Subsequently, the NRC staff sponsored studies that resulted in characterization of design factors, guidelines, technical bases, and practices generally considered appropriate for high-integrity software [see NUREG/CR-6101, "Software Reliability and Safety in Nuclear Reactor Protection Systems (November 1993);

NUREG/CR-6113, "Class 1E Digital Systems Studies" (October 1993); NUREG/CR-6263, "High Integrity Software for Nuclear Power Plants: Candidate Guidelines, Technical Basis and Research Needs (June 1995); NUREG/CR-6293, "Verification and Validation Guidelines for High Integrity Systems" (March 1995); and NUREG/CR 1

Copies are available for inspection 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; telephone (202)634 3273; fax (202)634-3343.

10

6294, "Design Factors for Safety-Critical Software" (December 1994)].2 These studies identified software design control techniques that are currently being used in "best practice" software development efforts. While it is possible to simply list the criteria covered, the problem still remains of reaching a common understanding between the NRC staff and industry practitioners regarding what constitutes acceptable software engineering practice for safety systems. An agreed-upon collection of standards, established practice, and engineering techniques for software engineering methods is needed to complement the collection that already supports traditional hardware engineering methods, such as statistical quality control, testing standards, and quality assurance techniques used on design and manufacturing processes for hardware components.

Software testing is a key element in software verification and validation activities and is fundamental to the assurance of software quality, as evidenced by the large body of literature on the subject. An effective testing program depends on careful planning and execution and this, in turn, depends partially on appropriate documentation. For systems and components under its purview, Appendix B to 10 CFR Part 50 requires test control, including the use of written test procedures and documentation of test results, as well as the maintenance of sufficient records to furnish evidence of activities affecting quality. The importance of software testing in the development of high-integrity software is stressed in the studies cited above. NUREG/CR-6101, in its description of activities and related documents necessary for the production of reliable software, addresses software testing in the implementation, integration, and validation phases. NUREG/CR-6263 devotes a chapter to software testing, addressing unit, integration, system, and installation testing. It proposes guidelines suggesting formal test plans, specifications, and test reporting in accordance with IEEE Std 829-1983 and evaluates the technical basis for this guidance as satisfactory. A common understanding between the staff and applicants of an acceptable method for accomplishing all three categories of software test documentation will therefore benefit staff safety reviews significantly, and the technical basis for such an understanding exists.

Therefore, software test documentation is an appropriate subject for staff review.

2 Copies may be purchased 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 also available for inspection 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; telephone (202)634-3273; fax (202)634-3343.

11

2. ALTERNATIVE APPROACHES Based on the studies referenced above, consensus in the software engineering community was decided to be sufficient to ensure widespread familiarity and reasonable levels of agreement. There are two additional approaches, taking no action and prescribing a detailed approach built from staff selections of best practice. In all, three alternative approaches were identified:

1. Take no action,

2. Prescribe a detailed approach,

3. Endorse one or more software engineering standards.

The first alternative, taking no action, has the attraction that its initial cost is low since there are no "start-up" activities. It has flexibility, since each applicant would develop its own technical basis demonstrating that its digital system, and the quality assurance measures applied to it, complied with the NRC's regulations. However, this could have adverse effects on the level of staff effort required to conduct reviews or to ensure consistency among reviews.

In the absence of an identified set of commonly accepted guidelines, practices, and quality assurance measures applicable to software engineering, NRC staff reviews would take longer and require greater effort to ensure consistent staff safety evaluations. From the applicant's perspective, this flexibility also has associated potential costs because there could be more unknowns associated with demonstrating compliance with regulations. Although the initial cost would apparently be low, taking no action could result in greater total costs, to both the NRC staff and the applicant, during the safety evaluation process.

Prescribing a detailed approach could have significant preliminary costs involved in formulating the approach and dealing with the public comment that would inevitably result. The staff has been reluctant in the past to take this approach. Such an approach places the staff in the position of designer and compromises, or appears to compromise, the staff's independence as design safety reviewers; this not the role of the regulator.

Consensus standards on software development are available and represent current good practice as agreed upon by responsible professionals in the software industry. Many organizations issuing standards, such as the IEEE and ANSI, provide for review and revision of standards at regular intervals to ensure the consensus positions are current. In the United States, the Institute of 12

Electrical and Electronic Engineers (IEEE), the American Nuclear Society (ANS),

the Electronic Industry Association (EIA), the Instrument Society of America (ISA), the American Society of Mechanical Engineers (ASME), and the American National Standards Institute (ANSI) are the standards bodies issuing software engineering standards, computer standards, or related quality standards. In Europe, the International Electrotechnical Commission (IEC), the International Organization for Standardization (ISO), the International Atomic Energy Agency (IAEA), and the Comit6 Consultatif International T6l6graphique et T6l6phonique (CCITT) fill the same roles. The European Committee for Electrotechnical Standardization (CENELEC), a regional standardization body, adopts national and international standards. The overall collection of standards issued by these bodies covers a variety of subjects considered important to software quality.

The standards specific to the nuclear industry issued by the U.S.-based organizations are, in general, compatible with the NRC's regulations. The software engineering standards issued by these organizations, notably the IEEE software engineering standards, are in general compatible with nuclear-industry specific standards. Together, these standards form a framework for addressing the use of software within nuclear systems in the U.S. nuclear regulatory environment. Selected international standards can complement this framework; however, they tend to be organized differently and do not map directly into the U.S. industry-specific framework.

3. VALUES AND IMPACTS Values and impacts for each of the three identified approaches are analyzed below. In this analysis, the probability of an alternative approach having a positive effect on software quality and the probability of the effect of software quality on the achievement of overall safety goals are not known quantitatively.

Although the current state of the art does not support quantitative estimates, the results of poor software quality are evident in notable instances of software failure in various industries. Therefore, a positive correlation between software quality and the achievement of safety goals is inferred from the instances of negative effects of poor software quality, i.e., software quality is a necessary but insufficient factor in achieving safety goals. In the summary below, an impact is a cost in schedule, budget, or staffing or an undesired property or attribute that would accrue from taking the proposed approach. Both values and impacts may be functions of time.

13

3.1 Alternative 1. Take No Action If no action is taken, retaining the status quo, the NRC staff will continue to receive applications or requests to review safety questions that are prepared with no clear guidance on what the staff considers to be acceptable methods of ensuring that safety-related software meets the requirements of the NRC's regulations. Each applicant will propose measures it deems necessary, and these measures will be reviewed by the staff and discussed with the applicant to reach a resolution that is acceptable to the NRC staff and the applicant. This preserves the value of flexibility, but at the impact of additional staff and applicant effort and potential schedule extension. It is possible that a de facto staff position would develop from the accumulation of successful applications, but the amount of time and effort required to reach this condition is unknown.

Value - No value beyond the status quo Impact - Schedule, budget, and staffing cost, to the staff and applicant, associated with regulatory uncertainty 3.2 Alternative 2. Prescribe a Detailed Approach If the staff prescribed a detailed approach, applicants would enjoy regulatory certainty at the expense of reduced flexibility. Tangible immediate impacts would include staff time to specify and defend the approach in a public forum. Intangible impacts would include a potential compromise of staff effectiveness as impartial safety reviewers and a loss of input from innovative applicants. Future impacts would include maintenance of the approach as newer software engineering methods were developed by the technical community.

Values - Probable improvement in the likelihood of achieving safety goals as a consequence of staff expertise and specialized knowledge derived during the development of the prescribed approach

- Common understanding of regulatory view of software practice Impacts - Cost of staff effort to develop the approach

- Potential compromise of staff objectivity

- Innovative approaches discouraged as a result of increased cost

- Cost of evolving, maintaining, and communicating the approach 14

3.3 Alternative 3. Endorse One or More Software Engineering Standards If the staff endorses selected consensus software engineering standards, the staff and applicants obtain the benefit of the work of responsible software engineering professional standards committee volunteers. The value in this is the common understanding between the staff and applicants of an approach that has acceptance as good practice in the technical community. The standards usually permit tailoring to meet the needs of particular situations, so that a medium level of flexibility is retained. Additional staff effort is minimal, since members of the staff are already active in standards committees that the staff considers important to safety. Because detailed standards that address specific software engineering practices are available, the staff may select standards that address topics of particular importance regarding safety system software. Many standards, including IEEE software engineering standards, are reviewed and updated periodically, which acquaints the staff with changing practices.

Coordination of standards efforts for standards used widely in the U.S. with international standards efforts is increasing, but the outcome of this is still unpredictable.

Values - Probable improvement in the likelihood of achieving safety goals as a consequence of improvement in software practices

- Consideration of relevant topics

- Common understanding of good software practice, as defined by consensus processes in the software industry

- Maintenance and evolution of the definition of good software practice by the software industry Impact - Cost of endorsing the selected standards

4. CONCLUSIONS There are a number of potential benefits associated with the use of digital I&C safety systems in nuclear power plants. Implementations of these systems must be consistent with the Commission's regulations. Three approaches to providing additional guidance for software were examined. Taking no action may result in accumulating regulatory expense as applicants submit proposed methods to assure the staff that safety-related software meets the requirements of the NRC's regulations. A de facto acceptable method would probably evolve, but the time and effort required for this to happen are unknown. A detailed staff prescription has unacceptable impacts and would involve the staff directly in the 15

applicant's solution of technical problems. Endorsing selected software engineering standards has good value with minimal impact and addresses the stated problem. Note that none of these approaches presents new regulatory requirements; they define acceptable approaches for meeting existing requirements.

5. DECISION RATIONALE Based on the lowest impact and highest value for problem solution capability, the third alternative, endorsing selected software engineering standards, has been chosen. The highest value will be achieved by selecting standards that address software engineering processes that have a high potential for ensuring that safety system software meets the requirements of the NRC's regulations as they are applied to software. Standards should be selected based on relevance and maturity.

16

BIBLIOGRAPHY Hecht, H., A.T. Tai, K.S. Tso, "Class 1E Digital Systems Studies, NUREG/CR-6113, USNRC, October 1993.'

Hecht, H., et al., "Verification and Validation Guidelines for High Integrity Systems," NUREG/CR-6293, USNRC, March 1995.'

Institute of Electrical and Electronics Engineers, "Standard 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 Lawrence, J.D, and G.G. Preckshot, "Design Factors for Safety-Critical Software," NUREG/CR-6294, USNRC, December 1994.'

Seth, S., et al., "High Integrity Software for Nuclear Power Plants: Candidate Guidelines, Technical Basis and Research Needs," NUREG/CR-6263, USNRC, June 1995.'

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.

Copies may be purchased 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 Document Room at 2120 L Street NW., Washington, DC; the POR's mailing address is Mail Stop LL-6, Washington, DC 20555; telephone (202)634-3273; fax (202)634-3343.

2Single copies of regulatory guides may be obtained free of charge by writing the Office of Administration, Attention: Distribution and Services Section, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; or by fax at (301)415-2260. Copies are available for inspection 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; telephone (202)634-3273; fax (202)634-3343.

17

'IN F on recycliednP Federal Recycling Program

UNITED STATES FIRST CLASS MAIL POSTAGE AND FEES PAID NUCLEAR REGULATORY COMMISSION USNRC WASHINGTON, DC 20555-0001 PERMIT NO. G-67 OFFICIAL BUSINESS PENALTY FOR PRIVATE USE, $300