**NUREG/CR-6263** [^1]**\-- A Valuable Resource for**

**Safety Software Quality Assurance (SQA)**

**Dr. Shivaji S. (Shiv) Seth**

**Senior Technical Advisor**

**DOE Richland Operations Office**

## Tel: (509) 376-8129; e-mail: shivaji_s_seth@rl.gov

# Introduction

Safety software professionals, including government safety oversight SQA
personnel, will find safety software guidelines and considerable
supporting resource information in the two volumes of *High Integrity
Software for Nuclear Power Plants -- Candidate Guidelines, Technical
Basis and Research Needs, NUREG/CR-6263, June 1995,* which was prepared
for the U.S. Nuclear Regulatory Commission (USNRC). The document is
essential reading for Department of Energy (DOE) personnel planning to
qualify to the Safety Software Quality Assurance Functional Area
Qualification Standard, DOE-STD-1172. Understanding the context,
framework, and organization will help making proper and quick use of
this landmark reference.

The purpose of this paper is simply to introduce the work presented in
NUREG/CR-6263 in terms of its context, focus, and organization. The
presentation is not a substitute for the introductory sections of both
NUREG/CR-6263 volumes, which are an important reading for understanding
why the work was performed and how it was documented.

While NUREG/CR-6263 is most pertinent to the development and assurance
of custom software for the highest grade of safety instrumentation and
control (I&C) systems in nuclear plants and facilities, considerable
material in the document, if used judiciously, would also apply to other
types of safety software, such as safety analysis and design computer
codes and databases and commercial-off-the-shelf (COTS) software.

# Context

Nuclear plants and facilities have made increasing use of digital
technology both to enhance the operational performance of I&C systems,
and to alleviate concerns regarding the obsolescence of analog systems.
Other characteristics of software-driven systems, however, have raised
safety and licensing issues. Software errors are less tractable and more
difficult to detect than hardware-related failures. The reliability of
software is a primary concern. For example, a software coding error that
causes redundant systems using the same platforms, operating systems,
and software to fail could be hazardous.

Numerous standards and methodologies exist for developing software and
assuring its quality. However, several previous studies, as well as the
USNRC and the interdisciplinary team working on the subject document,
found that most standards did not provide the necessary level of detail,
breadth of coverage, or coherence from the standpoint of nuclear safety.
In particular, the *technical basis* for a comprehensive set of
regulatory requirements and guidelines for safety software, in a manner
that the USNRC would find acceptable, had not been analyzed nor
documented systematically. For the USNRC, the description and assessment
of technical basis for regulatory positions consists of a consideration
of the following five elements:

(1) Relation to safety

(2) Definition of scope

(3) Body of knowledge and evidence

(4) Availability of a repeatable implementation method

(5) Threshold for acceptance

Therefore, the USNRC identified an important need to examine the
technical basis for guidelines that could be considered in reviewing and
evaluating safety system software. Based on that examination, candidate
guidelines with an adequate technical basis could be considered in
developing regulatory requirements and guidance, while those with an
inadequate technical basis could be considered in developing additional
research projects.

A panel of outside experts with considerable knowledge of software
safety and reliability relative to different government and industry
programs provided a peer review of NUREG/CR-6263 in its preliminary
draft stage so that their comments and best judgment could be properly
factored into revising and finalizing the report.

# Objectives and Important Caveats

The objective of the work on NUREG/CR-6263 was to develop a
comprehensive set of proposed guidelines and technical basis for
regulatory positions related to the use of safety software in nuclear
power plants, and to identify research that could enhance the technical
basis.

An important assumption in the work (as for any software life-cycle
standard) was that system-level analyses would be thoroughly conducted,
and thus, all requirements and constraints allocated to the software
could be specified completely, correctly, and clearly. In other words,
the guidelines for developing even the highest quality software must
rely on thorough systems analyses to define all the components and
functions of the hardware, human operator/user, and software, and to
ensure that the system-software interface is completely defined
\[[please refer to Figure 1](../shive_presentation/FIG-1.ppt)\]. The
reason for emphasizing this is that several important studies have found
critical software defects to occur when the system-software interface is
not adequately defined. \[This important topic is discussed in Section
2.2 of NUREG/CR-6263, Vol. 2.\]

Another assumption on the application of NUREG/CR-6263 is that the
proposed guidelines could not be "graded" for use in nuclear systems
belonging to different safety categories. The guidelines were assumed to
apply to the highest-grade safety systems, and any potential relaxation
of the standards, e.g., based on system function or degree of
redundancy, was not considered in the study. The authors did not find
sufficient empirical evidence to provide the technical basis for
differentiating guidelines for different categories. Moreover,
cost-benefit considerations were not a part of the study.

