Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software failures”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

An Approach to Automate tools for the Risk Assessment of Digital Instrumentation and Control Systems

Reliable digital instrumentation and control systems (DI&C) are integral for sustaining the continued operation of nuclear power plants. These systems ensure that nuclear reactors operate safely, efficiently, and within regulatory requirements. Yet, the cost of designing and licensing new nuclear DI&C can be prohibitively expensive. Under the U.S. Department of Energy Light Water Reactor Sustainability Program, Idaho National Laboratory has developed a framework for supporting the risk-informed design of DI&C systems by offering methods to support the identification, quantification, and evaluation of risks for various DI&C design architectures. The framework indicates potential software failure modes and provides pathways for quantifying the potential for these software failures, including common cause failures. Using the framework’s systematic approach, challenges for assessing risks within new and existing nuclear DI&C systems can be reduced. Nevertheless, the current framework can be further improved using the convenience of automation. This paper introduces the development of Software for the Hazard Identification and Evaluation of Digital Systems (SHIELDS). SHIELDS is an engineering software package that enables the identification, elimination, and mitigation of potential risks and reduces the burden of deploying reliable DI&C systems. This work introduces plans and techniques to digitize and improve the manual risk assessment modules of the framework. These improvements will save time and increase the repeatability and usability of the framework, making it more accessible to a wider range of users. Ultimately, this introduces SHIELDS and how its modules support efficient development of safe and reliable DI&C systems.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗
NASA NTRS1988

Software system safety

Software itself is not hazardous, but since software and hardware share common interfaces there is an opportunity for software to create hazards. Further, these software systems are complex, and proven methods for the design, analysis, and measurement of software safety are not yet available. Some past software failures, future NASA software trends, software engineering methods, and tools and techniques for various software safety analyses are reviewed. Recommendations to NASA are made based on this review.

Uber, James G.↗
NASA NTRS1984

Fault-tolerant software for the FIMP

The work reported here provides protection against software failures in the task dispatcher of the FTMP, a particularly critical portion of the system software. Faults in other system modules and application programs can be handled by similar techniques but are not covered in this effort. Goals of the work reported here are: (1) to develop provisions in the software design that will detect and mitigate software failures in the dispatcher portion of the FTMP Executive and, (2) to propose the implementation of specific software reliability measures in other parts of the system. Beyond the specific support to the FTMP project, the work reported here represents a considerable advance in the practical application of the recovery block methodology for fault tolerant software design.

Hecht, H.↗
DOE OSTI2022

Failure Mechanism Traceability and Application in Human System Interface of Nuclear Power Plants using RESHA

In recent years, there has been considerable effort to modernize existing and new nuclear power plants with digital instrumentation and control systems (DI&C). However, there has also been considerable concern both by industry and regulatory bodies for the risk and consequence analysis of these systems. Of particular concern are digital common cause failures (CCFs) specifically related to software defects. These “misbehaviors” by the software can occur in both the control and monitoring of a system. While many new methods have been proposed to identify potential software failure modes, such as Systems-theoretic Process Analysis (STPA), Hazard and Consequence Analysis for Digital Systems (HAZCADS), etc., these methods are focused primarily on the control action pathway of a system. In contrast, the information feedback pathway lacks unsafe control actions (UCAs), which are typically related to software basic events; thus, assessment of software basic events in such systems is unclear. In this work, we present the idea of intermediate processors and unsafe information flow (UIF) to help safety analysts trace failure mechanisms in the feedback pathway and how they can be integrated into a fault tree for improved assessment capability. The concepts presented are demonstrated in two comprehensive case studies, a smart sensor integrated platform for unmanned autonomous vehicles and another on a representative advanced human system interface (HSI) for safety critical plant monitoring. The qualitative software basic events are identified, and a fault tree analysis is conducted based on a modified Redundancy-guided Systems-theoretic Hazard Analysis (RESHA) methodology. The case studies demonstrate the use of UIF and intermediate processors in the fault tree to improve traceability of software failures in highly complex digital instrumentation feedback. The improved method can also clarify fault tree construction when multiple component dependencies are present in the system.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2022

Failure Mechanism Traceability and Application in Human System Interface of Nuclear Power Plants using RESHA

