Search NASA⌕ Search

SEARCH · Search NASA

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 469 records · Page 26

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↗

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↗

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 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↗

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 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↗

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↗

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↗

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.↗

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↗

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↗

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↗

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.↗

Validation of NSSC-I software for the Hubble Space Telescope

This paper describes the simulation and test methods used to ensure that the NASA Standard Spacecraft Computer, Model 1, (NSSC-I) flight software for the Hubble Space Telescope properly carries out its requirements for control of scientific observations and for monitoring the health and safety of the payload. The hardware and software test environment is discussed. The different kinds of tests (unit, special real time, and stress tests) that are performed before the software is incorporated into the flight system are described, and the kinds of errors that each test category is best suited to find are listed. Finally, the limitations of the tests are discussed, and current plans for enhancing the test environment are outlined.

Foley, Glenn↗

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗

Measuring Software-Execution Time

Test circuit times routines even during multiprogram operation. Circuit generates pulse started by signal at beginning address of program under test and ended by signal at ending address. Pulse duration measured with logic analyzer to determine execution time.

Pinera, C.↗

GPS and Galileo Developments on Board the International Space Station With the Space Communications and Navigation (SCaN) Testbed

The Space Communications and Navigation (SCaN) is a facility developed by NASA and hosted on board the International Space Station (ISS) on an external truss since 2013.It has the objective of testing navigation and communication experimentations with a Software Defined Radio (SDR) approach, which permits software updates for testing new experimentations.NASA has developed the Space Telecommunications Radio System (STRS) architecture standard for SDRs used in space and ground-based platforms to provide commonality among radio developments to provide enhanced capability. The hardware is equipped with both L band front-end radios and the NASA space network communicates with it using S-band, Ku-band and Ka-band links.In May 2016 Qascom started GARISS (GPS and Galileo Receiver for the ISS), an activity of experimentation in collaboration with ESA and NASA that has the objective to develop and validate the acquisition and processing of combined GPS and Galileo signals on board the ISS SCaN testbed. This paper has the objective to present the mission, and provide preliminary details about the challenges in the design, development and verification of the waveform that will be installed on equipment with limited resources. GARISS is also the first attempt to develop a waveform for the ISS as part of an international collaboration between US and Europe. Although the final mission objective is to target dual frequency processing, initial operations will foresee a single frequency processing. Initial results and trade-off between the two options, as well as the final decision will be presented and discussed. The limited resources on board the SCaN with respect to the challenging requirements to acquire and track contemporaneously two satellite navigation systems, with different modulations and data structure, led to the need to assess the possibility of aiding from ground through the S-band. This option would allow assistance to the space receiver in order to provide knowledge of GNSS orbits and reduce the processing on board. Trade off and various options for telemetry and uplink data are presented and discussed. Finally, integration and validation of the waveform are one of the major challenges of GARISS: The Experiment Development System (EDS) and the the Ground Integration Unit (GIU) for VV will be used prior to conducting the experiment on the ISS. The EDS can be used in lab environment and allows prototyping and verification activities with the simulator, but does not include all hardware components. The GIU on the other side is the flight model which replicates the flying equipment, but has limited flexibility for testing.As conclusion, the project is now approaching the Preliminary Design Review (PDR) and indeed only preliminary results are available. This paper is an opportunity to present the GARISS mission as part of an International cooperation between ESA, NASA and Qascom. The preliminary results include GPS and Galileo processing from space signals, the challenges and trade off decisions, the high level STRS architecture and foreseen experimentation campaign. Detailed results from the test campaigns are expected in 2017.

space navigation↗