Manuscript Completed: May 1992

Date Published: July 1992

Systems and Software Technology Division

Computer Systems Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899

Prepared for

U.S. Nuclear Regulatory Commission

Washington, DC 20555

NRC FIN # L19762

This report presents results of a study of standards, draft standards, and guidelines (all of which will hereafter be referred to as documents) that provide requirements for the assurance of software in safety systems in nuclear power plants. The study focused on identifying the attributes necessary in a standard for providing reasonable assurance for software in nuclear systems. The study addressed some issues involved in demonstrating conformance to a standard. The documents vary widely in their requirements and the precision with which the requirements are expressed. Recommendations are provided for guidance addressing the assurance of high integrity software. It is recommended that a nuclear industry standard be developed based on the documents reviewed in this study with additional attention to the concerns identified in this report.

Page

Under the interagency agreement RES-91-003 between the United States Nuclear Regulatory Commission (NRC) and the National Institute of Standards and Technology (NIST), NIST is responsible for providing NRC with current information regarding standards and practices for assuring safety of the software for safety systems in nuclear power plants. This report presents the results of a study that is defined by the following:

High integrity software is software that must be trusted to work dependably in some critical function, and whose failure to do so may have catastrophic results, such as serious injury, loss of life or property, business failure or breach of security. Examples include software used in safety systems of nuclear power plants, medical devices, electronic banking, air traffic control, automated manufacturing, and military systems. Standards, draft standards, and guidelines (hereafter referred to as documents) from each of these fields were examined in this study. The documents reviewed included those recommended by NRC and a few others that collectively reflect the trends of the standards community for high integrity software. Comprehensive documents that address more than one software engineering process were examined. From over 50 documents, ten were selected for further study. Most of these documents have broad scopes and provide guidance across the entire software lifecycle for several software engineering processes. Documents of narrower scope (i.e., single topic) were used to identify criteria for specific software engineering practices and processes that should be addressed by standards for high integrity software.

The following principal questions guided the review of the documents:

The focus of this study is on software assurance issues (i.e., assurance that the software meets safety requirements). Usually, the software will be embedded in a system in which software is only one component. Although the software lifecycle, not the system lifecycle, is the focus, the software lifecycle's relationship to the system lifecycle must be understood in order to place assurance activities in the proper context. System activities are not included in the review criteria beyond the extent necessary to evaluate software assurance requirements. While the documents in this study were reviewed relative to the assurance of software for safety systems in nuclear power plants, the criteria and recommendations contained in this report are applicable to other critical software safety systems.

Criteria for answering the principal questions should be derived from a body of knowledge or rigorous technical specifications for software engineering, especially specifications that are essential in building high integrity software. For software engineering, the body of knowledge has not yet been rigorously codified but is distributed among standards, guidelines, technical reports, conference presentations, and information proprietary to organizations. Few documents reviewed in this study reflect the growth of the knowledge base found in technical reports and conference presentations, which are not subjects of this review. The criteria used for this study are based on the authors' experience and knowledge derived from these various sources of information.

Documents were reviewed against a template (see Appendix A) of detailed criteria in several categories: levels of criticality/assurance, lifecycle phases, documentation, required software functionality against hazards, engineering practices for the development of software, project planning and management, and assurance activities which include software verification and validation, software quality assurance, software configuration management, and software hazard analysis. The template also includes procurement issues. The template's Presentation category provided a mechanism for objectivity in identifying how well an auditor can demonstrate compliance of a system with a specific document's requirements.

Each document was analyzed according to the criteria to answer the principal questions. The relative strengths and weaknesses of the documents were compared. No single standard or guideline reviewed for this study completely satisfies all the evaluation criteria, although most documents satisfy requirements for at least one category of criteria in the template.

No standard can guarantee the safety of a particular software system. In other words, no one can ever say "If a developer follows this standard, the system will be safe." The judgement of safety for a particular installation must be made by the appropriate authorities. Ideally, standards should state what is required for evaluating the safety of a system, and to determine if the software complies with the standard. That is, "These are the things that must be done to enable NRC to judge whether the system is safe enough to not pose an undue risk to public health and safety."

It is recommended that NRC considerations of consensus standards, draft standards, and guidelines include the concerns identified in this report. While information from all of the documents can be used in developing a rigorous standard, other concerns must be addressed. For example, the scope of the standard within system and software lifecycles must be clearly identified. The standard should require that software is always assured in the context of the particular system under evaluation. Guidance for assurance of high integrity software should either describe all practices or cite acceptable standards for them, encompassing at least the criteria in Appendix A.

Leo Beltracchi of the United States Nuclear Regulatory Commission (NRC) provided substantial guidance to the authors of this report. Franklin Coffman and Julius Persensky, NRC, also contributed to this report.

Acronyms used in this report (other than those used to refer to documents) are listed below.

CASE Computer Aided Software Engineering

CM Configuration Management

DID Design Input Documentation

FMEA Failure Modes and Effects Analysis

FTA Fault Tree Analysis

IV&V Independent Verification and Validation

O&M Operation and Maintenance

QA Quality Assurance

SCM Software Configuration Management

SCMP Software Configuration Management Plan

SDD Software Design Description

SDP Software Development Plan

SQA Software Quality Assurance

SQAP Software Quality Assurance Plan

SRS Software Requirements Specification

SSP Software Safety Plan

SV&V Software Verification and Validation

SVVP Software Verification and Validation Plan

V&V Verification and Validation

Under the interagency agreement RES-91-003 between the United States Nuclear Regulatory Commission (NRC) and the National Institute of Standards and Technology (NIST), NIST is responsible for providing NRC with current information regarding standards and practices for assuring safety of the software for safety systems in nuclear power plants. This report presents the results of a study that is defined by the following:

