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 595 records · Page 33
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Simulation of Non-Acoustic Combustion Instability in a Hybrid Rocket Motor

A transient model of a hybrid motor was formulated to study the cause and elimination of non-acoustic combustion instability. The transient model was used to simulate four key tests out of a series of seventeen hybrid motor tests conducted by Thiokol, Rocketdyne and Martin Marietta at NASA/Marshall Space Flight Center (NASAIMSFC). These tests were performed under the Hybrid Propulsion Technology for Launch Vehicle Boosters (HPTLVB) program. The first test resulted in stable combustion. The second test resulted in large-amplitude, 6.5 Hz chamber pressure oscillations that gradually damped away by the end of the test. The third test resulted in large-amplitude, 7.5 Hz chamber pressure oscillations that were sustained throughout the test. The seventh test resulted in the elimination of combustion instability with the installation of an orifice immediately upstream of the injector. The formulation and implementation of the model are the scope of this presentation. The current model is an independent continuation of modeling presented previously by joint Thiokol-Rocketdyne collaborators Boardman, Hawkins, Wassom, and Claflin. The previous model simulated an unstable IR&D hybrid motor test performed by Thiokol. There was very good agreement between the model and the test data. Like the previous model, the current model was developed using Matrix-x simulation software. However, the tests performed at NASA/MSFC under the HPTLVB program were actually simulated. In the current model, the hybrid motor consisting of the liquid oxygen (LOX) injector, the multi-port solid fuel grain and the nozzle was simulated. Also, simulated in the model was the LOX feed system consisting of the tank, venturi, valve and feed lines. All components of the hybrid motor and LOX feed system are treated by a lumped-parameter approach. Agreement between the results of the transient model and the actual test data was very good. This agreement between simulated and actual test data indicated that the combustion instability in the hybrid motor was due to two causes. The first cause was a LOX feed system of insufficient stiffness. The second cause was a LOX injector with an impedance or pressure drop that was too low to provide damping against the feed system oscillations. Also, it was discovered that testing with a new grain of solid fuel sustained the combustion instability. However, testing with a used grain of solid fuel caused the combustion instability to gradually decay.

Rocker, Marvin↗
NASA NTRS2016

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗
NASA NTRS2022

Developing High Performance Space Networking Capabilities for the International Space Station and Beyond

A performance optimized implementation of Delay Tolerant Networking (DTN) with the capacity of gigabit-per second rates is developed for the International Space Station (ISS) and missions demanding large amounts of communications bandwidth. An overview of the High-rate Delay Tolerant Networking (HDTN) architecture and support for different convergence layers is provided. This paper then presents an overview of the testing and integration efforts to evaluate interoperability and capability in relevant environments. The first was interoperability testing with DTN Marshall Enterprise (DTNME) which resulted in near-gigabit per second data rates. This was followed by ISS emulation testing with the Software Development and Integration Laboratory (SDIL) at the Lyndon B. Johnson Space Center (JSC) and local testing based on the ISS DTN network topology. The local tests resulted in the discovery of potential sources of performance loss in the network and demonstrated near-gigabit rates between HDTN and DTNME.

Daniel Raible↗
NASA NTRS1981

Cleanroom software development

The 'cleanroom' software development process is a technical and organizational approach to developing software with certifiable reliability. Key ideas behind the process are well structured software specifications, randomized testing methods and the introduction of statistical controls; but the main point is to deny entry for defects during the development of software. This latter point suggests the use of the term 'cleanroom' in analogy to the defect prevention controls used in the manufacturing of high technology hardware. In the 'cleanroom', the entire software development process is embedded within a formal statistical design, in contrast to executing selected tests and appealing to the randomness of operational settings for drawing statistical inferences. Instead, random testing is introduced as a part of the statistical design itself so that when development and testing are completed, statistical inferences are made about the operation of the system.

Dyer, M.↗
NASA NTRS2007

Software for Automated Image-to-Image Co-registration

The project objectives are: a) Develop software to fine-tune image-to-image co-registration, presuming images are orthorectified prior to input; b) Create a reusable software development kit (SDK) to enable incorporation of these tools into other software; d) provide automated testing for quantitative analysis; and e) Develop software that applies multiple techniques to achieve subpixel precision in the co-registration of image pairs.

Benkelman, Cody A.↗
NASA NTRS2015

NASA Operational Simulator for Small Satellites (NOS3)

The Simulation-to-Flight 1 (STF-1) CubeSat mission aims to demonstrate how legacy simulation technologies may be adapted for flexible and effective use on missions using the CubeSat platform. These technologies, named NASA Operational Simulator (NOS), have demonstrated significant value on several missions such as James Webb Space Telescope, Global Precipitation Measurement, Juno, and Deep Space Climate Observatory in the areas of software development, mission operationstraining, verification and validation (VV), test procedure development and software systems check-out. STF-1 will demonstrate a highly portable simulation and test platform that allows seamless transition of mission development artifacts to flight products. This environment will decrease development time of future CubeSat missions by lessening the dependency on hardware resources. In addition, through a partnership between NASA GSFC, the West Virginia Space Grant Consortium and West Virginia University, the STF-1 CubeSat will hosts payloads for three secondary objectives that aim to advance engineering and physical-science research in the areas of navigation systems of small satellites, provide useful data for understanding magnetosphere-ionosphere coupling and space weather, and verify the performance and durability of III-V Nitride-based materials.

modeling simulation↗
NASA NTRSDate not supplied

An Experimental System for Strategic Flight Path Management in Advanced Air Mobility

In the concept envisioned for Urban Air Mobility (UAM) operations, fleets of electric vertical takeoff and landing (eVTOL) vehicles would operate between vertiports distributed within a densely populated area. These operations would be largely independent from the existing air traffic control system and would place the responsibility for flight planning and aircraft separation on fleet operators. The fourth major level on the UAM Maturity Level scale, UML-4, relies on “collaborative and responsible” automation to enable operations in non-visual conditions with medium traffic density (hundreds of aircraft in one metropolitan region) and medium complexity. This level of service places many requirements on automation systems to assist the operators of these aircraft. NASA has developed the Autonomous Operations Planner (AOP), a reference prototype Flight Path Management automation system, and has modified AOP to support research of anticipated UML-4 operations. AOP creates a four-dimensional flight plan conforming to the constraints of these operations, evaluates and modifies the flight plan during flight as conditions and constraints evolve, and coordinates the flight plan with other airspace users and with service providers. This version of AOP has been integrated into the Sikorsky Autonomy Research Aircraft and used in a flight test activity. In this paper we discuss anticipated characteristics of UAM operations, modifications that were made to AOP to adapt to that environment or to support the flight test, and observations of software and aircraft performance during the flight test. The aircraft achieved four-dimensional conformance with the flight plan and AOP provided adequate planning in almost all cases. We discuss improvements that could be made to AOP to address deficiencies that were observed.

Autonomous Operations Planner↗
NASA NTRSDate not supplied

An Experimental System for Strategic Flight Path Management in Advanced Air Mobility

In the concept envisioned for Urban Air Mobility (UAM) operations, fleets of electric vertical takeoff and landing (eVTOL) vehicles would operate between vertiports distributed within a densely populated area. These operations would be largely independent from the existing air traffic control system and would place the responsibility for flight planning and aircraft separation on fleet operators. The fourth major level on the UAM Maturity Level scale, UML-4, relies on “collaborative and responsible” automation to enable operations in non-visual conditions with medium traffic density (hundreds of aircraft in one metropolitan region) and medium complexity. This level of service places many requirements on automation systems to assist the operators of these aircraft. NASA has developed the Autonomous Operations Planner (AOP), a reference prototype Flight Path Management automation system, and has modified AOP to support research of anticipated UML-4 operations. AOP creates a four-dimensional flight plan conforming to the constraints of these operations, evaluates and modifies the flight plan during flight as conditions and constraints evolve, and coordinates the flight plan with other airspace users and with service providers. This version of AOP has been integrated into the Sikorsky Autonomy Research Aircraft and used in a flight test activity. In this paper we discuss anticipated characteristics of UAM operations, modifications that were made to AOP to adapt to that environment or to support the flight test, and observations of software and aircraft performance during the flight test. The aircraft achieved four-dimensional conformance with the flight plan and AOP provided adequate planning in almost all cases. We discuss improvements that could be made to AOP to address deficiencies that were observed.

Autonomous Operations Planner↗
NASA NTRS1994

Software analysis handbook: Software complexity analysis and software reliability estimation and prediction

This handbook documents the three software analysis processes the Space Station Software Analysis team uses to assess space station software, including their backgrounds, theories, tools, and analysis procedures. Potential applications of these analysis results are also presented. The first section describes how software complexity analysis provides quantitative information on code, such as code structure and risk areas, throughout the software life cycle. Software complexity analysis allows an analyst to understand the software structure, identify critical software components, assess risk areas within a software system, identify testing deficiencies, and recommend program improvements. Performing this type of analysis during the early design phases of software development can positively affect the process, and may prevent later, much larger, difficulties. The second section describes how software reliability estimation and prediction analysis, or software reliability, provides a quantitative means to measure the probability of failure-free operation of a computer program, and describes the two tools used by JSC to determine failure rates and design tradeoffs between reliability, costs, performance, and schedule.

Computer systems design↗
NASA NTRS2006

Control Software for Advanced Video Guidance Sensor

Embedded software has been developed specifically for controlling an Advanced Video Guidance Sensor (AVGS). A Video Guidance Sensor is an optoelectronic system that provides guidance for automated docking of two vehicles. Such a system includes pulsed laser diodes and a video camera, the output of which is digitized. From the positions of digitized target images and known geometric relationships, the relative position and orientation of the vehicles are computed. The present software consists of two subprograms running in two processors that are parts of the AVGS. The subprogram in the first processor receives commands from an external source, checks the commands for correctness, performs commanded non-image-data-processing control functions, and sends image data processing parts of commands to the second processor. The subprogram in the second processor processes image data as commanded. Upon power-up, the software performs basic tests of functionality, then effects a transition to a standby mode. When a command is received, the software goes into one of several operational modes (e.g. acquisition or tracking). The software then returns, to the external source, the data appropriate to the command.

Howard, Richard T.↗
NASA NTRS2014

GeoLab: A Geological Workstation for Future Missions

The GeoLab glovebox was, until November 2012, fully integrated into NASA's Deep Space Habitat (DSH) Analog Testbed. The conceptual design for GeoLab came from several sources, including current research instruments (Microgravity Science Glovebox) used on the International Space Station, existing Astromaterials Curation Laboratory hardware and clean room procedures, and mission scenarios developed for earlier programs. GeoLab allowed NASA scientists to test science operations related to contained sample examination during simulated exploration missions. The team demonstrated science operations that enhance theThe GeoLab glovebox was, until November 2012, fully integrated into NASA's Deep Space Habitat (DSH) Analog Testbed. The conceptual design for GeoLab came from several sources, including current research instruments (Microgravity Science Glovebox) used on the International Space Station, existing Astromaterials Curation Laboratory hardware and clean room procedures, and mission scenarios developed for earlier programs. GeoLab allowed NASA scientists to test science operations related to contained sample examination during simulated exploration missions. The team demonstrated science operations that enhance the early scientific returns from future missions and ensure that the best samples are selected for Earth return. The facility was also designed to foster the development of instrument technology. Since 2009, when GeoLab design and construction began, the GeoLab team [a group of scientists from the Astromaterials Acquisition and Curation Office within the Astromaterials Research and Exploration Science (ARES) Directorate at JSC] has progressively developed and reconfigured the GeoLab hardware and software interfaces and developed test objectives, which were to 1) determine requirements and strategies for sample handling and prioritization for geological operations on other planetary surfaces, 2) assess the scientific contribution of selective in-situ sample characterization for mission planning, operations, and sample prioritization, 3) evaluate analytical instruments and tools for providing efficient and meaningful data in advance of sample return and 4) identify science operations that leverage human presence with robotic tools. In the first year of tests (2010), GeoLab examined basic glovebox operations performed by one and two crewmembers and science operations performed by a remote science team. The 2010 tests also examined the efficacy of basic sample characterization [descriptions, microscopic imagery, X-ray fluorescence (XRF) analyses] and feedback to the science team. In year 2 (2011), the GeoLab team tested enhanced software and interfaces for the crew and science team (including Web-based and mobile device displays) and demonstrated laboratory configurability with a new diagnostic instrument (the Multispectral Microscopic Imager from the JPL and Arizona State University). In year 3 (2012), the GeoLab team installed and tested a robotic sample manipulator and evaluated robotic-human interfaces for science operations.

