skip to main content
OSTI.GOV title logo U.S. Department of Energy
Office of Scientific and Technical Information

Title: A ''Toolbox''21 Equivalent Process for Safety Analysis Software

Abstract

Defense Nuclear Facilities Safety Board (DNFSB) Recommendation 2002-1 (Quality Assurance for Safety-Related Software) identified a number of quality assurance issues on the use of software in Department of Energy (DOE) facilities for analyzing hazards, and designing and operating controls that prevent or mitigate potential accidents. The development and maintenance of a collection, or ''toolbox,'' of multiple-site use, standard solution, Software Quality Assurance (SQA)-compliant safety software is one of the major improvements identified in the associated DOE Implementation Plan (IP). The DOE safety analysis toolbox will contain a set of appropriately quality-assured, configuration-controlled, safety analysis codes, recognized for DOE-broad, safety basis applications. Currently, six widely applied safety analysis computer codes have been designated for toolbox consideration. While the toolbox concept considerably reduces SQA burdens among DOE users of these codes, many users of unique, single-purpose, or single-site software may still have sufficient technical justification to continue use of their computer code of choice, but are thwarted by the multiple-site condition on toolbox candidate software. The process discussed here provides a roadmap for an equivalency argument, i.e., establishing satisfactory SQA credentials for single-site software that can be deemed ''toolbox-equivalent''. The process is based on the model established to meet IP Commitment 4.2.1.2:more » Establish SQA criteria for the safety analysis ''toolbox'' codes. Implementing criteria that establish the set of prescriptive SQA requirements are based on implementation plan/procedures from the Savannah River Site, also incorporating aspects of those from the Waste Isolation Pilot Plant (SNL component) and the Yucca Mountain Project. The major requirements are met with evidence of a software quality assurance plan, software requirements and design documentation, user's instructions, test report, a configuration and control procedure, an error notification and corrective action process, and evidence of available training on use of the software. The process is best performed with an independent SQA evaluator, i.e., a technically knowledgeable individual in the application area who is not part of the development team. The process provides a consistent, systematic approach based on the experience gained with SQA evaluations of the toolbox codes. Experience has shown that rarely will existing software be fully compliant with SQA criteria. Instead, the typical case is where SQA elements are deficient. For this case, it is recommended that supplemental remedial documentation be generated. Situations may also arise where the SQA evaluator must weigh whether the entire SQA suite be reconstituted. Regardless, the process is described sufficiently to guide a comprehensive evaluation. If the candidate software is successful in meeting process requirements, the software is ''toolbox-equivalent''. The benefit of the methodology outlined is that it provides a standard evaluation technique for choosing the most applicable software for a given application. One potential outcome is that the software of choice will be found to be applicable with ample SQA justification. Alternatively, the software in question may be found not to meet SQA process requirements. In this case, the analyst may then make an informed decision and possibly select one of the multiple-use, toolbox codes. With either outcome, the DSA is improved.« less

Authors:
Publication Date:
Research Org.:
Savannah River Site (US)
Sponsoring Org.:
US Department of Energy (US)
OSTI Identifier:
823611
Report Number(s):
WSRC-MS-2004-00116
TRN: US0401773
DOE Contract Number:  
AC09-96SR18500
Resource Type:
Conference
Resource Relation:
Conference: EFCOG SAWG Workshop, Conference location not supplied, 05/01/2004--05/06/2004; Other Information: PBD: 30 Apr 2004
Country of Publication:
United States
Language:
English
Subject:
12 MANAGEMENT OF RADIOACTIVE WASTES, AND NON-RADIOACTIVE WASTES FROM NUCLEAR FACILITIES; 11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS; ACCIDENTS; COMPUTER CODES; CONFIGURATION; DOCUMENTATION; EVALUATION; IMPLEMENTATION; MAINTENANCE; NUCLEAR FACILITIES; QUALITY ASSURANCE; SAFETY; SAFETY ANALYSIS; TRAINING; WIPP; YUCCA MOUNTAIN

Citation Formats

O'KULA, KR. A ''Toolbox''21 Equivalent Process for Safety Analysis Software. United States: N. p., 2004. Web.
O'KULA, KR. A ''Toolbox''21 Equivalent Process for Safety Analysis Software. United States.
O'KULA, KR. Fri . "A ''Toolbox''21 Equivalent Process for Safety Analysis Software". United States. https://www.osti.gov/servlets/purl/823611.
@article{osti_823611,
title = {A ''Toolbox''21 Equivalent Process for Safety Analysis Software},
author = {O'KULA, KR},
abstractNote = {Defense Nuclear Facilities Safety Board (DNFSB) Recommendation 2002-1 (Quality Assurance for Safety-Related Software) identified a number of quality assurance issues on the use of software in Department of Energy (DOE) facilities for analyzing hazards, and designing and operating controls that prevent or mitigate potential accidents. The development and maintenance of a collection, or ''toolbox,'' of multiple-site use, standard solution, Software Quality Assurance (SQA)-compliant safety software is one of the major improvements identified in the associated DOE Implementation Plan (IP). The DOE safety analysis toolbox will contain a set of appropriately quality-assured, configuration-controlled, safety analysis codes, recognized for DOE-broad, safety basis applications. Currently, six widely applied safety analysis computer codes have been designated for toolbox consideration. While the toolbox concept considerably reduces SQA burdens among DOE users of these codes, many users of unique, single-purpose, or single-site software may still have sufficient technical justification to continue use of their computer code of choice, but are thwarted by the multiple-site condition on toolbox candidate software. The process discussed here provides a roadmap for an equivalency argument, i.e., establishing satisfactory SQA credentials for single-site software that can be deemed ''toolbox-equivalent''. The process is based on the model established to meet IP Commitment 4.2.1.2: Establish SQA criteria for the safety analysis ''toolbox'' codes. Implementing criteria that establish the set of prescriptive SQA requirements are based on implementation plan/procedures from the Savannah River Site, also incorporating aspects of those from the Waste Isolation Pilot Plant (SNL component) and the Yucca Mountain Project. The major requirements are met with evidence of a software quality assurance plan, software requirements and design documentation, user's instructions, test report, a configuration and control procedure, an error notification and corrective action process, and evidence of available training on use of the software. The process is best performed with an independent SQA evaluator, i.e., a technically knowledgeable individual in the application area who is not part of the development team. The process provides a consistent, systematic approach based on the experience gained with SQA evaluations of the toolbox codes. Experience has shown that rarely will existing software be fully compliant with SQA criteria. Instead, the typical case is where SQA elements are deficient. For this case, it is recommended that supplemental remedial documentation be generated. Situations may also arise where the SQA evaluator must weigh whether the entire SQA suite be reconstituted. Regardless, the process is described sufficiently to guide a comprehensive evaluation. If the candidate software is successful in meeting process requirements, the software is ''toolbox-equivalent''. The benefit of the methodology outlined is that it provides a standard evaluation technique for choosing the most applicable software for a given application. One potential outcome is that the software of choice will be found to be applicable with ample SQA justification. Alternatively, the software in question may be found not to meet SQA process requirements. In this case, the analyst may then make an informed decision and possibly select one of the multiple-use, toolbox codes. With either outcome, the DSA is improved.},
doi = {},
journal = {},
number = ,
volume = ,
place = {United States},
year = {2004},
month = {4}
}

Conference:
Other availability
Please see Document Availability for additional information on obtaining the full-text document. Library patrons may search WorldCat to identify libraries that hold this conference proceeding.

Save / Share: