Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software 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 559 records · Page 31
All sourcesNASA NTRSDOE OSTI
NASA NTRS2019

Writing a New Automated Testing Method for Custom Display Components

During the launch process of the Space Launch System (SLS), engineers in the Firing Room of the Launch Control Center (LCC) will be analyzing displays that show data and statistics about the vehicle and launch. These displays are subject to a battery of tests, but the custom components they use are not currently supported by any testing framework. My project is to modify a testing framework so that the custom components on these displays can be tested similarly to how a user would interact with them.

Automated Testing↗
NASA NTRS2003

Radiometric orbit determination activities in support of navigating Deep Space 1 to Comet Borrelly

After several months of planning, development and testing, new software was uploaded that allowed Deep Space 1 to restore celestial inertia reference and begin thrusting towards an encounter with comet Borrelly. The new mission plan would have to work within the constraints of the new software as well as minimize use of the dwindling supply of hydrazine, the fuel needed to maintain the spacecraft attitude.

DS1↗
NASA NTRS2018

Smartphone scene generator for efficient characterization of visible imaging detectors

Full characterization of imaging detectors involves subjecting them to spatially and temporally varying illumination patterns over a large dynamic range. Here we present a scene generator that fulfills many of these functions. Based on a modern smartphone, it has a number of good features, including high spatial resolution (13 um), high dynamic range (∼104), near-Poisson limited illumination stability over time periods from 100 ms to many days, and no background noise. The system does not require any moving parts and may be constructed at modest cost. We present the optical, mechanical, and software design, test data validating the performance, and application examples.

Demers, Richard T.↗
NASA NTRS2024

NASA Engineering and Safety Center Technical Bulletins 2007-2023

An NESC Technical Bulletin captures critical knowledge in the form of new engineering information or best practices in a one-page format that have resulted from NESC independent testing, analysis, and assessments. This document contains all NESC Technical Bulletins from 2007 through 2023.

additive manufacturing, battery, braycote, capacit↗
NASA NTRS2022

Adaptive IV&V for Increasingly Complex Software Systems

As NASA software systems continue to innovate, becoming more complex and nondeterministic, the need for the NASA IV&V Program to become systemically adaptive to ensure mission success is paramount. To ensure adaptability within resource constraints, IV&V has developed an agile, risk-based approach to identify, characterize, scope, focus, and prioritize mission assurance activities. This risk based adaptive framework has been applied to trends such as increased reliance on data driven algorithms for safety and mission critical software behavior, use of MBSE in system design, and application of agile principles to embedded software development. The framework is enabled by continuous innovation of new approaches such as software only test beds, assurance design tools, and initiatives that augment IV&V assurance methods with artificial intelligence and machine learning techniques. This presentation will highlight the trends the NASA IV&V Program is seeing, the innovative steps it is taking to address those challenges, and how it is postured to address evolving risk and constantly changing and new technologies.

Wesley W Deadrick↗
NASA NTRSDate not supplied

NASA Operational Simulator for SmallSats (NOS3): Design Reference Mission

The NASA Operational Simulator for Small Satellites (NOS3) has undergone significant advances including updating the framework to be “component” based and expanding the open-source code to include a generic design reference mission to enable advanced technologies. This paper details the changes to the framework as well as a number of innovative use-cases the team is currently supporting such as 1) the expansion of NOS3 to support distributed systems missions in collaboration with NASA GSFC, 2) the integration of NASA JPL’s Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) for on-orbit science data prioritization, and 3) the inclusion of NASA IV&V’s software-only CCSDS encryption library (CryptoLib). NOS3 continues to serve the SmallSat community by providing an open-source digital twin that can significantly reduce costs associated with spacecraft software development, test, and operations. The NOS3 team hopes to continue to expand the resources available to the community and partner with others to resolve issues and add new features requested via the NASA GitHub.

SmallSats↗
NASA NTRSDate not supplied

Design Considerations of an Ascent Abort Monitor Algorithm for Use During Service Module Aborts

In support of human rating the Artemis missions, NASA's Orion program requires continuous abort coverage from liftoff through mission destination. During a portion of the ascent trajectory, the currently achievable abort mode is determined by an Orion algorithm using the onboard navigated vehicle state. This ascent abort monitor determines achievability for Orion's Mode 2 abort, Untargeted Abort Splashdown (UAS), by propagating the current vehicle state through ascent abort events to determine sufficient timing to perform the abort and to a ballistic touchdown point to approximate landing location relative to prescribed keep out boundaries. The algorithm was updated for Artemis 2 to allow the capability to limit loads for the majority of ascent. Performance of the algorithm has been demonstrated and verified through dispersed trajectory analysis with emulated flight software, unit testing, and hardware in the loop testing.

Esteban Guzman↗
DOE OSTI2023

Assessment of the Phase-to-Ground Fault Apparent Admittance Method with Phase/Ground Boundaries to Detect Types of Electrical Faults for Protective Relays Using Signature Library and Simulated Events

Protective relays in electric power grids recognize the types of electrical faults in a few seconds. The most common detection method to detect the types of electrical faults is based on measuring the angle between the zero and negative sequence currents. However, it is not completely accurate because the phase to phase ground and phase to ground electrical faults could have the same detection conditions. Therefore, engineers need to plot the events after an electrical fault to observe the nature of the incidents in detail. In this study, the phase to ground fault apparent (PGFA) admittance method with phase/ground boundaries identified the types of electrical faults located in distribution power lines and feeders. This method was based on measuring the PGFA admittance magnitudes for the faulted and non-faulted phases, resulting in greater than zero and near zero, respectively. The PGFA admittance algorithm was built with MATLAB/ Simulink software and tested with signature library and grid simulation events. The PGFA method with phase/ground boundaries was evaluated with the confusion matrix. The measured and predicted values matched in more than 90% of the tests, and the PGFA admittance method with phase/ground boundaries presented an accuracy of 94.3% and a precision of 100%.

Piesciorovsky, Emilio↗
DOE OSTI2024

Improving and Automating Building Model Data Exchange

There are many instances throughout a project’s lifecycle where there arises a need for quick and accurate risk assessment of building designs. For example, an unexpected design change during construction may necessitate structural engineers to perform a seismic risk assessment on analytical models of the updated building design using high fidelity structural analysis software, such as ANSYS or Abaqus. However, the efficiency of such workflows often depends upon the interoperability of architectural design software and structural analysis software. When the quality of this interoperability is lacking or even non-existent, the efficiency of virtual engineering workflows is hampered, which increases project costs. A McGraw Hill industry survey of professional users of Building Information Modeling (BIM) technologies found that there is high demand for BIM interoperability for structural analysis, but that the value/difficulty ratio is currently too low for practical use. There have been efforts by the academic community to facilitate model data exchange between the architectural design and structural analysis domains, but such solutions have not been widely adopted by industry, face technical challenges, and oftentimes are limited in applicability for users of various BIM software. Therefore, INL is developing capabilities to improve, automate, and generalize model data exchange between architectural BIM software (e.g., Revit) and structural analysis software (e.g., SAP2000, ANSYS). The goal is to help expedite and automate as much of the pre-processing step for creating analytical models in finite element analysis software as reasonably as possible. Such a "BIM-to-FEA" conversion tool should provide direct benefit to end-users through accuracy, automation, quick turn-around, and wide applicability. To generalize the application of this BIM-to-FEA conversion tool and increase its useability among the many different commercial BIM software currently used by industry, the program is being developed with the concept of openBIM. OpenBIM is the application of non-proprietary, open data standards that allow for BIM model data exchange in a format that is accessible, retainable, and useable for all users. The most widely used open, non-proprietary data exchange format for BIM is the Industry Foundation Classes (IFC) schema. IFC is developed by buildingSMART international and is ISO certified (ISO 16739-1:2018). The BIM-to-FEA conversion tool is being developed for compatibility with typical commercial building designs of steel framed structures. The tool is currently capable of importing architectural BIM data of framed building structures, recognizing and extracting the aspects of the model that are required for structural analysis, adjusting the connectivity of frame members, and finally exporting to an analytical model stored in the IFC format. The exported IFC analytical model can then be imported into various openBIM compliant software, such as SAP2000. Such capabilities have already been tested on commercial software, as shown above, and continue to be improved. Work is underway to test the conversion on various commercial BIM software, develop a user-friendly interface, incorporate the program into the broader DeepLynx data warehouse project being developed by INL, and to eventually open-source the tool for the benefit of the community. Future development of the tool envisions the ability for efficient iterative risk assessment of generative building designs, all within a workflow utilizing open-source tools. One such open-source tool will be MOOSE, an advanced finite element analysis tool developed at INL. The conversion tool will also branch out from typical commercial building designs and will aim to incorporate nuclear construction. The aim will be to convert both structural and non-structural components of nuclear facilities, such as curved concrete containment structures and piping systems, respectively.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1998

Testing and Troubleshooting Automatically Generated Source Code

Tools allowing engineers to model the real-time behavior of systems that control many types of NASA systems have become widespread. These tools automatically generate source code that is compiled, linked, then downloaded into computers controlling everything from wind tunnels to space flight systems. These tools save hundreds of hours of software development time and allow engineers with thorough application area knowledge but little software development experience to generate software to control the systems they use daily. These systems are verified and validated by simulating the real-time models, and by other techniques that focus on the model or the hardware. The automatically generated source code is typically not subjected to rigorous testing using conventional software testing techniques. Given the criticality and safety issues surrounding these systems, the application of conventional and new software testing and troubleshooting techniques to the automatically generated will improve the reliability of the resulting systems.

Henry, Joel↗
NASA NTRS1993

Software testability and its application to avionic software

Randomly generated black-box testing is an established yet controversial method of estimating software reliability. Unfortunately, as software applications have required higher reliabilities, practical difficulties with black-box testing have become increasingly problematic. These practical problems are particularly acute in life-critical avionics software, where requirements of 10 exp -7 failures per hour of system reliability can translate into a probability of failure (POF) of perhaps 10 exp -9 or less for each individual execution of the software. This paper describes the application of one type of testability analysis called 'sensitivity analysis' to B-737 avionics software; one application of sensitivity analysis is to quantify whether software testing is capable of detecting faults in a particular program and thus whether we can be confident that a tested program is not hiding faults. We so 80 by finding the testabilities of the individual statements of the program, and then use those statement testabilities to find the testabilities of the functions and modules. For the B-737 system we analyzed, we were able to isolate those functions that are more prone to hide errors during system/reliability testing.

Voas, Jeffrey M.↗
NASA NTRS2022

Increasing Cognitive Reserve with Software - Pilot (ICARUS-Pilot)

The ICARUS-Pilot study sought to quantify and assess the potential benefit of using commercial-off-the-shelf (COTS) cognitive training software to improve cognitive performance in an astronaut-like terrestrial population. Five volunteer research subjects were recruited from the JSC employee population to mimic characteristics of the NASA astronaut population (age, education/discipline). Subject cognitive performance was assessed before and after executing eighteen sessions of remote cognitive training using six exercises within an adaptive app-based COTS software package (BrainHQ, Posit Science) on study-provided tablets. Pre- and post-training cognitive performance was measured using internal BrainHQ assessments as well as Cognition Test Battery (CTB), an independent software test developed specifically for NASA and used currently in research studies on astronauts. BrainHQ exercises were posited to map well or partially to several CTB sub-tests. Subjects provided feedback on their study experience formally via survey at the conclusion of testing and informally throughout the study if they encountered issues.

cognitive training↗
NASA NTRSDate not supplied

X-57 Flight Systems Integration Path

The foundation for a safe and successful flight test of the National Aeronautics and Space Administration (NASA) X-57 Maxwell all-electric experimental airplane, or any X-Plane, is comprehensive system testing on the ground. This test campaign includes verification and validation (V&V) that the integrated system operates as designed and expected, as well as understanding how the system reacts and responds to failures that can occur during flight by performing failure modes and effects testing (FMET). The aircraft should be in the final flight configuration for these test activities because any modifications, even those that appear insignificant, could affect test outcomes. Although the plan was to perform V&V and FMET testing once the airplane was in the flight configuration, due to multiple component redesigns, concurrent software development, and other problems with on-aircraft testing, the X-57 Maxwell never made it into a full-flight configuration. As a result, a build-up approach was followed to test software and hardware as they became ready in order to continue making progress wherever possible. Using this approach revealed problems with the hardware and software faster than waiting for a full-flight configuration, allowing solutions to be found more quickly and in parallel with other project tasks. Other than unloaded motor testing in a lab setting, the only other test setup was on the airplane itself. On-aircraft testing was preferrable in order to test things as close to a flight configuration as possible but was time consuming due to the requirements for testing on the airplane. To overcome some of the on-aircraft barriers, off-aircraft test configurations, such as the Systems Integration Laboratory (SIL) and hardware-in-the-loop (HIL) setups, were used, but each of these setups had limitations to be considered. As a result, solutions found in the SIL or HIL configurations did not always work as expected on the airplane, resulting in an iterative process between on- and off-aircraft testing to find the final solution. Having a dedicated test platform such as an iron bird that closely represents the aircraft - without flight hardware - would have been the most effective off-aircraft test setup, which could have allowed the project to save time and money and potentially reach flight. This paper will highlight the V&V and FMET considerations and testing prerequisites, the build-up approaches to both software and system testing, the benefits and drawbacks to different test configurations, as well as battery testing and operations.