Evans, Cynthia↗
NASA NTRS2017

NASA's Space Launch System Takes Shape

Major hardware and software for NASA's Space Launch System (SLS) began rolling off assembly lines in 2016, setting the stage for critical testing in 2017 and the launch of a major new capability for deep space human exploration. SLS continues to pursue a 2018 first launch of Exploration Mission 1 (EM-1). At NASA's Michoud Assembly Facility near New Orleans, LA, Boeing completed welding of structural test and flight liquid hydrogen tanks, and engine sections. Test stands for core stage structural tests at NASA's Marshall Space Flight Center, Huntsville, AL. neared completion. The B2 test stand at NASA's Stennis Space Center, MS, completed major structural renovation to support core stage green run testing in 2018. Orbital ATK successfully test fired its second qualification solid rocket motor in the Utah desert and began casting the motor segments for EM-1. Aerojet Rocketdyne completed its series of test firings to adapt the heritage RS-25 engine to SLS performance requirements. Production is under way on the first five new engine controllers. NASA also signed a contract with Aerojet Rocketdyne for propulsion of the RL10 engines for the Exploration Upper Stage. United Launch Alliance delivered the structural test article for the Interim Cryogenic Propulsion Stage to MSFC for tests and construction was under way on the flight stage. Flight software testing at MSFC, including power quality and command and data handling, was completed. Substantial progress is planned for 2017. Liquid oxygen tank production will be completed at Michoud. Structural testing at Marshall will get under way. RS-25 hotfire testing will verify the new engine controllers. Core stage horizontal integration will begin. The core stage pathfinder mockup will arrive at the B2 test stand for fit checks and tests. EUS will complete preliminary design review. This paper will discuss the technical and programmatic successes and challenges of 2016 and look ahead to plans for 2017.

Askins, Bruce↗
NASA NTRS2009

Importance of Model Simulations in Cassini In-Flight Mission Events

Simulation environments have been an integral part of Cassini's heritage. From the time of flight software development and testing to the beginning of the spacecraft's extended mission operations, both softsim and hardware-in-the-loop testbeds have played vital roles in verifying and validating key mission events. Satellite flybys and mission-critical events have established the need to model Titan's atmospheric torque, Enceladus' plume density, and other key parametric spacecraft environments. This paper will focus on enhancements to Cassini's Flight Software Development System (FSDS) and Integrated Test Laboratory (ITL) to model key event attributes which establish valid test environments and ensure safe spacecraft operability. Comparisons between simulated to in-flight data are presented which substantiate model validity.

FSDS↗
NASA NTRS2014

More Than A SketchUp

