Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Test Report”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2008

JPL Test Effectiveness Analysis

1) The pilot study provided meaningful conclusions that are generally consistent with the earlier Test Effectiveness work done between 1992 and 1994: a) Analysis of pre-launch problem/failure reports is consistent with earlier work. b) Analysis of post-launch early mission anomaly reports indicates that there are more software issues in newer missions, and the no-test category for identification of post-launch failures is more significant than in the earlier analysis. 2) Future work includes understanding how differences in Missions effect these analyses: a) There are large variations in the number of problem reports and issues that are documented by the different Projects/Missions. b) Some missions do not have any reported environmental test anomalies, even though environmental tests were performed. 3) Each project/mission has different standards and conventions for filling out the PFR forms, the industry may wish to address this issue: a) Existing problem reporting forms are to document and track problems, failures, and issues (etc.) for the projects, to ensure high quality. b) Existing problem reporting forms are not intended for data mining.

failure cause↗
NASA NTRS1976

A methodology for producing reliable software, volume 1

An investigation into the areas having an impact on producing reliable software including automated verification tools, software modeling, testing techniques, structured programming, and management techniques is presented. This final report contains the results of this investigation, analysis of each technique, and the definition of a methodology for producing reliable software.

Stucki, L. G.↗
NASA NTRS1997

Proposal for beta-test of GIFCORCODE

This year's effort produced very significant progress in the development of the software package heretofore known as GIFCORCODE. One important change has been in the name. The package is now named CONDUIT for CONtrol Designer's Unified InTerface. There have also been some more significant changes in the way CONDUIT is used. These changes caused some modifications in the work accomplished. Both the original goals for the year and the modifications will be described in the next section of this report. The major goal for this year was to bring CONDUIT to beta-test. This has been accomplished. The software package is in beta-test at Bell Helicopters and has been since September 1996. This and the other achievements during the past year are described in the third section of this report. Some discussion of the scaling issue is also included here. This is in answer to a question that arose at one of the CONDUIT briefings. The report concludes with a brief set of suggestions for further work. An appendix describing the issues involved in dynamic linking is also included.

Levine, William S.↗
NASA NTRS1974

MSFC Skylab attitude and pointing control system mission evaluation

The results of detailed performance analyses of the attitude and pointing control system in-orbit hardware and software on Skylab are reported. Performance is compared with requirements, test results, and prelaunch predictions. A brief history of the altitude and pointing control system evolution leading to the launch configuration is presented. The report states that the attitude and pointing system satisfied all requirements.

Chubb, W. B.↗
NASA NTRS2009

Oxygen Generation System Laptop Bus Controller Flight Software

The Oxygen Generation System Laptop Bus Controller Flight Software was developed to allow the International Space Station (ISS) program to activate specific components of the Oxygen Generation System (OGS) to perform a checkout of key hardware operation in a microgravity environment, as well as to perform preventative maintenance operations of system valves during a long period of what would otherwise be hardware dormancy. The software provides direct connectivity to the OGS Firmware Controller with pre-programmed tasks operated by on-orbit astronauts to exercise OGS valves and motors. The software is used to manipulate the pump, separator, and valves to alleviate the concerns of hardware problems due to long-term inactivity and to allow for operational verification of microgravity-sensitive components early enough so that, if problems are found, they can be addressed before the hardware is required for operation on-orbit. The decision was made to use existing on-orbit IBM ThinkPad A31p laptops and MIL-STD-1553B interface cards as the hardware configuration. The software at the time of this reporting was developed and tested for use under the Windows 2000 Professional operating system to ensure compatibility with the existing on-orbit computer systems.

Rowe, Chad↗
NASA NTRS2011

Space Telecommunications Radio System (STRS) Compliance Testing

