Search NASA⌕ Search

SEARCH · Search NASA

Results for “Automated Testing”

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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

An Ada programming support environment

The toolset of an Ada Programming Support Environment (APSE) being developed at North American Aircraft Operations (NAAO) of Rockwell International, is described. The APSE is resident on three different hosts and must support developments for the hosts and for embedded targets. Tools and developed software must be freely portable between the hosts. The toolset includes the usual editors, compilers, linkers, debuggers, configuration magnagers, and documentation tools. Generally, these are being supplied by the host computer vendors. Other tools, for example, pretty printer, cross referencer, compilation order tool, and management tools were obtained from public-domain sources, are implemented in Ada and are being ported to the hosts. Several tools being implemented in-house are of interest, these include an Ada Design Language processor based on compilable Ada. A Standalone Test Environment Generator facilitates test tool construction and partially automates unit level testing. A Code Auditor/Static Analyzer permits the Ada programs to be evaluated against measures of quality. An Ada Comment Box Generator partially automates generation of header comment boxes.

Tyrrill, AL↗
NASA NTRS1978

Studies of self streamlining wind tunnel real and imaginary flows

Testing in the low speed flexible walled tunnel in an effort to explain the reasons for data discrepancies at high angles of attack are presented. Automated transonic test sections were developed. The flexible walled tunnel was used in a new operating mode to a generated curved flow around the airfoil, allowing the extraction of purely rotary derivatives. Some straight wall, low speed pressure data, for wall and model, which is used for checking interference correction methods were reported. Computer software which includes an old streamlining algorithm and a prediction algorithm was examined.

Wolf, S. W. D.↗
NASA NTRS2007

Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as Automated Rendezvous and Docking, AR&D). The crewed versions may also perform AR&D, possibly with a different level of automation and/or autonomy, and must also provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the CEV requirements. The relatively low technology readiness of relative navigation sensors for AR&D has been carried as one of the CEV Projects top risks. The AR&D Sensor Technology Project seeks to reduce this risk by increasing technology maturation of selected relative navigation sensor technologies through testing and simulation, and to allow the CEV Project to assess the relative navigation sensors.

Mitchell, J.↗
NASA NTRS2007

Automated Rendezvous and Docking Sensor Testing at the Flight Robotics Laboratory

The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as Automated Rendezvous and Docking, (AR&D).) The crewed versions of the spacecraft may also perform AR&D, possibly with a different level of automation and/or autonomy, and must also provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the CEV requirements. The relatively low technology readiness of relative navigation sensors for AR&D has been carried as one of the CEV Projects top risks. The AR&D Sensor Technology Project seeks to reduce this risk by increasing technology maturation of selected relative navigation sensor technologies through testing and simulation, and to allow the CEV Project to assess the relative navigation sensors.

Howard, Richard T.↗
DOE OSTI2025

Enhancing Post-Irradiation Examination (PIE) Efficiency with High-Throughput Experiments

Nuclear materials testing is essential for understanding changes in reactor environments, but traditional methods are costly and time-consuming. High-Throughput Experimentation (HTE) enables rapid screening and optimization of material properties by significantly increasing the number of specimens in the experiment. In this work, HTE methods were employed to irradiate novel materials at the Advanced Test Reactor (ATR) at Idaho National Laboratory. A total of 367 sub-sized tensile specimens were irradiated using the standard capsule design. To facilitate HTE, automated systems such as the Automated Mechanical Testing System were implemented for mechanical testing within hot cell environments, thereby reducing the need for manual interaction with hot cell manipulators and significantly lowering both the cost and duration of experiments. Digital image correlation (DIC) was used to measure displacement during mechanical testing, providing precise, non-contact measurement capabilities. The methodologies developed in this research will support the advancement of HTE techniques for future nuclear materials testing experiments at ATR. This approach allows for more efficient and cost-effective evaluation of new materials, ultimately leading to improved reactor performance, enhanced safety, and extended longevity within the nuclear industry.

22 - GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1988

Benchmarking expert system tools

As part of its evaluation of new technologies, the Artificial Intelligence Section of the Mission Planning and Analysis Div. at NASA-Johnson has made timing tests of several expert system building tools. Among the production systems tested were Automated Reasoning Tool, several versions of OPS5, and CLIPS (C Language Integrated Production System), an expert system builder developed by the AI section. Also included in the test were a Zetalisp version of the benchmark along with four versions of the benchmark written in Knowledge Engineering Environment, an object oriented, frame based expert system tool. The benchmarks used for testing are studied.

Riley, Gary↗
NASA NTRS2013

A System for Fault Management for NASA's Deep Space Habitat

NASA's exploration program envisions the utilization of a Deep Space Habitat (DSH) for human exploration of the space environment in the vicinity of Mars and/or asteroids. Communication latencies with ground control of as long as 20+ minutes make it imperative that DSH operations be highly autonomous, as any telemetry-based detection of a systems problem on Earth could well occur too late to assist the crew with the problem. A DSH-based development program has been initiated to develop and test the automation technologies necessary to support highly autonomous DSH operations. One such technology is a fault management tool to support performance monitoring of vehicle systems operations and to assist with real-time decision making in connection with operational anomalies and failures. Toward that end, we are developing Advanced Caution and Warning System (ACAWS), a tool that combines dynamic and interactive graphical representations of spacecraft systems, systems modeling, automated diagnostic analysis and root cause identification, system and mission impact assessment, and mitigation procedure identification to help spacecraft operators (both flight controllers and crew) understand and respond to anomalies more effectively. In this paper, we describe four major architecture elements of ACAWS: Anomaly Detection, Fault Isolation, System Effects Analysis, and Graphic User Interface (GUI), and how these elements work in concert with each other and with other tools to provide fault management support to both the controllers and crew. We then describe recent evaluations and tests of ACAWS on the DSH testbed. The results of these tests support the feasibility and strength of our approach to failure management automation and enhanced operational autonomy.

Fault management↗
NASA NTRS2013

A System for Fault Management and Fault Consequences Analysis for NASA's Deep Space Habitat

NASA's exploration program envisions the utilization of a Deep Space Habitat (DSH) for human exploration of the space environment in the vicinity of Mars and/or asteroids. Communication latencies with ground control of as long as 20+ minutes make it imperative that DSH operations be highly autonomous, as any telemetry-based detection of a systems problem on Earth could well occur too late to assist the crew with the problem. A DSH-based development program has been initiated to develop and test the automation technologies necessary to support highly autonomous DSH operations. One such technology is a fault management tool to support performance monitoring of vehicle systems operations and to assist with real-time decision making in connection with operational anomalies and failures. Toward that end, we are developing Advanced Caution and Warning System (ACAWS), a tool that combines dynamic and interactive graphical representations of spacecraft systems, systems modeling, automated diagnostic analysis and root cause identification, system and mission impact assessment, and mitigation procedure identification to help spacecraft operators (both flight controllers and crew) understand and respond to anomalies more effectively. In this paper, we describe four major architecture elements of ACAWS: Anomaly Detection, Fault Isolation, System Effects Analysis, and Graphic User Interface (GUI), and how these elements work in concert with each other and with other tools to provide fault management support to both the controllers and crew. We then describe recent evaluations and tests of ACAWS on the DSH testbed. The results of these tests support the feasibility and strength of our approach to failure management automation and enhanced operational autonomy

System Effects Analysis↗
NASA NTRS1975

The Mark 3 Haploscope

A computer-operated binocular vision testing device was developed as one part of a system designed for NASA to evaluate the visual function of astronauts during spaceflight. This particular device, called the Mark 3 Haploscope, employs semi-automated psychophysical test procedures to measure visual acuity, stereopsis, phoria, fixation disparity, refractive state and accommodation/convergence relationships. Test procedures are self-administered and can be used repeatedly without subject memorization. The Haploscope was designed as one module of the complete NASA Vision Testing System. However, it is capable of stand-alone operation. Moreover, the compactness and portability of the Haploscope make possible its use in a broad variety of testing environments.

Decker, T. A.↗
NASA NTRS2001

Verifying Data Integrity of Electronically Scanned Pressure Systems at the NASA Glenn Research Center

The proper operation of the Electronically Scanned Pressure (ESP) System critical to accomplish the following goals: acquisition of highly accurate pressure data for the development of aerospace and commercial aviation systems and continuous confirmation of data quality to avoid costly, unplanned, repeat wind tunnel or turbine testing. Standard automated setup and checkout routines are necessary to accomplish these goals. Data verification and integrity checks occur at three distinct stages, pretest pressure tubing and system checkouts, daily system validation and in-test confirmation of critical system parameters. This paper will give an overview of the existing hardware, software and methods used to validate data integrity.

Panek, Joseph W.↗
NASA NTRSDate not supplied

Trajectory Simulation Using Multi Model Monte Carlo with Python (MXMCPy)

EDL (Entry, Descent and Landing) is the process from a vehicle approaching a surface to landing on it, such as a Mars rover approaching the planet before landing. POST2 (Program to Optimize Simulated Trajectories 2) is Langley’s primary EDL simulation tool and is used NASA-wide for simulations. POST2 can generate highly accurate results by running a precise, but time consuming, Monte Carlo (MC) simulation hundreds or thousands of times. Though POST2 can produce highly accurate results, it can take unrealistic time spans to generate these results, which has created a need to speed up the simulations. The new NASA software MXMCPy offers various ways to speed up the simulations while getting just as precise results. Instead of running high-precision POST2 simulations many times for traditional MC, MXMCPy can run fewer high-precision POST2 simulations and many less precise POST2 simulations and merge the results. MXMCPy contains 30+ different methods which will each suggest different allocations between model precision levels, which result in results of varying precision based on the POST2 simulation. I created Python and Bash code to automate the 5 steps of MXMCPy’s application to POST2. I also tested the precision of traditional Monte Carlo simulations to MXMCPy aided simulations and found that MXMCPy can achieve substantially more precise solutions at the same computer runtime. I learned Test Driven Development (TDD), a software programming workflow which involves writing computer-automated tests before writing the code which is being tested. These tests are ran every time the code is changed and they can find glitches in the code much quicker than a human can. This programming workflow saved me a lot of time because the automated tests could tell me exactly where the code had stopped working. I plan on using this software development method for future academic and professional software projects. I have greatly enjoyed my work at NASA, so I have been applying to NASA internships and Pathways positions. In addition, I plan on applying what I have learned about Test Driven Development to my computer science courses next semester

James Warner↗
NASA NTRS1972

Development, integration, and testing of a 30 cm thruster/power conditioning and control system.

The 30 cm thruster/power conditioning and control system discussed represents a significant milestone in the evolution of prime ion propulsion systems. The effort described covers three distinct electronic hardware implementation, integration and testing phases; development of a flight-type power conditioner for laboratory testing, development of a thruster control system to control the power conditioning for demonstrating continuously variable automatic thruster throttling from a single control over a range in excess of 5:1, and finally development of an automated endurance test system incorporating many of the above designs for a 6000 hour thruster life test.

Herron, B. G.↗
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 NTRS1991

Robot graphic simulation testbed

The objective of this research was twofold. First, the basic capabilities of ROBOSIM (graphical simulation system) were improved and extended by taking advantage of advanced graphic workstation technology and artificial intelligence programming techniques. Second, the scope of the graphic simulation testbed was extended to include general problems of Space Station automation. Hardware support for 3-D graphics and high processing performance make high resolution solid modeling, collision detection, and simulation of structural dynamics computationally feasible. The Space Station is a complex system with many interacting subsystems. Design and testing of automation concepts demand modeling of the affected processes, their interactions, and that of the proposed control systems. The automation testbed was designed to facilitate studies in Space Station automation concepts.

Cook, George E.↗
NASA NTRS2006

Testing Strategies for Model-Based Development

This report presents an approach for testing artifacts generated in a model-based development process. This approach divides the traditional testing process into two parts: requirements-based testing (validation testing) which determines whether the model implements the high-level requirements and model-based testing (conformance testing) which determines whether the code generated from a model is behaviorally equivalent to the model. The goals of the two processes differ significantly and this report explores suitable testing metrics and automation strategies for each. To support requirements-based testing, we define novel objective requirements coverage metrics similar to existing specification and code coverage metrics. For model-based testing, we briefly describe automation strategies and examine the fault-finding capability of different structural coverage metrics using tests automatically generated from the model.

Heimdahl, Mats P. E.↗
DOE OSTI2026

Transformative Efficiency and Automation in Modular Homes (TEAMH)

This report documents the Transformative Efficiency and Automation in Modular Homes (TEAMH) project, which evaluates the integration of advanced building envelope technologies and automation-assisted modular construction to improve residential energy performance and construction efficiency. The study investigates high-performance insulation systems, including vacuum insulation panels (VIPs), combined with light gauge steel (LGS) modular construction and factory automation. Laboratory testing, whole-building energy modeling across multiple climate zones, and factory demonstrations were conducted to assess thermal performance, energy savings, and production efficiency. Results indicate that upgraded envelope assemblies can achieve up to ~50% heating and ~34% cooling energy savings relative to IECC 2018 code-compliant homes, while automation-assisted construction can reduce wall assembly time by 24%–46% compared to conventional wood framing. The findings demonstrate the potential for scalable, high-performance modular homes that deliver significant energy savings with competitive projected costs.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