This 2014 summer internship assignment at John F. Kennedy Space Center (K.S.C) was conducted with the National Aeronautics and Space Administration (NASA) Engineering and Technology (NE) group in support of the Control and Data Systems Division (NE-C) within the Test, Operations & Support Software Engineering Branch (NE-C2). The primary focus of this project was to assist Branch Chief Laurie B. Griffin, to support NASA's Small Payload Launch Integrated Testing Services (SPLITS) mission, by mastering the capabilities of 3-D modeling software called SketchUp. I used SketchUp to create a virtual environment for different laboratories of the NE-00 Division. My mission was to have these models uploaded into a K.S.C Partnerships Website and be used as a visual aid to viewers who browsed the site. The leads of this project were Kay L. Craig, Business and Industry Specialist (AD-A) and Steven E. Cain, (FA-C). I teamed with fellow intern Tait Sorenson of the Flight Structures and Thermal Protection Systems Branch (NE-M5) and met with many K.S.C lab managers willing to display their lab's structure and capabilities. The information collected during these lab tours was vital to the building of the K.S.C Partnerships Website. To accomplish this goal Sorenson and I later teamed with fellow Marketing intern Marlee Pereda-Ramos, of the Spaceport Planning Office In Center Planning And Development (AD-A) Along with Ramos, Tait and I toured an array of laboratories and got first hand exposure to their functions and capabilities.

Trimble Corporation↗
NASA NTRS2012

Development of the GPM Observatory Thermal Vacuum Test Model

A software-based thermal modeling process was documented for generating the thermal panel settings necessary to simulate worst-case on-orbit flight environments in an observatory-level thermal vacuum test setup. The method for creating such a thermal model involved four major steps: (1) determining the major thermal zones for test as indicated by the major dissipating components on the spacecraft, then mapping the major heat flows between these components; (2) finding the flight equivalent sink temperatures for these test thermal zones; (3) determining the thermal test ground support equipment (GSE) design and initial thermal panel settings based on the equivalent sink temperatures; and (4) adjusting the panel settings in the test model to match heat flows and temperatures with the flight model. The observatory test thermal model developed from this process allows quick predictions of the performance of the thermal vacuum test design. In this work, the method described above was applied to the Global Precipitation Measurement (GPM) core observatory spacecraft, a joint project between NASA and the Japanese Aerospace Exploration Agency (JAXA) which is currently being integrated at NASA Goddard Space Flight Center for launch in Early 2014. From preliminary results, the thermal test model generated from this process shows that the heat flows and temperatures match fairly well with the flight thermal model, indicating that the test model can simulate fairly accurately the conditions on-orbit. However, further analysis is needed to determine the best test configuration possible to validate the GPM thermal design before the start of environmental testing later this year. Also, while this analysis method has been applied solely to GPM, it should be emphasized that the same process can be applied to any mission to develop an effective test setup and panel settings which accurately simulate on-orbit thermal environments.

Yang, Kan↗
NASA NTRSDate not supplied

NEUROSPF: A Tool For the Symbolic Analysis of Neural Networks

This paper presents NEUROSPF, a tool for the symbolic analysis of neural networks. Given a trained neural network model, the tool extracts the architecture and model parameters and translates them into a Java representation that is amenable for analysis using the Symbolic PathFinder symbolic execution tool. Notably, NEUROSPF encodes specialized peer classes for parsing the model’s parameters, thereby enabling efficient analysis. With NEUROSPF the user has the flexibility to specify either the inputs or the network internal parameters as symbolic, promoting the application of program analysis and testing approaches from software engineering to the field of machine learning. For instance, NEUROSPF can be used for coverage-based testing and test generation, finding adversarial examples and also constraint-based repair of neural networks, thus improving the reliability of neural networks and of the applications that use them.

neural networks↗
NASA NTRS1977

Data processing system and interfacing elements time base analysis

The processing of time in the Orbiter System Services software and the associated facilities provided to the user community are described. The descriptions are directed toward showing the functional intent of the design rather than the actual implementation. Simplified flow diagrams are included. Based upon detailed analysis of a preliminary review copy of the Approach and Landing Test (ALT) System Software Detailed Design Specification and the Program Listings for Version 17 Prime, the processing of time has the potential for error free operations. The processing of time is not expected to change between ALT and the Operational Flight Test (OFT) other than differences in value of some constants for control and limit checking. Due to the dynamic nature of onboard time processing and its criticality to the successful operation of the orbiter, it is recommended that a comprehensive list of external variables, their locations, initial values, and a 'where used' listing be produced, as a by-product of the link edit process, for all non-HAL coding. In addition, a careful review of the verification test procedures for the System Services time-related software is recommended.

Blackburn, J. D.↗
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↗