The Space Telecommunications Radio System (STRS) defines an open architecture for software defined radios. This document describes the testing methodology to aid in determining the degree of compliance to the STRS architecture. Non-compliances are reported to the software and hardware developers as well as the NASA project manager so that any non-compliances may be fixed or waivers issued. Since the software developers may be divided into those that provide the operating environment including the operating system and STRS infrastructure (OE) and those that supply the waveform applications, the tests are divided accordingly. The static tests are also divided by the availability of an automated tool that determines whether the source code and configuration files contain the appropriate items. Thus, there are six separate step-by-step test procedures described as well as the corresponding requirements that they test. The six types of STRS compliance tests are: STRS application automated testing, STRS infrastructure automated testing, STRS infrastructure testing by compiling WFCCN with the infrastructure, STRS configuration file testing, STRS application manual code testing, and STRS infrastructure manual code testing. Examples of the input and output of the scripts are shown in the appendices as well as more specific information about what to configure and test in WFCCN for non-compliance. In addition, each STRS requirement is listed and the type of testing briefly described. Attached is also a set of guidelines on what to look for in addition to the requirements to aid in the document review process.

Handler, Louis M.↗
NASA NTRS1988

Concept of a programmable maintenance processor applicable to multiprocessing systems

A programmable maintenance processor concept applicable to multiprocessing systems has been developed at the NASA Ames Research Center's Dryden Flight Research Facility. This stand-alone-processor is intended to provide support for system and application software testing as well as hardware diagnostics. An initial machanization has been incorporated into the extended aircraft interrogation and display system (XAIDS) which is multiprocessing general-purpose ground support equipment. The XAIDS maintenance processor has independent terminal and printer interfaces and a dedicated magnetic bubble memory that stores system test sequences entered from the terminal. This report describes the hardware and software embodied in this processor and shows a typical application in the check-out of a new XAIDS.

Glover, Richard D.↗
NASA NTRS1997

A Case Study of 4 & 5 Cost Effectiveness

This paper looks at the Independent Verification and Validation (IV&V) of NASA's Space Shuttle Day of Launch I-Load Update (DoLILU) project. IV&V is defined. The system's development life cycle is explained. Data collection and analysis are described. DoLILU Issue Tracking Reports (DITRs) authored by IV&V personnel are analyzed to determine the effectiveness of IV&V in finding errors before the code, testing, and integration phase of the software development life cycle. The study's findings are reported along with the limitations of the study and planned future research.

Neal, Ralph D.↗
DOE OSTI2023

Laboratory Instrument Software Controlled Spread Spectrum Time Domain Reflectometry for Electrical Cable Testing