While the documents in this study were reviewed relative to the assurance of software for safety systems in nuclear power plants, the criteria and recommendations contained in this report are applicable to other critical software safety systems.

This report contains the results of a review of current US and international standards and guidelines (hereafter referred to as documents) for high integrity software and their analysis relative to potential use in the nuclear industry with regard to safety applications. High integrity software is software that must be trusted to work dependably in some critical function, and whose failure to do so may have catastrophic results, such as serious injury, loss of life or property, business failure or breach of security. Some examples include software used in safety systems of nuclear power plants, medical devices, electronic banking, air traffic control, automated manufacturing, and military systems [NIST190]. Documents from each of these fields were examined in this study including those recommended by NRC and a few others that collectively reflect the trends of the standards community for high integrity software.

Comprehensive documents that address more than one software engineering process were examined. From over 50 documents, ten were selected for further study. One of these is a book of five chapters produced by a European committee; this study considered each of the five chapters as a separate document. Therefore, 14 documents were reviewed. The titles of these documents and their respective acronyms used in this report are in Table 1-1. Complete references are in Section 5.

Most of these documents have broad scopes and provide guidance across the entire software lifecycle for several software engineering processes. Documents of narrower scope (i.e., single topic) were used to identify criteria for specific software engineering practices and processes that should be addressed by standards for high integrity software. Titles and acronyms of documents that were used to provide additional criteria are listed in Table 1-2. Complete references are in Section 5.

Table 1-3 lists the categories of criteria used to respond to the principal questions that were derived from the documents listed in Table 1-2.

Section 2 of this report provides a description of the criteria for each category in this template, that is, the detailed requirements. Section 3 contains a comparison of the documents for each of the review criteria. Section 4 contains the summary of this study. Appendix A identifies some of the features against which each document was analyzed. Appendix B contains the review of each document based on the criteria.

This study required a review of documents potentially useful for assuring high integrity software in safety systems of nuclear power plants. The focus of this study was on software assurance issues (i.e., assurance that the software meets safety requirements). Usually, the software will be embedded in a system in which software is only one component. Although the software lifecycle, not the system lifecycle, is the focus, the software lifecycle's relationship to the system lifecycle must be understood in order to place assurance activities in the proper context. In general, system activities are not included in the review criteria beyond the extent necessary to evaluate software assurance requirements.

The documents were reviewed according to criteria developed to answer the following principal questions:

To meet the first set of questions, the software system must be of high integrity. To build a high integrity system, developers, assurers, and customers need a body of knowledge or technical specifications for high integrity software. For many engineering disciplines, that body of knowledge may be found in handbooks and rigorous standards. For software engineering, the body of knowledge has not been rigorously codified. Software engineering knowledge is distributed among standards, guidelines, technical reports, conference presentations, and information proprietary to organizations. It is important to understand this distinction between software engineering and older engineering disciplines. Due to this lack of codified information, this review was based on criteria which reflect the authors' knowledge and experience derived from various sources of information, including technical reports, conference proceedings, and related standards. NIST has published two such technical reports that address high integrity software issues. One identifies the range of requirements (e.g., functional, interface, performance, security, safety, and quality) for inclusion in defining a software system [NIST180]. The other report identifies current practices and issues in developing and assuring high integrity systems [NIST190].

The second set of principal questions deals with the customer and is designed so that the requirements of the documents would be interpreted objectively. The customer must be able to determine that the software system has met the requirements. A standard serves as a measuring tool to apply to the software. The customer must be able to use the standards and guidelines to determine how the software satisfies the specific contractual requirements of the software. Another important point considered was whether or not the document clearly defines what conformance to the document means. The presentation of a document heavily influenced the answers to this set of questions.

The template in Appendix A summarizes some of the criteria used to review the documents. Other criteria are based on standards for specific processes, technical articles, and staff experience. The rationale for the criteria are described in the remainder of Section 2.

Computer software is used to drive many types of systems (e.g., air traffic control, medical devices, rail transportation, nuclear power systems, and software systems that stand alone). Failure of these systems may have different consequences, which can be assigned a level of seriousness or criticality. The most serious of these consequences is usually considered to be loss of life and is assigned the highest level of criticality. For these systems, the most rigorous software standards and practices must be invoked. Other levels of criticality take into account how serious a failure is relative to the completion of the task the system is responsible for, and how devastating the failure may be relative to destruction of property and environment, injuries, and other losses. While software systems used for safety systems in nuclear power plants are at the highest level, not all of the documents reviewed in this study are written at this level. A trend observed after examining many documents is that documents identify requirements according to levels of criticality not only for the principal system but for its support software and for software used to develop and assure it. Other factors (e.g., new technology, importance of mission, project size) may affect the needed level of assurance, but in this report the concern is the criticality level based on the consequences of failure.

For this study, the scope of each document relative to the software lifecycle is identified. While there are many representations of the software lifecycle and names for lifecycle phases, this report uses the following names to represent the lifecycle phases:

The phases are used only to help in identifying the scope of each document; this study was not concerned with a particular lifecycle management (e.g., waterfall, spiral). While some activities in software development and assurance need to be performed at certain times in the lifecycle (e.g., system test planning during requirements), no judgments are made on lifecycle management. The priorities centered on the activities themselves and how well a document addresses a particular phase. Therefore, it is not necessarily undesirable if a document addresses only some phases. For completeness, assurance of a software system relies on all aspects of software; that includes the entire lifecycle. By identifying documents that address partial lifecycles, it may become clear which documents, or parts of them, may be used together.

In standards dealing with the system lifecycle, it is sometimes difficult to know when a requirement is imposed on the software, or takes effect only after integration of the software with system components (e.g., configuration management (CM)). The focus of this study was on the set of activities that should be levied on the software.

Documentation of a software system serves many purposes, including the following:

This study uses a small set of documentation (based on an examination of many documents) as a baseline for review. The list does not include documentation for software quality assurance (SQA), software CM (SCM), and software verification and validation (SV&V) because these topics are addressed in other sections of the template. This study concentrated on software documentation. However, system requirements may be included with software documentation when the system requirements specification levies requirements on the software. The following types of questions were considered:

A standard may be used by a vendor to build a product and by an auditor to verify compliance to the standard. A useful documentation tool that aids both the vendor and auditor is a checklist of the requirements.

Critical systems require defensive functions to prevent unintended functions and to allow operation to continue despite errors and component failures. At the system level, a hazard analysis provides information concerning the types of hazards or threats that could adversely affect system behavior. From the system hazard analysis, some software functions may be identified to prevent hazards or to mitigate the effect of problems. Additionally, a software hazard analysis may be conducted to reveal other functionality. Special software functions are often included to detect, tolerate, override, or recover from failures. Examples include the use of prompts that query the operator as to whether or not a keyed-in command should actually be executed, and the use of software devoted to error detection and correction (e.g., telephone switching systems where, typically, 50% or more of the software serves this function). Defensive functions should be a consideration in a standard for safety critical software.

Some special software functions which may be generic to any system concerned with software safety or computer security are listed in Appendix A. Not all of the functions are essential in all systems, but an auditor should look for the use of these functions, or reasons why they are not needed in a particular system. The list is not necessarily complete nor does reference to such a list eliminate the need for system and software hazard analyses to identity software functions for a specific system.

Certain software engineering practices can either contribute or detract from the safety and reliability of a system. For example, systems constructed from modules that each perform a single, well-defined function are likely to be more reliable than those where modules perform a mixture of functions (e.g., both control and data input/output). Choice of programming language is another example. Systems written in assembly language tend to be much more error-prone than those developed in modern high-level languages such as Pascal, C, and Ada [NRC91]. The National Research Council has recommended the use of simple modules and high-level languages [NRC91].

A standard for safety critical software should give guidance on software engineering practices that contribute to high integrity. Rigid rules for the use of specific software engineering practices are not always appropriate. In some cases, it may not be possible to develop software for a particular application in a way that is normally considered good software engineering practice in other applications. For example, it is normally considered good practice to separate critical functions from the rest of the system, placing critical functions in a small module that can be more readily analyzed than a large system. It has been argued that some safety critical systems cannot be built in this way because, in some systems, safety concerns are present in all functions.

However, it is essential that developers use established and acceptable practices as much as possible, and explain cases where established practices were not used. Section A.5 lists practices for consideration in all projects, even if not all techniques are appropriate for all projects. The major types of software engineering practices considered in this review are explained below.

Specifications - A good specification must be clear, unambiguous, and analyzable, so that flaws can be found before the system is built. Specifications can be characterized as informal (English text and block diagrams), semi-formal (pseudo code or "structured English" plus standardized notation such as structure charts and data-flow diagrams), or formal (mathematics such as logic and set theory). Formal specifications make it possible to do the kind of rigorous mathematical design analysis that is conducted in traditional engineering. With less formal specifications, this is not possible; thus formality in specifications is desirable.

Component isolation - Ideally, components that are critical to system safety should be isolated from other parts of the system. Safety functions should be kept separate from one another.

Modularity - All systems should be constructed in a modular fashion, where each module performs a single, well-defined function.

Language - Programmers are more likely to make errors using assembly languages than in using high-level languages such as Ada, Pascal, Fortran and C [NRC91]. The tradeoff may be that the high-level language compiler itself may have errors but the compiler should have the same level of software assurance as the software systems that will be built with it. The extra expense of assurance for the compiler will be offset by reduced expense in assuring one or more software systems built with it. Many reasons for using high-level languages are cited in NRC91. Standards should encourage the use of high-level languages and discourage assembly language, except where absolutely necessary.

Deprecated programming practices - Many programming practices, such as floating point arithmetic or use of interrupts, result in systems whose behavior is difficult to analyze. Standards for critical software often discourage such practices in order to make the software evaluation more effective [MOD0055].

Quality Attributes - While many standards require SQA activities to check for quality of software products, few specify what the qualities should be, or specify requirements for those qualities. Standards should identify quality attributes and definitions of those attributes. For example, some of the documents require that a specification be "complete." Because "completeness" can be ambiguous, it is important to clearly state the rules of completeness. For example, one rule may be that a document require the types of requirements to be defined (e.g., functional, performance, safety, security, quality, and interface requirements from the software to the system).

This section of the template identifies the activities that will locate problems (e.g., errors, faults) in the development process and products, and will provide evidence that the software complies with its specifications. These activities are performed from the beginning of the software lifecycle, through development, to maintenance of software. Results from the activities may affect the software requirements, design, or code, and sometimes the system itself. The template in Appendix A addresses activities performed during the software lifecycle and, in some cases, these activities require as input the system requirements specification and reports of system hazard analyses. It should be noted that this template does not address activities of assurance that are specific to the final evaluation of a product before delivery (e.g, acceptance test, final audit, system validation).

Software verification is "the process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase." Software validation is "the process of evaluating software at the end of the software development process to ensure compliance with software requirements." [IEEE1012] The definitions for verification and validation may be different in the system context than they are in the software context. In the system context, the activities of verification are separate from those of validation, which is performed on the completed system. In the software context, the distinctions between verification and validation (V&V) may be less clear. Within the full system lifecycle, SV&V may occur between system requirements specification and system validation. All testing of the software is included under SV&V. That part of system validation that exercises software is also the final step of SV&V. Final system validation is not included as part of this study because the scope of the documents under examination does not cover this step.

There are two standards which together have comprehensive requirements for SV&V. These are ANS104 and FIPS132, which references IEEE1012. The criteria in the template provide a brief summary of those standards' requirements.