Kassidy M. Mclaughlin↗
NASA NTRSDate not supplied

X-57 Flight Systems Integration Path

The foundation for a safe and successful flight test of the National Aeronautics and Space Administration (NASA) X-57 Maxwell all-electric experimental airplane, or any X-Plane, is comprehensive system testing on the ground. This test campaign includes verification and validation (V&V) that the integrated system operates as designed and expected, as well as understanding how the system reacts and responds to failures that can occur during flight by performing failure modes and effects testing (FMET). The aircraft should be in the final flight configuration for these test activities because any modifications, even those that appear insignificant, could affect test outcomes. Although the plan was to perform V&V and FMET testing once the airplane was in the flight configuration, due to multiple component redesigns, concurrent software development, and other problems with on-aircraft testing, the X-57 Maxwell never made it into a full-flight configuration. As a result, a build-up approach was followed to test software and hardware as they became ready in order to continue making progress wherever possible. Using this approach revealed problems with the hardware and software faster than waiting for a full-flight configuration, allowing solutions to be found more quickly and in parallel with other project tasks. Other than unloaded motor testing in a lab setting, the only other test setup was on the airplane itself. On-aircraft testing was preferrable in order to test things as close to a flight configuration as possible but was time consuming due to the requirements for testing on the airplane. To overcome some of the on-aircraft barriers, off-aircraft test configurations, such as the Systems Integration Laboratory (SIL) and hardware-in-the-loop (HIL) setups, were used, but each of these setups had limitations to be considered. As a result, solutions found in the SIL or HIL configurations did not always work as expected on the airplane, resulting in an iterative process between on- and off-aircraft testing to find the final solution. Having a dedicated test platform such as an iron bird that closely represents the aircraft - without flight hardware - would have been the most effective off-aircraft test setup, which could have allowed the project to save time and money and potentially reach flight. This paper will highlight the V&V and FMET considerations and testing prerequisites, the build-up approaches to both software and system testing, the benefits and drawbacks to different test configurations, as well as battery testing and operations.

Kassidy McLaughlin↗
DOE OSTI2022

Enabling Autonomous Electron Microscopy for Networked Computation and Steering

Advanced electron microscopy workflows require an ecosystem of microscope instruments and computing systems possibly located at different sites to conduct remotely steered and automated experiments. Current workflow executions involve manual operations for steering and measurement tasks, which are typically performed from control workstations co-located with microscopes; consequently, their operational tempo and effectiveness are limited. We propose an approach based on separate data and control channels for such an ecosystem of Scanning Transmission Electron Microscopes (STEM) and computing systems, for which no general solutions presently exist, unlike the neutron and light source instruments. We demonstrate automated measurement transfers and remote steering of Nion STEM physical instruments over site networks. We propose a Virtual Infrastructure Twin (VIT) of this ecosystem, which is used to develop and test our steering software modules without requiring access to the physical instrument infrastructure. Additionally, we develop a VIT for a multiple laboratory scenario, which illustrates the applicability of this approach to ecosystems connected over wide-area networks, for the development and testing of software modules and their later field deployment.

Al Najjar, Anees↗
NASA NTRS1991

Ground Systems Development Environment (GSDE) interface requirements analysis

A set of procedural and functional requirements are presented for the interface between software development environments and software integration and test systems used for space station ground systems software. The requirements focus on the need for centralized configuration management of software as it is transitioned from development to formal, target based testing. This concludes the GSDE Interface Requirements study. A summary is presented of findings concerning the interface itself, possible interface and prototyping directions for further study, and results of the investigation of the Cronus distributed applications environment.

Church, Victor E.↗