This research discusses development of a software-controlled laboratory instrument based spread spectrum time domain reflectometry system (SSTDR). This constitutes one task within PNNL’s Light Water Sustainability Program (LWRS) whose mission includes advancing nondestructive examination (NDE) techniques for off-line and on-line in-situ cable condition monitoring. In 2022, PNNL evaluated SSTDR for detection and characterization of a number of cable anomalies (Glass et al. 2022). The review included comparison of SSTDR to Frequency Domain Reflectometry (FDR) techniques which have enjoyed encouraging feedback and are starting to be used in nuclear power plants for periodic cable condition monitoring of cable systems as part of the plant’s overall cable aging management program. The FDR test introduces a broad-band chirp onto the cable at the cable end then listens for any reflection from a change of impedance along the cable caused by a damaged conductor or insulation, splices, contact with moisture, or other cable anomalies. The signal is captured in the frequency domain then transformed back to the time domain using an inverse Fourier transform (IFT). Based on the velocity of propagation, the impedance response signal is plotted against distance along the cable. Peak locations along the X-axis indicate the distance along the cable where a portion of the signal has been reflected back to the instrument as a result of a cable anomaly. The FDR test is considered the gold standard of reflectometry however it does require the cable to be de-energized to perform the test. The LIVEWIRE commercial SSTDR produces a similar plot to the FDR however all processing is in the time domain. A pseudo-random noise code (PN code) is input onto the cable conductor and the instrument listens for any reflected response from cable anomalies. The SSTDR processes the signal as an autocorrelation comparing the input PN code to any reflected signal detected. The autocorrelation analysis for thermal aging, water and water ingress detection, ground fault and phase-to-phase fault detection at various locations along the cable and with the cable attached and detached from a motor load, and on both energized and un-energized conditions were performed. These results were contrasted to Frequency Domain Reflectometry (FDR) measurements of the un-energized cable. Results were encouraging but indicated more work was warranted – particularly with the SSTDR, it seemed that the insulation damage would likely be better evaluated with multiple bandwidth cable tests particularly including larger bandwidths than were possible with the current commercial instrument. The commercial instrument’s bandwidth was set at 6, 12, 24, and 48MHz but note that SSTDR and FDR definitions of bandwidth trend similarly but are not the same. The FDR response could be more broadly adjusted, and the bandwidth of 100 to 500 MHz produced the best responses. FDR responses to anomalies were clearer than SSTDR responses and indications were that a broader bandwidth SSTDR may lead to improved SSTDR detection capability. This project used a laboratory instrument based SSTDR (primarily using an Arbitrary Waveform Generator (AWG) and a digital oscilloscope plus Python in-house software) that allowed software adjustment of the SSTDR bandwidth, window functions applied to the exciting Pseudo-random Noise (PN) code plus and other aspects of the SSTDR signal processing. Hereafter, this will be referred to as the PNNL SSTDR. Evaluating specific performance of the PNNL SSTDR is left to a separate report. This report documents hardware and software development to produce the SSTDR cable test system.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRS1986

Implementation and flight tests for the Digital Integrated Automatic Landing System (DIALS). Part 1: Flight software equations, flight test description and selected flight test data

Five flight tests of the Digital Automated Landing System (DIALS) were conducted on the Advanced Transport Operating Systems (ATOPS) Transportation Research Vehicle (TSRV) -- a modified Boeing 737 aircraft for advanced controls and displays research. These flight tests were conducted at NASA's Wallops Flight Center using the microwave landing system (MLS) installation on runway 22. This report describes the flight software equations of the DIALS which was designed using modern control theory direct-digital design methods and employed a constant gain Kalman filter. Selected flight test performance data is presented for localizer (runway centerline) capture and track at various intercept angles, for glideslope capture and track of 3, 4.5, and 5 degree glideslopes, for the decrab maneuver, and for the flare maneuver. Data is also presented to illustrate the system performance in the presence of cross, gust, and shear winds. The mean and standard deviation of the peak position errors for localizer capture were, respectively, 24 feet and 26 feet. For mild wind conditions, glideslope and localizer tracking position errors did not exceed, respectively, 5 and 20 feet. For gusty wind conditions (8 to 10 knots), these errors were, respectively, 10 and 30 feet. Ten hands off automatic lands were performed. The standard deviation of the touchdown position and velocity errors from the mean values were, respectively, 244 feet and 0.7 feet/sec.

Hueschen, R. M.↗
NASA NTRS1994

COSMIC monthly progress report

Activities of the Computer Software Management and Information Center (COSMIC) are summarized for the month of May 1994. Tables showing the current inventory of programs available from COSMIC are presented and program processing and evaluation activities are summarized. Nine articles were prepared for publication in the NASA Tech Brief Journal. These articles (included in this report) describe the following software items: (1) WFI - Windowing System for Test and Simulation; (2) HZETRN - A Free Space Radiation Transport and Shielding Program; (3) COMGEN-BEM - Composite Model Generation-Boundary Element Method; (4) IDDS - Interactive Data Display System; (5) CET93/PC - Chemical Equilibrium with Transport Properties, 1993; (6) SDVIC - Sub-pixel Digital Video Image Correlation; (7) TRASYS - Thermal Radiation Analyzer System (HP9000 Series 700/800 Version without NASADIG); (8) NASADIG - NASA Device Independent Graphics Library, Version 6.0 (VAX VMS Version); and (9) NASADIG - NASA Device Independent Graphics Library, Version 6.0 (UNIX Version). Activities in the areas of marketing, customer service, benefits identification, maintenance and support, and dissemination are also described along with a budget summary.

