[Federal Register Volume 67, Number 196 (Wednesday, October 9, 2002)]
[Notices]
[Pages 62960-62961]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 02-25488]
=======================================================================
-----------------------------------------------------------------------
DEFENSE NUCLEAR FACILITIES SAFETY BOARD
[Recommendation 2002-1]
Quality Assurance for Safety-Related Software
AGENCY: Defense Nuclear Facilities Safety Board.
ACTION: Notice, recommendation.
-----------------------------------------------------------------------
SUMMARY: The Defense Nuclear Facilities Safety Board has made a
recommendation to the Secretary of Energy pursuant to 42 U.S.C.
2286a(a)(5) concerning quality assurance for safety-related software.
DATES: Comments, data, views, or arguments concerning this
recommendation are due on or before November 8, 2002.
ADDRESSES: Send comments, data, views, or arguments concerning this
recommendation to: Defense Nuclear Facilities Safety Board, 625 Indiana
Avenue, NW., Suite 700, Washington, DC 20004-2901.
FOR FURTHER INFORMATION CONTACT: Kenneth M. Pusateri or Andrew L.
Thibadeau at the address above or telephone (202) 694-7000.
Dated: October 1, 2002.
John T. Conway,
Chairman.
September 23, 2002.
Background
Two core Integrated Safety Management (ISM) functions evolving from
the Department of Energy's (DOE) implementation of Defense Nuclear
Facilities Safety Board (Board) Recommendation 95-2, Safety Management
are: (1) Analyzing hazards; and (2) identifying and implementing
controls to prevent and/or mitigate potential accidents. DOE relies
heavily on computer software to analyze hazards, and design and operate
controls that prevent or mitigate potential accidents.
DOE and its contractors use many codes to evaluate the consequences
of potential accidents. Safety controls and their functional
classifications are often based on these evaluations. Functional
classifications establish the level of rigor to which controls are
designed, procured, maintained, and inspected. The robustness and
reliability of many structures, systems, and components (SSCs)
throughout DOE's defense nuclear complex depend on the quality of the
software used to analyze and to guide these decisions, the quality of
the software used to design or develop controls, and proficiency in use
of the software. In addition, software that performs safety-related
functions in distributed control systems, supervisory control and data
acquisition systems (SCADA), and programmable logic controllers (PLC)
requires the same high quality needed to provide adequate protection
for the public, the workers, and the environment. Other types of
software, such as databases used in safety management activities, can
also serve important safety functions and deserve a degree of quality
assurance commensurate with their safety significance.
In some areas where there is at present no substantial activity in
development of new software for safety applications, new calculations
are usually based on existing codes, with data inputs and some logic
chains often modified to fit the problems of the moment. It is
therefore necessary to ensure that software so modified is not placed
in general use in competition with generally validated and more widely
useable software.
Software quality assurance (SQA) provides measures designed to
ensure that computer software will perform its intended functions. Such
measures must be applied during the design, testing, documentation, and
subsequent use of the software, and must be maintained throughout the
software life cycle. It is generally accepted that an effective SQA
program ensures that:
[sbull] All requirements, including the safety requirements, are
properly specified.
[sbull] Models are a valid representation of the physical phenomena
of interest, and digital control functions are properly executed.
[sbull] Input and embedded data are accurate.
[sbull] Software undergoes an appropriate verification and
validation process.
[sbull] Results are in reasonable agreement with available
benchmark data.
[sbull] All internal logic states of PLCs and SCADA are understood,
so that no sequence of inputs, even those due to component failure, can
leave the controlled system in an unexpected or unanalyzed state.
[sbull] Computer codes are properly and consistently executed by
analysts.
[sbull] Code modifications and improvements are controlled,
subjected to regression and re-acceptance testing, and documented.
DOE identified inadequate SQA as a problem as early as December
1989, when its Office of Environment, Safety and Health (DOE-EH) issued
ENVIRONMENT, SAFETY & HEALTH BULLETIN EH-89-9, Technical Software
Quality Assurance Issues. This bulletin states, ``Inadequate SQA for
scientific and technical codes at any phase in their ``life cycle'' may
not only result in lost time and/or excessive project costs, but may
also endanger equipment and public or occupational sectors.'' The
bulletin cites problems with all three types of software noted above
(analysis, design, and operation). Likewise, a 1997 assessment
performed by DOE's Accident Phenomenology and Consequence Assessment
Methodology Evaluation Program determined that only a small fraction of
accident analysis computer codes meet current industry SQA standards.
SQA problems continue to persist, as documented in the Board's
technical report DNFSB/TECH-25, Quality Assurance for Safety-Related
Software at Department of Energy Defense Nuclear Facilities, issued in
January 2000.
An integrated and effective SQA infrastructure still does not exist
within DOE. This situation can lead to both errors in technical output
from software used in safety analyses and incorrect performance of
instrumentation and controls for safety-related systems. In a letter to
DOE dated January 20, 2000, the Board identified these deficiencies and
requested that DOE provide a corrective action plan within 60 days. On
October 3, 2000, the Board received DOE's corrective action plan, but
found that it did not sufficiently respond to the Board's concerns. On
October 23, 2000, the Board asked for a new plan of action; DOE has
never submitted a revised plan, although several deliverables under the
original plan have been received.
During the Board's August 15, 2001, public meeting on quality
assurance,
[[Page 62961]]
DOE proposed a revised set of actions to improve SQA processes and
practices. Since then, DOE has attempted to develop a Quality Assurance
Improvement Plan that includes SQA as a key goal. This action now
appears stalled as a result of internal differences over objectives and
funding. Thus, despite well over two years of effort, DOE has failed to
develop and implement effective corrective actions in response to the
Board's reporting requirement.
This situation is not acceptable. To improve SQA in the DOE
complex, the Board recommends prompt actions to achieve the following:
Responsibility and Authority
1. Define responsibility and authority for the following:
developing SQA guidance, conducting oversight of the development and
use of software important to safety, and directing research and
development as noted below. Roles and responsibilities should address
all software important to safety, including, at a minimum, design
software, instrumentation and control software, software for analysis
of consequences of potential accidents, and other types of software,
such as databases used for safety management functions.
2. Assign those responsibilities and authorities to offices/
individuals with the necessary technical expertise.
Recommended Computer Codes for Safety Analysis and Design
3. Identify software that would be recommended for use in
performing design and analyses of SSCs important to safety, and for
analysis of expected consequences of potential accidents.
4. Identify an organization responsible for management of each of
these software tools, including SQA, technical support, configuration
management, training, notification to users of problems and fixes, and
other official stewardship functions.
Proposed Changes to the Directives System
5. Establish requirements and guidance in the DOE directives system
for a rigorous SQA process, including specific guidance on the
following: grading of requirements according to safety significance and
complexity; performance of safety reviews, including failure analysis
and fault tolerance; performance of verification and validation
testing; and training to ensure proficiency of users.
Research and Development
6. Identify evolving areas in software development in which
additional research and development is needed to ensure software
quality.
Appendix--Transmittal Letter to the Secretary of Energy Defense Nuclear
Facilities Safety Board
September 23, 2002.
The Honorable Spencer Abraham, Secretary of Energy, 1000
Independence Avenue, SW., Washington, DC 20585-1000.
Dear Secretary Abraham: The Defense Nuclear Facilities Safety Board
(Board) has been following closely the Department of Energy's (DOE)
response to a reporting requirement dated January 20, 2000, which
requested a corrective action plan to address deficiencies
documented in the Board's technical report DNFSB/TECH-25, Quality
Assurance for Safety-Related Software at Department of Energy
Defense Nuclear Facilities. Although more than two years have since
elapsed, DOE has been unable to develop and execute an acceptable
plan to resolve these issues, some of which were identified as early
as 1989. Since the Board's August 15, 2001, public meeting on
quality assurance, DOE has been developing an overall Quality
Assurance Improvement Plan that includes software quality assurance
as a key element, but this effort has not yet produced any
substantial results.
As a result, the Board on September 23, 2002, unanimously
approved Recommendation 2002-1, Quality Assurance for Safety-Related
Software, which is enclosed for your consideration. After your
receipt of this recommendation and as required by 42 U.S.C.
2286d(a), the Board will promptly make it available for access by
the public in DOE's regional public reading rooms. The Board
believes that the recommendation contains no information that is
classified or otherwise restricted. To the extent this
recommendation does not include information restricted by DOE under
the Atomic Energy Act of 1954, 42 U.S.C. 2161-68, as amended, please
see that it is promptly placed on file in your regional public
reading rooms. The Board will also publish this recommendation in
the Federal Register.
Sincerely,
John T. Conway,
Chairman.
[FR Doc. 02-25488 Filed 10-8-02; 8:45 am]
BILLING CODE 3670-01-P