In recent years, there has been considerable effort to modernize existing and new nuclear power plants with digital instrumentation and control systems (DI&C). However, there has also been considerable concern both by industry and regulatory bodies for the risk and consequence analysis of these systems. Of particular concern are digital common cause failures (CCFs) specifically related to software defects. These “misbehaviors” by the software can occur in both the control and monitoring of a system. While many new methods have been proposed to identify potential software failure modes, such as Systems-theoretic Process Analysis (STPA), Hazard and Consequence Analysis for Digital Systems (HAZCADS), etc., these methods are focused primarily on the control action pathway of a system. In contrast, the information feedback pathway lacks unsafe control actions (UCAs), which are typically related to software basic events; thus, assessment of software basic events in such systems is unclear. In this work, we present the idea of intermediate processors and unsafe information flow (UIF) to help safety analysts trace failure mechanisms in the feedback pathway and how they can be integrated into a fault tree for improved assessment capability. The concepts presented are demonstrated in two comprehensive case studies, a smart sensor integrated platform for unmanned autonomous vehicles and another on a representative advanced human system interface (HSI) for safety critical plant monitoring. The qualitative software basic events are identified, and a fault tree analysis is conducted based on a modified Redundancy-guided Systems-theoretic Hazard Analysis (RESHA) methodology. The case studies demonstrate the use of UIF and intermediate processors in the fault tree to improve traceability of software failures in highly complex digital instrumentation feedback. The improved method can also clarify fault tree construction when multiple component dependencies are present in the system.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2021

Integrated system failure analysis software toolchain (IS-FAST)

Systems and methods are provided for generating faults and analyzing fault propagation and its effects. Starting from the ontologies of components, functions, flows, and faults, systems and methods are provided that describe, generate and track faults in a computer system across multiple domains throughout design and/or development. In order to construct the system and fault models, a series of concepts is introduced in the form of ontologies and their dependencies. An investigation is performed into the faults, including their type, cause, life-cycle aspects, and effect. Principles and rules are created to generate various faults based on system configurations. After the modeling process, a simulation engine is described to execute actions and simulate the process of fault generation and propagation. As a result, fault paths that impact components and functions can be obtained.

Diao, Xiaoxu↗
NASA NTRS2010

Improving Software Engineering on NASA Projects

Software Engineering Initiative: Reduces risk of software failure -Increases mission safety. More predictable software cost estimates and delivery schedules. Smarter buyer of contracted out software. More defects found and removed earlier. Reduces duplication of efforts between projects. Increases ability to meet the challenges of evolving software technology.

Crumbley, Tim↗
NASA NTRSDate not supplied

Orion Backup Flight Software

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

Orion↗
NASA NTRSDate not supplied

Orion Backup Flight Software (BFS)

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

CFS↗
NASA NTRS1988

Results of software error-data experiments

In order to evaluate existing software reliability models and proposed modeling approaches, a search was conducted for data on the software failure process. This search revealed that the data necessary for this evaluation were not available. As a result, a research effort was initiated by NASA to generate data on which to base the development of credible methods for assessing the reliability of software targeted for flight-crucial applications. Two sets of software error-data experiments were conducted by different research groups. The results of the experiments were consistent: errors caused by different faults in a program occurred at widely varying rates; program failure rates exhibited a log-linear trend with respect to the number of faults corrected; some faults were found to interact in either concealing or revealing ways; and contiguous regions of the input space which cause a program to generate errors, called error crystals, were found and characterized for some faults. Collectively, these experiments have produced information on software failure which must be accounted for in software reliability modeling approaches.

Finelli, George B.↗
DOE OSTI2022

An Application of a Modified Beta Factor Method for the Analysis of Software Common Cause Failures

This paper presents an approach for modeling software common cause failures (CCFs) within digital instrumentation and control (I&C) systems. CCFs consist of a concurrent failure between two or more components due to a shared failure cause and coupling mechanism. This work emphasizes the importance of identifying software-centric attributes related to the coupling mechanisms necessary for simultaneous failures of redundant software components. The groups of components that share coupling mechanisms are called common cause component groups (CCCGs). Most CCF models rely on operational data as the basis for establishing CCCG parameters and predicting CCFs. This work is motivated by two primary concerns: (1) a lack of operational and CCF data for estimating software CCF model parameters; and (2) the need to model single components as part of multiple CCCGs simultaneously. A hybrid approach was developed to account for these concerns by leveraging existing techniques: a modified beta factor model allows single components to be placed within multiple CCCGs, while a second technique provides software-specific model parameters for each CCCG. This hybrid approach provides a means to overcome the limitations of conventional methods while offering support for design decisions under the limited data scenario.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Bayesian And Human Reliability Analysis (hra)-aided Method For The Reliability Analysis Of Software (bahamas)

The purpose of the BAHAMAS code is to provide a simplified process for performing quantitative evaluations of software reliability. The Bayesian and Human Reliability Analysis (HRA)-Aided method for the Reliability Analysis of software (BAHAMAS) was developed specifically to perform quantification under limited data conditions, i.e., when limited testing or operational data are available, such as during early development stages. BAHAMAS essentially examines the quality of a software development life cycle to determine the probability of specific types of software failure. BAHAMAS will have modules to support user input for detailed and simplified analyses. The user interface will also support software common cause failure analysis.