Source record↗
NASA NTRS2003

An Immunized Aircraft Maneuver Selection System

The objective of this project, as stated in the original proposal, was to develop an immunized aircraft maneuver selection (IAMS) system. The IAMS system was to be composed of computational and informational building blocks that resemble structures in natural immune systems. The ultimate goal of the project was to develop a software package that could be flight tested on aircraft models. This report describes the work performed in the first year of what was to have been a two year project. This report also describes efforts that would have been made in the final year to have completed the project, had it been continued for the final year. After introductory material is provided in Section 2, the end-of-year-one status of the effort is discussed in Section 3. The remainder of the report provides an accounting of first year efforts. Section 4 provides background information on natural immune systems while Section 5 describes a generic ar&itecture developed for use in the IAMS. Section 6 describes the application of the architecture to a system identification problem. Finally, Section 7 describes steps necessary for completing the project.

Karr, Charles L.↗
DOE OSTI2021

Quantitative Risk Analysis of High Safety Significant Safety-related Digital Instrumentation and Control Systems in Nuclear Power Plants using IRADIC Technology

This report documents the activities performed by Idaho National Laboratory (INL) during fiscal year (FY) 2021 for the U.S. Department of Energy (DOE) Light Water Reactor Sustainability (LWRS) Program, Risk Informed Systems Analysis (RISA) Pathway, digital instrumentation and control (DI&C) Risk Assessment project. In FY-2019, the RISA Pathway initiated a project to develop a risk assessment strategy for delivering a strong technical basis to support effective, licensable, and secure DI&C technologies for digital upgrades/designs. An integrated risk assessment technology for the DI&C systems (IRADIC technology) was proposed for this strategy, which aims to (1) provide a best-estimate risk-informed capability to quantitatively and accurately estimate the safety margin obtained from plant modernization, especially for the High Safety Significant Safety-related (HSSSR) DI&C systems, (2) develop an advanced risk assessment technology to support transition from analog to DI&C technologies for nuclear industry, (3) assure the long-term safety and reliability of vital HSSSR DI&C systems, (4) reduce uncertainty in costs and support integration of DI&C systems in the plant. To achieve these technical goals and deal with the expensive licensing justifications from regulatory insights, the IRADIC technology is instructive for nuclear vendors and utilities to effectively lower the costs associated with digital compliance and speed industry advances by: (1) defining an integrated risk-informed analysis process for DI&C upgrade, including hazard analysis, reliability analysis, and consequence analysis, (2) applying systematic and risk-informed tools to address common cause failures (CCFs) and quantify responding failure probabilities for DI&C technologies, particularly software CCFs, (3) evaluating the impact of digital failures at the individual level, system level, and plant level, (4) providing insights and suggestions on designs to manage the risks; thus, to support the development, licensing, and deployment of advanced DI&C technologies on nuclear power plant (NPPs). In this report, an approach for performing software CCF analysis, given limited data, is developed and demonstrated using a case study of a highly redundant digital reactor trip system. Consequence analysis is also performed based on different accident scenarios. Results indicate that plant modernization including the improvement of HSSSR DI&C systems will make great benefits to plant safety by providing more safety margins to accident management. In addition, a novel approach is proposed in this report for the quantification of software hazards when sufficient operational and testing data available. The method incorporates software development quality as well as strong analysis techniques to identify and link software defects to potential failure modes. The approach includes both semantic and test-based analysis to detect failures that can exist in different stages of the software development life cycle. This method is applied to an advanced human system interface relevant to reactor trip safety developed from the APR 1400 design.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