The criteria for SQA are derived from IEEE7301. This standard relies heavily on the existence of project documentation. SQA is the planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements. The thrust of SQA is product assurance. A theme which began to develop in the late 1980's is that of process: process assurance, process improvement, quality of the process related to quality of the product. Some evolving standards are beginning to cite process rather than either phase or product for discussions on quality. The new set of SQA activities focuses on evaluating the processes by which products are developed or manufactured. This study reviews SQA activities primarily relative to product.

Because IEEE7301 requires an SCM plan (SCMP), this report notes whether IEEE7301 or a similar standard is cited in the documents. Another consideration was whether requirements for SCM were included as part of SQA. The inclusion is neither a negative nor positive attribute, but rather provides information about how complete the requirements of the document are for SCM.

SCM is the discipline of identifying and documenting characteristics of items in software development and maintenance, to baselining the items, and controlling changes to them. Typical activities consist of configuration identification, configuration control, configuration status control, and configuration audit. The criteria for SCM are taken from IEEE828. This standard is presently serving as a base document for an ISO/IEC JTC1 SC7 (Software Engineering) working group for developing a standard on SCM. Requirements for SCM should be included or referenced in a document for high integrity software.

Broad-based system documents may treat CM only at the system level. Software used in safety systems for nuclear power plants is often only one of many components comprising the total system, and, at the system level, software CM may not be adequately provided for. Hence, the treatment of SCM during software development, before system integration, was examined carefully.

A pre-requisite for any critical system is an analysis of the hazards or threats that the system must protect against. For example, a power plant safety shutdown system must continue to function even during a power failure. While the study was mostly concerned with hazard analyses applied to software, it should be noted that software hazard analysis (e.g., software fault tree analysis (FTA)) is an integral part of system hazard analysis, and both should be conducted in order to assure that all hazards have been identified. Both types of hazard analysis are essential in designing a system for fail-safe operation (e.g., protection against division by zero). In response to a software hazard analysis, some software requirements, software design features, or software code may be changed.

Well-defined project management procedures are as important for the development of high integrity software as they are for any quality product. The documents reviewed are broad in scope and should contain some requirements for how the development of software will be planned, managed, and monitored. Criteria in the template are derived partially from IEEE1058.

Some evolving standards are addressing concerns of the customer. For example, the customer of a system may have some concerns about the people building and evaluating the software. Are they capable? Should evaluators be independent of the vendor? What should their training plans look like? Do the companies have a quality management policy? Some standards also address assessment of qualifications of the vendor and vendor plans for remaining qualified. Another procurement issue involves the use of automated support to build and verify the system and the use of pre-existing software in the software system; the issue is whether this software should be at the same level of assurance as the system. Some standards may include clauses that identify what conformance to the standard means; this is also a procurement concern. Any topics included in the documents that affect the customer at contract are discussed in this section of the template.

One of the major problems with using a standard and verifying compliance with it is that all too often the "requirements" of the standard are not specified in a non-ambiguous, orderly manner. While rewriting a document, or reporting on every ambiguous statement was beyond the scope of this study, some examples of poorly-formulated statements were stated. In many cases, different categories of requirements were specified in documentation requirements. For example, required software functionality against hazards and required software engineering practices for a process should be stated separately rather than in the documentation requirements for a specific process (e.g., design).

Properties of a document that are not covered anywhere else on the template are described in this section. For example, the template does not provide criteria specifically for maintenance. Requirements of documents addressing maintenance are described in this part of the template.

This section contains an overall analysis, based on the two sets of principal questions. The first set deals with reasonable assurance, not absolute assurance, and certainly judgment is subjective. The answer to the second set relies heavily on the findings in the Presentation section.

This section compares the documents for each major evaluation category, while Appendix B describes documents individually. The degree to which documents address each category varies widely. Some of the documents were draft documents at the time of evaluation. The purpose of including these documents is to identify the current thinking of the experts concerning standards for assurance of high integrity systems, especially software systems for the nuclear industry. The comparison of all the documents can assist in identifying proven requirements of standards, new requirements to be added, and organization and presentation format that will make standards easier to use, and easier for auditors to show compliance.

Among the documents reviewed for this report, most address levels of criticality, but in different ways. Canadian documents DLP880 and SOFTENG do not address levels at all. DLP880 implicitly assumes it is addressing critical software, and SOFTENG is for safety-critical systems (highest level of requirements). However, the purpose of the third Canadian document, CATEGORY, is to provide guidance on classifying software according to the consequences of failure but it does not associate software engineering practices with those categories.

IEC880 makes no distinctions concerning assurance needs in the main sections of the document. While Appendix B identifies recommendations for design and programming practices by three levels of priority or importance, no guidance is given on a definition of priority or importance. One would expect that because one purpose of IECSUPP is to clarify and supplement IEC880, IECSUPP would address priority. IECSUPP does this only in specifying diversity requirements, depending on reliability requirements. Even ANS7432 neglects to address levels of assurance, but it does require that the tools used for verification must have SQA measures on them commensurate with their importance to the verification process.

EWICS2-1 states that the design constraints should be associated with the level of criticality. In EWICS2-2, seven levels of criticality are related to types of systems and values for attributes like unavailability and failure probability.

RTCA178A discusses three levels of criticality, and the levels must be addressed in the certification plan for the software. RTCA178A is currently undergoing revision; the current draft defines five levels of criticality and provides guidance for determining the level of a system.

There is some disagreement within the software engineering community with respect to levels of assurance and the requirements that are appropriate for each level. Two questions must be resolved: How many levels of assurance should the standard provide? What activities are needed at each level? The levels of assurance specified in computer security standards are the result of concerns that are unique to security, so there is no reason to use the same divisions for a nuclear safety standard.

There are at least two other efforts addressing criticality assessment and levels of assurance. One is the High Integrity Software project at NIST, and the other is the working group for the revision of IEEE1012. A recommendation from the Workshop on High Integrity Software held at NIST on January 22-23, 1991, is that criticality assessment should be based on four levels. The IEEE1012 working group discussions are leaning toward five levels. In both efforts, the intention is to assign engineering and assurance practices according to the level of criticality.

NIST recognizes the difficulty of assigning software engineering practices and assurance techniques to lifecycle processes based on levels of criticality. However, NIST recommends that this should be accomplished. For at least the highest level of criticality, requirements are already well-defined in several standards and guidelines; these requirements need to be stated in one document. The primary difficulty comes from the refinement of the activities, that is, eliminating or changing them for the middle levels. Different levels will cost developers and assurers overhead in establishing and managing their practices at different levels. There will also be cost involved in the training of staff and the performance of activities at different levels. There will be cost also for auditors to understand the different levels. For other evaluation methods, accredited laboratories will need to establish methods for each of the levels. It is important for standards makers to be able to demonstrate that requirements at four or five different levels are significant and sufficient to satisfy the criticality needs of the product at a given level.

The trend today is to discuss lifecycle not so much by phase, but by processes necessary to produce assured software. While phases are identified in this report, whether a document has requirements for necessary processes, including those for assurance, was also considered.

Some documents are special purpose documents and address those parts of the lifecycle phases that they affect. For example, the categorization document, CATEGORY, is concerned with procedures and guidelines for categorizing software; the categorization is assigned at the initiation of a project. EWICS2-1 provides guidelines for the design of safety critical systems and does not provide guidance on other lifecycle issues. The primary concern in EWICS2-1 is the process of design at the system level with some guidance on software considerations.

Some of the documents deal strictly with requirements for the software lifecycle (e.g., IEC880, IECSUPP, SOFTENG, and RTCA178A). However, they do place the software phases in context with system phases. DLP880 and ANS7432 also address system requirements and integration of hardware and software. The EWICS documents are concerned at the system level, with some specific references to software. In almost all of these documents, there is often confusion as to whether system or software is the focus of activity.

For safety systems in nuclear power plants in which software is embedded and must always be related to the system, the following issues on lifecycle are especially important:

No single document provides sufficient requirements for the first two questions. The combination of the documents provides coverage, at least minimally, in the lifecycle processes. While IEC880, in spite of its problems with presentation, comes close, it does not address project management. Other documents do a better job in other areas (e.g., NPR6300 on reuse and corrective action). While ANS7432 does address the software-system relationship, overall its requirements for software for all lifecycle processes are either minimal or nonexistent. If taken as a whole, the EWICS documents address (system) design and maintenance, but provide little guidance on other aspects of the software lifecycle processes. However, EWICS2-4 and SOFTENG are the only two documents which address quality attributes and measures. With respect to maintenance, IEC880 and EWICS2-5 provide more guidance than the other documents.

RTCA178A provides rather generic requirements for most lifecycle processes. It is currently under revision; the revision will probably be oriented more toward processes, not phases, and may contain rigorous requirements.

The combination of the best features of the documents reviewed may provide reasonable coverage for lifecycle processes.

None of the documents specifically address documentation. Their requirements for documentation range from a simple statement for each type of document to a complete description of the quality attributes of a document. ANS7432 falls into the terse category (e.g., completeness, consistency, and documentation standards are implied). The most complex set of documentation requirements are in DLP880 where documentation is to be written in formal specification languages.

Only one document, SOFTENG, provides rigorous guidance on the quality attributes that should be inherent in documentation. For each document, criteria are identified for each required quality attribute.

One of the features of several documents, especially IEC880 and SOFTENG, is that documentation requirements included requirements for the software itself. For example, designing modules with a single well-defined function is a software engineering practice that designers apply through their thinking processes to structure the system for the best possible design for the system's operational capability and assurance. The primary purpose of implementing this practice is not documentation. In other cases, functional requirements were hidden in documentation requirements. It is recommended that standards make the distinction between documentation requirements and requirements for software engineering practices and software functionality against hazards. The documentation requirement may be that the software engineering practices should be documented separately, for example, MOD0055's requirements for a "Code of Design Practices."

In most of the reviewed documents, separate documentation is specified for each lifecycle phase or process. An exception is RTCA178A which treats the software development and verification plan as one document.

Several documents contained checklists of varying degrees of clarity and completeness. This is a positive feature.

IEC880 and EWICS2-3 included lists of functions that can be used to counter specific hazards. Of these two, the questionnaire in EWICS2-3 is the more comprehensive. IEC880 contains annotations indicating what each function is "good for" and "good against," but these are generally obvious, so the annotations provide little useful guidance. For example, the annotation for retry procedures indicates that retries are useful against sporadic hardware faults, and range checking of variables is said to help guard against "yet undetected errors."

The inclusion of checklists of functions to guard against hazards is helpful in a standard, but it is probably not appropriate to mandate specific functions when a standard covers a broad category of systems. Some functionality that is considered essential for all nuclear safety systems (e.g., range checking) might be required, but, in general, some functions may not be appropriate for all systems. This is consistent with standards for high integrity systems supporting security. Standards for general purpose secure systems have less prescribed functionality than those for a more narrow range of applications, such as data encryption. It may be beneficial to consider supplemental standards for special purpose systems.

Software engineering practices are either those techniques recommended or required to prevent errors from being entered into the system during construction, or are properties to be built into the system for high integrity. An example of the first type is the use of formal specification languages, and an example of the second type is the use of modularity.

The documents reviewed vary enormously in their recommendations regarding software engineering practices. Most contain at least some guidance on good practices. The only two documents which do not cite any software engineering practices are RTCA178A and NPR6300. There is little agreement on the practices that are mentioned. While EWICS2-4 and EWICS2-5 do not address software engineering practices, the other EWICS documents provide comprehensive coverage and address software engineering practices. Summaries of the more significant software engineering practices are given below approximately in order of consensus among the documents.

Modularity and critical component isolation - The software engineering practices cited by most of the documents are the use of modularity in design and the isolation of critical components. In this regard, the documents are consistent with current thinking in the software engineering community and with other standards for critical software.

Programming Language - Several documents state principles for programming languages. The consensus in this area is for use of high-level languages (e.g., C, Fortran, Ada) rather than assembler, and for languages that support automatic checking of data types and function arguments. For example, Ada or C++ will warn if a function is called with an integer argument when it is expecting a character string. Here again, the documents are consistent with current thinking in the software engineering community and with other standards for critical software. Another programming consideration is the use of structured programming (the use of restricted control structures rather than arbitrary branching). Structured programming is now nearly universally accepted as good practice. The documents reviewed reflect this acceptance.

Formal methods - Over the past decade, there has been increasing interest in the use of formal methods for complex software. Formal methods refers to the use of mathematical logic and related areas of mathematics to specify and model the behavior of software. Formal methods are required by only one of the documents reviewed (DLP880). Another, the supplement to IEC880 (IECSUPP), says that "formal methods should be considered for the highest requirement of safety importance." EWICS2-3 gives preference to the use of formal specifications over informal ones, but does not require the use of formal methods. IEC880 notes only that "a formal specification language may be a help to show coherence and completeness of the software functional requirements." A trend toward greater reliance on formal methods is evident in the documents reviewed. DLP880 and IECSUPP were 1991 drafts; EWICS2-3 was written in 1989, and IEC880 in 1986. In the area of formal methods, the nuclear documents reviewed lag behind other standards for critical software. In the fields of computer security and data communications, formal methods have become accepted practice, and are required at the higher levels of all significant security standards and by MOD0055.

Documentation of software engineering practices - A mechanism frequently used is to define documentation as a description of a lifecycle process. For example, in IEC880 and SOFTENG, documentation for a software requirements specification often specifies the principles or functions the system must embody, or in the case of SQA, the activities to be performed. Software engineering practices are hidden in documentation requirements. Those practices are discussed in this report in Section 3.3. Taken together, the documents reviewed gave adequate treatment to most aspects of software engineering practices, except in the area of formal methods. (This statement reflects the documents in general. As noted, there was much variation.)

Quality attributes - Only SOFTENG and EWICS2-4 provided either specific requirements or measures for quality attributes like completeness, consistency, and maintainability.

In the nuclear power industry, as in many other industries, software is one component of a company's business, and of a power plant. At the top management level, the view is of the whole, not a part. Therefore, system CM and system validation are the engineering concepts that make sense to executives of manufacturing companies. For software companies, executives think in terms of software CM and software validation. The difference is non-trivial and has caused much misunderstanding in the development of standards. Software is deeply embedded in systems where software cannot fully stand alone, yet some other components of these systems are not only plug-in but are built to precise, accredited standards. CM and testing of these components during their development is an expected activity. Software should be treated similarly. For testing this has not been always possible. For one thing, software systems have been unique for each system in which they will be embedded. There is no precise set of validated specifications. Second, their full functionality usually can only be simulated and cannot be tested in real-time during software development.

The purpose of this study was to discover how well the documents provide assurance of the software and how well the software will fulfill its system responsibilities. Few of the documents reviewed focused entirely on software. There was a lot of second-guessing whether system level requirements were applied at the software development level or only at the point when software was integrated with the system. If the requirements are unclear, how can auditors check for exact compliance? If accredited, precise standards for software existed, as they do for other components (e.g., pipes, power cables), then this review would have been simpler. This study reemphasized the growing recognition that the software industry must identify some precise standards for software that permit measurement of its quality.

For the assurance activities, P1228 focuses on safety issues and requires specific assurance activities in all the categories of Section 3.5 of this report. Under P1228, all documentation for assurance activities may serve as special sections of plans for those activities (e.g., safety requirements for the SV&V plan (SVVP), safety requirements for the SQA plan (SQAP), for the SCMP). The assumption of the P1228 draft is that the other IEEE Software Engineering Standards, or similar standards, will be used. For computer security planning, which may be important to the nuclear industry as dependency grows on large databases and distributed computing, perhaps the documentation requirements of P1228 can be adapted for computer security.

The difference between system and software viewpoints stands out in the documents reviewed for this study. For example, ANS7432 is concerned with computer system validation and not particularly concerned with software issues. Software verification is the software testing; in the software world, this can be confusing. Part of the rationale for not treating SV&V as separate functions in IEEE1012 is to avoid this confusion. The final step of SV&V is the system validation, as in system standards; SV&V consists of these activities applied as the software evolves to assure the internal properties of the software and the external relationships to the system.

DLP880 refers to software verification but is in reality SV&V. One caution with DLP880 is the assumption that the vendor may produce the verification plan which is then implemented by an independent team. One should not think this is the only meaning of IV&V, because the fullest possible benefit of independence is the independent planning process in which the IV&V brings a different perspective to the types of analysis and test strategies.

Two documents, EWICS2-1 and P1228, focus on the safety requirements; this is acceptable since these documents are intended to augment other more general standards and the intent is to ensure attention to the safety functions. EWICS2-3 should be used by verifiers to guide them in checking features of the software, and auditors to check how well the developers and verifiers have followed guidelines.

IEC880 specifically addresses software verification, and is reasonably thorough. There are weaknesses, however. The major weakness is that of presentation; a reader has to search several places before finding all the requirements for a given process, in this instance, verification. Technical weaknesses include a lack of specific requirements for requirements traceability.