Wang, Congjian (0000000207789927)↗
NASA NTRS1989

Study of a unified hardware and software fault-tolerant architecture

A unified architectural concept, called the Fault Tolerant Processor Attached Processor (FTP-AP), that can tolerate hardware as well as software faults is proposed for applications requiring ultrareliable computation capability. An emulation of the FTP-AP architecture, consisting of a breadboard Motorola 68010-based quadruply redundant Fault Tolerant Processor, four VAX 750s as attached processors, and four versions of a transport aircraft yaw damper control law, is used as a testbed in the AIRLAB to examine a number of critical issues. Solutions of several basic problems associated with N-Version software are proposed and implemented on the testbed. This includes a confidence voter to resolve coincident errors in N-Version software. A reliability model of N-Version software that is based upon the recent understanding of software failure mechanisms is also developed. The basic FTP-AP architectural concept appears suitable for hosting N-Version application software while at the same time tolerating hardware failures. Architectural enhancements for greater efficiency, software reliability modeling, and N-Version issues that merit further research are identified.

Lala, Jaynarayan↗
NASA NTRS2023

Considerations for Software Fault Prevention and Tolerance

Mission or safety-critical spaceflight systems should be developed to both reduce the likelihood of software faults pre-flight and to detect/mitigate the effects of software errors should they occur in-flight. New data is available that categorizes software errors from significant historic spaceflight software incidents with implications and considerations to better develop and design software to both minimize and tolerate these most likely software failures.

Avionics↗
DOE OSTI2023

Analyzing Hardware and Software Common Cause Failures in Digital Instrumentation and Control Systems using Dual Error Propagation Method

This paper develops a methodology for quantifying software common cause failures (CCFs) in digital instrumentation and control (I&C) systems of nuclear power plants. To support the transition of analog I&C systems to digital in nuclear power plants, probabilistic risk assessment (PRA) techniques are used. The hardware components of the I&C systems have reliability databases that can be used in the PRA studies. However, the failure data for redundant software components of the systems is sparse. Failure of components constitutes a CCF, wherein two or more components or systems fail due to a single shared cause and coupling mechanism. This paper proposes a quantification approach that can simultaneously model hardware and software components, incorporate the CCFs of software systems in the models, and bridge the gap between the failure quantification of models and the development of CCF parametric databases. We demonstrate the dual error propagation method (DEPM) by developing I&C systems failure models for a representative digital reactor trip system. The DEPM models are built to simulate the control and data flows within the systems and can accommodate failure states. By expanding DEPM to software CCFs, we generated alpha factor parameter estimates for each of the modeled error propagation mechanisms.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1991

Factors That Affect Software Testability

Software faults that infrequently affect software's output are dangerous. When a software fault causes frequent software failures, testing is likely to reveal the fault before the software is releases; when the fault remains undetected during testing, it can cause disaster after the software is installed. A technique for predicting whether a particular piece of software is likely to reveal faults within itself during testing is found in [Voas91b]. A piece of software that is likely to reveal faults within itself during testing is said to have high testability. A piece of software that is not likely to reveal faults within itself during testing is said to have low testability. It is preferable to design software with higher testabilities from the outset, i.e., create software with as high of a degree of testability as possible to avoid the problems of having undetected faults that are associated with low testability. Information loss is a phenomenon that occurs during program execution that increases the likelihood that a fault will remain undetected. In this paper, I identify two brad classes of information loss, define them, and suggest ways of predicting the potential for information loss to occur. We do this in order to decrease the likelihood that faults will remain undetected during testing.

Voas, Jeffrey M.↗
NASA NTRS1990

Software verification plan for GCS

This verification plan is written as part of an experiment designed to study the fundamental characteristics of the software failure process. The experiment will be conducted using several implementations of software that were produced according to industry-standard guidelines, namely the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, Software Consideration in Airborne Systems and Equipment Certification, for the development of flight software. This plan fulfills the DO-178A requirements for providing instructions on the testing of each implementation of software. The plan details the verification activities to be performed at each phase in the development process, contains a step by step description of the testing procedures, and discusses all of the tools used throughout the verification process.

Dent, Leslie A.↗
NASA NTRS1991

An evaluation of a DO-178A software development process

The guidance and control software (GCS) experiment is an effort to generate realistic software failure data by developing three implementations of a guidance and control software application according to the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines. The authors describe their approach for evaluating the DO-178A guidelines and give results from the development and verification process for the Pluto implementation. The other names are Mercury and Earth. The preliminary analysis of the Pluto implementation has already yielded some results that will be interesting to track for the other implementations.

Shagnea, Anita M.↗