Finally, the nature of the available technical basis for developing
high-quality safe software -- actually, the lack of the kind of "first
principles" on which the safety requirements for hardware are often
founded -- is the reason for focusing so much on the life-cycle
processes for developing and maintaining software. A deterministic
evaluation of a complex software system is currently an intractable
problem. \[This topic, which underscores the importance of SQA is
discussed in Technical Basis, Section 1.3.2 of NUREG/CR-6263, Vol. 2.\]

# Framework and Approach

The software development component of the overall system development
provided the framework for developing guidelines. This framework is
shown in [Figure 2](../shive_presentation/FIG-2.ppt). The illustration
using the water-fall process model of software development is not an
endorsement of that model; the timing of the activities may vary and
overlap. Software life-cycle activities relate to either development or
assurance. The software assurance activities are closely coupled with
the development activities and are performed throughout the life-cycle.

The following orderly and systematic approach was taken to meet the
objectives:

1.  Develop guidelines applicable to each software life-cycle stage.

2.  Examine and describe the technical basis for each guideline, where
    it exists.

3.  Identify research needs where the technical basis is insufficient or
    lacking.

The development and organization of the guidelines mapped directly to
the elements of the framework shown in Figure 2. However, depending on
the technical content of a given element, and in order to avoid
overlapping discussion, some elements were combined or re-grouped. For
example, the guidelines for the four successive levels of software
testing and for verification and validation (V&V) were grouped into
three elements: V&V -- Static, V&V -- Dynamic (Testing), and V&V --
General Considerations. \[This mapping of the software life-cycle
elements to the specific sections of NUREG/CR-6263, Volume 2, where the
guidelines for the element are discussed, is shown in Figure 2-3, p.
2-9, of Volume 2.\]

For each software development or assurance activity (framework
*element*), guidelines were developed according to the important areas
(framework *subelements*) covered by the element. For example, Interface
Integrity of a software system is one of the subelements within the
element Software Design. [Figure 3](../shive_presentation/FIG-3.ppt)
shows all the framework elements and subelements into which the
guidelines were organized. \[A brief and succinct description of the
scope of each framework element and subelement is provided in Section 4
of the Executive Summary, NUREG/CR-6263, Volume 1.\]

# Guidelines and Technical Basis

A full set of approximately 200 guidelines that span the entire range of
software life-cycle activities, along with the technical basis
assessment for each guideline, is presented both in the Executive
Summary (Volume 1, Table ES-1) and the Main Report (Volume 2, Appendix
A) of NUREG/CR-6263.

[Figure 4](../shive_presentation/FIG-4.ppt) depicts the process that was
used in NUREG/CR-6263 for developing guidelines from a combination of
certain established sources and several other pertinent standards.

Certain industry standards that cover a broad range of software
development and assurance activities and that are well recognized in the
nuclear industry were the primary sources for deriving guidelines within
each framework subelement. These sources, termed the "baseline" in
NUREG/CR-6263, included IEEE7-4.3.2 *(Standard Criteria for Digital
Computers in Safety Systems of Nuclear Power Generating Stations),*
ASME-NQA-2a *(Quality Assurance Requirements of Computer Software for
Nuclear Facility Applications),* IEC-880 (*Software for Computers in the
Safety Systems of Nuclear Power Stations),* and various IEEE standards,
as well the USNRC's applicable regulatory guidance documents.

The discussion of each subelement in NUREG/CR-6263, Volume 2, first
presents the set of guidelines and then a description of the technical
basis for those guidelines. The description starts with the baseline
sources. Pertinent statements that describe software attributes relevant
to safety are extracted and presented straight from the sources. SQA
professionals using NUREG/CR-6263 would find this feature most
convenient because the direct quotes from the baseline sources could
save them the effort of searching, accessing and locating the desired
guidance.

Any gaps in the baseline for which additional guidelines should be
considered were also identified. The technical basis description for
each subelement includes the rationale and justification for any
additional guidelines in terms of their relationship to safety. The
additional guidelines to fill the observed gaps in the baseline were
derived from defense, aviation, aerospace, and other nuclear industry
standards, including some developed in other countries.

The availability of implementation methods, approaches, criteria, or
tools to achieve conformance with the guidelines is also discussed for
each subelement.

The discussion of the technical basis for each subelement concludes with
an assessment that identifies any research needs to strengthen the
technical basis. Research needs are discussed at the end of each section
and an overall assessment of those needs is presented in the last
section of the report. The discussion of description, assessment,
categorization, and prioritization of research needs, which was
explicitly required by the USNRC in this study, may not be of great
interest to SQA professionals who simply wish to understand and apply
the best existing standards.

[^1]: S. Seth, et al, *High Integrity Software for Nuclear Power Plants
    -- Candidate Guidelines, Technical Basis and Research Needs,
    NUREG/CR-6263, June 1995.* Available (at no charge to government
    agencies) by writing to the following e-mail address:
    distribution@nrc.gov