Some documents recommend several test strategies and test conditions (e.g., stress test, logic test, boundary test) but the selections are not the same in all the documents. For example, IEC880 has long lists of strategies and conditions but omits stress testing, while SOFTENG includes stress testing. Error analysis should be a requirement in all SV&V or SQA standards or sections of standards addressing SV&V or SQA. Error analysis is important for uncovering a type of error (e.g., misunderstanding of trigonometry) that could appear elsewhere in the system. When the type of error is made because of a misunderstanding or a wrong specification, it is important to check other places in the program that are based on the same assumptions, especially if the same person is responsible. Otherwise, a potentially critical error could slip through.

While RTCA178A provides the most detailed and best organized set of requirements for software verification (including validation), the software verification assurance matrix is too high-level to be truly useful for auditors.

From the review of these documents, including the base documents IEEE1012 and ANS104, recommendations for improving standards for SV&V include

o practices based on levels of criticality

o distinctive requirements for different test types

o detailed checklists

As a general comment, NRC should note that these documents are concerned strictly with SQA of the product, not the vendor processes. Current and evolving SQA standards are addressing process as well as product. When NRC audits a particular product, will NRC be concerned about whether a vendor has changed processes mid-stream, or for the next product? Probably not. For a current audit, NRC will likely be interested in whether a given product has the required quality level. But, when new SQA standards are written, what happens if they require activities for both process and product? NRC needs to study this question to determine if process quality is outside the scope of their requirements.

Several documents addressed SQA in a general manner. For example, ANS7432 requires that SQA be addressed in the software development plan (SDP). IEC880 simply requires an SQAP. This is not sufficient because it will not be clear what is required of the vendors. For audit and review purposes, NRC must know the following:

Some documents permit national standards to be used. NRC would need to ensure specification of an SQA standard or expect their auditor to know every SQA standard quite well.

Design and code inspections can be either SQA or SV&V activities. In addition, requirement for inspections was not consistent in the documents. Both ANS7432 and EWICS2-1 provide detailed procedures for SQA of design and EWICS2-4 addresses SQA entirely.

There is a growing recognition that SQA procedures are needed for existing software programs and for reuse of software modules. NPR6300 provides detailed guidance and it appears that IECSUPP will address the topic also.

The SQA sections of the documents, like those for SV&V, are in general weak concerning anomaly reporting, corrective action and follow-up, and error analysis.

Software CM is another process that sometimes is addressed only at the system level. While the size of software systems used in safety systems for nuclear power plants may be small, the critical role of software for safety mandates that SCM be required for all the lifecycle processes and products of such software. IEC880's requirement for system CM is insufficient. ANS7432 and EWICS2-3 simply ignore the topic. Several documents, DLP880, SOFTENG, RTCA178A, and NPR6300, require SCM activities with varying degrees of rigor. The international community (ISO/IEC JTC1 SC7) is presently using IEEE828 as a base document for producing an international standard on SCM. When the international standard is published, NRC and the standards community in general may consider simply citing this SCM standard directly.

Typically the initial hazard analysis is performed from a total system, environmental perspective and the results may affect the system requirements and design. From the software perspective, the results of that analysis should be an input to the software assurance activities. By examining these results, the software experts identify what potential hazards have an impact on the software, or may be mitigated or prevented by software. For the same reason, results of other system hazard analyses should be required inputs to software assurance activities. Additionally, hazard analyses specific to software should be conducted. There is some debate over whether the software hazard analyses and related analyses should be considered development or assurance activities. The recommendation here is that the perspective of software assurance may lend itself somewhat better to conducting software hazard analyses and using system hazard analyses to check the safety impact of the software.

While many of the documents of the study addressed system hazard analysis, it was quite difficult to determine if the hazard analysis was conducted on software features. When the hazard analysis report was strictly system, its report was not usually required as an input to any software development or assurance activities.

Two documents specifically addressed software safety analysis. P1228 requires the results of the preliminary system hazard analysis and requires additional software safety analyses throughout the lifecycle. SOFTENG requires a code hazard analysis and a report with ten requirements. Examples of items that must be identified in the report include input conditions which could lead to the software causing an unsafe state, failure modes related to instructions in code which could lead to an unsafe subsystem failure, and code modifications which would eliminate the identified failure modes.

Most of the documents in this study either do not address project management activities or do so indirectly through other governing principles. For example, requirements on planning for SQA and SCM may be considered requirements for project planning. SOFTENG includes requirements for project management in requirements for the SDP. EWICS2-4 addresses project management through acceptance criteria. The P1228 draft expects a project management plan, and requires that the plan be augmented to address software safety issues.

One concern that NRC has is whether or not assurance activities should be performed by independent teams. ANS7432 uses a non-binding statement in the foreword to recommend independence and requires independence of the verification group at the system level. Others, like DLP880 and IEC880, recommend that verification plans be written so that an independent team may implement the plan. IECSUPP suggests complete separation of development and verification teams. EWICS2-1 and EWICS2-2 ask for an IV&V assessment. P1228 also recommends IV&V. SOFTENG asks for independence between development and verification; management of the developers is different from managers of the verifiers (but does not require a separate organization). These recommendations present another problem; nowhere is there a standard definition of independence and of the tasks of IV&V. A non-exclusive list of possible meanings of IV&V duties includes the following:

Additionally, can the "independent" team be simply another department within a vendor's organization? What conditions make the team "independent?" Unless the document clearly specifies a definition of IV&V, requirements for IV&V are ambiguous.

Most of the documents do not specify contractor capability assessment although the EWICS documents do ask for compliance with ISO9000 which requires assessment of contractor's quality system. P1228 requires the software safety plan (SSP) to specify qualifications for the personnel performing software safety activities.

The permission to tailor a standard to a project may present two problems. One, the tailored version may not produce a satisfactory assurance of the product. Two, an auditor may have difficulty assessing compliance. SOFTENG has a statement that all requirements of the standard must be met for compliance.

For an auditor to verify vendor compliance to a standard, it is helpful to have a statement of conformance within the standard. Only two of the reviewed documents have firm conformance clauses. SOFTENG states that conformance means all its requirements must be met. Of the five separate chapters in EWICS2, all except one have strong conformance clauses that list specific requirements. For example, EWICS2-1 requires written procedures that identify the existence of activities corresponding to each and every step of the guideline. EWICS2-3 consists of a questionnaire; a conformance clause is inappropriate.

Several of the documents suggest that the use of pre-existing software in a product falls under the requirements of a document. Some also require the same level of assurance for automated development or assurance tools. For example, P1228 states that pre-existing software must be in compliance with P1228 and the verification of support tools depends on the level of assurance of the system. While IEC880 has requirements on the use of operating systems, it does not require that automatic development and verification aids be tested.

The documents reviewed have a variety of problems with their presentation. The major problem lies with usage of words to indicate requirements: "shall," "should," "must," "may." When the words "shall" and "should" appear in the same paragraph, it can be confusing to vendors, assurers, customers, and auditors. Requirements and recommendations need to be clearly distinctive from one another. Ambiguous statements in several documents (e.g., "the software must be easy to test" [IEC880]) are meaningless. An example of language that does impose meaningful constraints on qualities may be found in SOFTENG.

Another concern is that features required to be present in the software, development practices, and descriptions of the software are often specified in documentation. It is recommended that standards keep separate different categories of requirements.

The Supplemental Information section for each document (see Sections B.x.10 of this report) contains information about the documents that was not covered by the template categories. The important findings are that only two documents (IEC880, EWICS2-5) address software maintenance in detail and only NPR6300 addresses problem reporting and corrective action in detail.

In general, no standard can guarantee the safety of a particular software system. In other words, no one can ever say "If a vendor follows this standard, the system will be safe." The judgement of safety for a particular installation must be made by the appropriate authorities. Ideally, standards should state what is required for evaluating the safety of a system, and to determine if the software complies with the standard. That is, "These are the things a vendor must do to enable NRC to judge whether the system is safe enough to not pose an undue risk to public health and safety."

No single standard or guideline reviewed completely satisfies the evaluation criteria, and there is relatively little consensus among the documents. None of the documents positively answered the first set of principal questions "Do the requirements of the document provide assurance of the nuclear safety system software developed, maintained, and operated according to these requirements? That is, does the document contain requirements for building verifiably dependable nuclear safety system software?" However, most of the documents satisfy at least one category of criteria.

The documents reviewed have several common problems. It is unclear whether the system or software is the focus of the activities. There is a lack of system information provided to the software. Process requirements are specified under documentation requirements. Specification of required software functionality against hazards is usually insufficient. And, in general, conformance to most of the documents would be difficult to demonstrate.

The scope of a standard must be clearly identified relative to system and software lifecycles. The requirements for software must ensure that the software is always assured relative to its relationship to the system. Documentation requirements should be limited to what should be included in the document and how this content should be presented. Requirements for software engineering practices and software functionality against hazards (what should be done) should be listed separately. The functions listed in Appendix A are not all essential to all systems, however, standards should provide guidance on what functions are necessary for specific types of systems.

It is important to develop a standard with rigorous requirements for documentation, required software functionality against hazards, software engineering practices, SV&V, SQA, SCM, software hazard analysis, and project management. It is acceptable to cite specific standards to provide requirements for any of the categories (e.g., IEEE1012 or ANS104 for SV&V). In fact, a standard that is self-contained or has reference to specific standards helps to prevent omissions and conflicts among standards. Software engineering practices and assurance techniques should be assigned based on levels of criticality/assurance. The activities for each level may all be defined within one standard, or different standards may be developed for each level of criticality/assurance.

The language of a standard must be non-ambiguous. Requirements should be clearly stated and contained within the body of the standard (e.g., not in appendices). Until software engineering practice is rigorously codified in handbooks as in other engineering fields, standards for the assurance of high integrity software should describe all practices or cite acceptable standards for them, which encompass at least the criteria in Appendix A.

There was some consensus among the documents on certain software engineering practices including the use of modularity and critical component isolation, high level programming languages, formal methods, documentation of software engineering practices, and quality attributes. But, in general, the guidance is enormously varied.

Frequently, the documents did not distinguish between documentation requirements and those for software engineering practices and software functionality against hazards. This distinction should be made in the documents. Besides the benefit of vendors' improved understanding of their requirements, the distinction should facilitate the task of verifying compliance with a standard.

Procurement issues such as independent evaluations, contractor capability assessments, pre-existing software and support software should be addressed in standards. At a minimum, a standard definition of independent organization should be developed. While such a definition may have variants, a standard for high integrity software can cite the required variant of independence. The customer is also interested in whether the system has built in conformance with the standard. To verify vendor compliance to a standard, it is helpful to have a statement of conformance within the standard.

It is recommended that NRC considerations of consensus standards, draft standards, and guidelines include the concerns identified in this report. While information from all of the documents can be used in developing a rigorous standard, other concerns must be addressed. For example, the scope of the standard within system and software lifecycles must be clearly identified. The standard should require that software is always assured in the context of the particular system under evaluation. Guidance for assurance of high integrity software should either describe all practices or cite acceptable standards for them, encompassing at least the criteria in Appendix A.

ANS7432

ANS41

ANS104

ASMENQA1

ASMENQA2

CATEGORY

DLP880

EWICS2-1

EWICS2-2

EWICS2-3

EWICS2-4

EWICS2-5

EWICS3

FIPS101

FIPS132

FIPS1401

IEC880

IECSUPP

IEEE603

IEEE828

IEEE830

IEEE983

IEEE1012

IEEE1016

IEEE1042

IEEE1058

IEEE1074

IEEE7301

ISO9000

ITSEC

MOD0055