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 667 records · Page 37

SDO FlatSat Facility

The goal of the Solar Dynamics Observatory (SDO) is to understand and, ideally, predict the solar variations that influence life and society. It's instruments will measure the properties of the Sun and will take hifh definition images of the Sun every few seconds, all day every day. The FlatSat is a high fidelity electrical and functional representation of the SDO spacecraft bus. It is a high fidelity test bed for Integration & Test (I & T), flight software, and flight operations. For I & T purposes FlatSat will be a driver to development and dry run electrical integration procedures, STOL test procedures, page displays, and the command and telemetry database. FlatSat will also serve as a platform for flight software acceptance and systems testing for the flight software system component including the spacecraft main processors, power supply electronics, attitude control electronic, gimbal control electrons and the S-band communications card. FlatSat will also benefit the flight operations team through post-launch flight software code and table update development and verification and verification of new and updated flight operations products. This document highlights the benefits of FlatSat; describes the building of FlatSat; provides FlatSat facility requirements, access roles and responsibilities; and, and discusses FlatSat mechanical and electrical integration and functional testing.

Amason, David L.↗

NASA software specification and evaluation system: Software verification/validation techniques

NASA software requirement specifications were used in the development of a system for validating and verifying computer programs. The software specification and evaluation system (SSES) provides for the effective and efficient specification, implementation, and testing of computer software programs. The system as implemented will produce structured FORTRAN or ANSI FORTRAN programs, but the principles upon which SSES is designed allow it to be easily adapted to other high order languages.

Source record↗

An Automated Stall-Speed Warning System

The NASA Dryden Flight Research Facility embarked upon a project with the United States Army Aviation Engineering Flight Activity (USAAEFA) to develop and test a stall-speed warning system. NASA designed and built an automated stall-speed warning system which presents both airspeed and stall speed to the pilot. The airspeed and stall speed are computed in real time by monitoring the basic aerodynamic parameters {dynamic pressure, horizontal and vertical accelerations, and pressure altitude) and other parameters (elevator and flap positions, engine torques, and fuel flow). In addition, an aural warning at predetermined stall margins is presented to the pilot through a voice synthesizer. Once the system was designed and installed in the aircraft, a flight-test program of less than 20 hr was anticipated to determine the stall-speed software coefficients. These coefficients would then be inserted in the system's software and then test flown over a period of about 10 hr for the purposes of evaluation.

Pilot↗

An Automated Stall-Speed Warning System

The NASA Dryden Flight Research Facility embarked upon a project with the United States Army Aviation Engineering Flight Activity (USAAEFA) to develop and test a stall-speed warning system. NASA designed and built an automated stall-speed warning system which presents both airspeed and stall speed to the pilot. The airspeed and stall speed are computed in real time by monitoring the basic aerodynamic parameters (dynamic pressure, horizontal and vertical accelerations, and pressure altitude) and other parameters (elevator and flap positions, engine torques, and fuel flow). In addition, an aural warning at predetermined stall margins is presented to the pilot through a voice synthesizer. Once the system was designed and installed in the aircraft, a flight-test program of less than 20 hr was anticipated to determine the stall-speed software coefficients. These coefficients would then be inserted in the system's software and then test flown over a period of about 10 hr for the purposes of evaluation.

Dynamic Pressure↗

Avionics Simulation, Development and Software Engineering

During this reporting period, all technical responsibilities were accomplished as planned. A close working relationship was maintained with personnel of the MSFC Avionics Department Software Group (ED14), the MSFC EXPRESS Project Office (FD31), and the Huntsville Boeing Company. Accomplishments included: performing special tasks; supporting Software Review Board (SRB), Avionics Test Bed (ATB), and EXPRESS Software Control Panel (ESCP) activities; participating in technical meetings; and coordinating issues between the Boeing Company and the MSFC Project Office.

Source record↗

Electrical Impedance Tomography Technology: 2013 Center Innovation Fund Final Report

Electrical impedance tomography is a medical noninvasive imaging technology which has advantages over other medical imaging technologies for medically safe long term real time internal imaging monitoring applications in human patients. The technology is much more compact, portable, low power and potentially more low cost compared to other medical image technologies, making it very well suited for medical aerospace and spaceflight applications. EIT technology’s main drawback has been low image resolution, and consequently improving EIT resolution is the primary research goal, as well as increasing imaging speed for real time animation imaging. In a relatively short time the BERL group has brought together design plans, technical resources and has built and tested hardware with the purpose of improving EIT imaging technology. EIT prototype system development plans and system designs have been made to target needed EIT technical improvement in electronic and computer hardware as well as EIT software technology. New hardware design and fabrication resources and technologies have been brought together through resourceful use of existing equipment and software at BERL, and a significant advance has been made in custom electronic hardware prototyping capabilities in collaboration with EFAL, for mutual benefit for both NASA KSC laboratories. BERL has gained significant EIT software capability and tested EIT imaging algorithm code through collaboration with an internationally recognized EIT software development and research forum. A new custom workstation has been developed, built and tested using internal resources, equipment and expertise, that includes a new state-of-the-art massively parallel technology that is commercially available. Custom prototype hardware has been designed and tested, a high priority electronic design, key to improving electronic performance and image quality, has been researched and tested in four designs, with a summary of test results of the selected design illustrated here. The selected design performance exceeds the developed EIT design hardware specifications.

Michael R Lapointe↗

CFS Test Framework

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.

cfs↗

Flight and Integrated Vehicle Testing: Laying the Groundwork for the Next Generation of Space Exploration Launch Vehicles

Integrated vehicle testing will be critical to ensuring proper vehicle integration of the Ares I crew launch vehicle and Ares V cargo launch vehicle. The Ares Projects, based at Marshall Space Flight Center in Alabama, created the Flight and Integrated Test Office (FITO) as a separate team to ensure that testing is an integral part of the vehicle development process. As its name indicates, FITO is responsible for managing flight testing for the Ares vehicles. FITO personnel are well on the way toward assembling and flying the first flight test vehicle of Ares I, th Ares I-X. This suborbital development flight will evaluate the performance of Ares I from liftoff to first stage separation, testing flight control algorithms, vehicle roll control, separation and recovery systems, and ground operations. Ares I-X is now scheduled to fly in summer 2009. The follow-on flight, Ares I-Y, will test a full five-segment first stage booster and will include cryogenic propellants in the upper stage, an upper stage engine simulator, and an active launch abort system. The following flight, Orion 1, will be the first flight of an active upper stage and upper stage engine, as well as the first uncrewed flight of an Orion spacecraft into orbit. The Ares Projects are using an incremental buildup of flight capabilities prior to the first operational crewed flight of Ares I and the Orion crew exploration vehicle in 2015. In addition to flight testing, the FITO team will be responsible for conducting hardware, software, and ground vibration tests of the integrated launch vehicle. These efforts will include verifying hardware, software, and grou handling interfaces. Through flight and integrated testing, the Ares Projects will identify and mitigate risks early the United States prepares to take its next giant leaps to the Moon and beyond.

Taylor, Jim↗

Flight and Integrated Vehicle Testing: Laying the Groundwork for the Next Generation of Space Exploration Launch Vehicles

Integrated vehicle testing will be critical to ensuring proper vehicle integration of the Ares I crew launch vehicle and Ares V cargo launch vehicle. The Ares Projects, based at Marshall Space Flight Center in Alabama, created the Flight and Integrated Test Office (FITO) as a separate team to ensure that testing is an integral part of the vehicle development process. As its name indicates, FITO is responsible for managing flight testing for the Ares vehicles. FITO personnel are well on the way toward assembling and flying the first flight test vehicle of Ares I, the Ares I-X. This suborbital development flight will evaluate the performance of Ares I from liftoff to first stage separation, testing flight control algorithms, vehicle roll control, separation and recovery systems, and ground operations. Ares I-X is now scheduled to fly in summer 2009. The follow-on flight, Ares I-Y, will test a full five-segment first stage booster and will include cryogenic propellants in the upper stage, an upper stage engine simulator, and an active launch abort system. The following flight, Orion 1, will be the first flight of an active upper stage and upper stage engine, as well as the first uncrewed flight of an Orion spacecraft into orbit. The Ares Projects are using an incremental buildup of flight capabilities prior to the first operational crewed flight of Ares I and the Orion crew exploration vehicle in 2015. In addition to flight testing, the FITO team will be responsible for conducting hardware, software, and ground vibration tests of the integrated launch vehicle. These efforts will include verifying hardware, software, and ground handling interfaces. Through flight and integrated testing, the Ares Projects will identify and mitigate risks early as the United States prepares to take its next giant leaps to the Moon and beyond.

Taylor, J. L.↗

Evaluation of Visualization Software

Visualization software is widely used in scientific and engineering research. But computed visualizations can be very misleading, and the errors are easy to miss. We feel that the software producing the visualizations must be thoroughly evaluated and the evaluation process as well as the results must be made available. Testing and evaluation of visualization software is not a trivial problem. Several methods used in testing other software are helpful, but these methods are (apparently) often not used. When they are used, the description and results are generally not available to the end user. Additional evaluation methods specific to visualization must also be developed. We present several useful approaches to evaluation, ranging from numerical analysis of mathematical portions of algorithms to measurement of human performance while using visualization systems. Along with this brief survey, we present arguments for the importance of evaluations and discussions of appropriate use of some methods.

Globus, Al↗

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 (NASA/MSFC). 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↗

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↗

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↗

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↗

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

SAM Co-Development to Support Fluoride-salt-cooled High-temperature Reactor Design and Licensing (CRADA 2018-18177 Final Report)

This project aims to raise the SAM code's technical and commercial maturity level to enable the Kairos Power ("Kairos") to use SAM to support its KP-FHR design analysis and licensing application. Argonne National Laboratory ("Argonne") has actively developed and maintained SAM, a modern system-level analysis tool for advanced nonlight water reactors safety analysis. Kairos is currently actively pursuing development of an FHR design and associated technology, and consequently requires a pedigreed safety analysis tool. The purpose of this project is to increase the maturity of the SAM code for the modeling and simulation of the KP-FHR design, thus enabling its use in safety analyses that support licensing application. Argonne will primarily be responsible for software design, development, and testing; while Kairos will be responsible for software requirements, assessment of software capabilities, needs, gaps, and priorities, and development of proprietary models. The research and development activities for the joint SAM development project include: a series of identification and prioritization studies on design characteristics, event sequences, relevant phenomena, and software capabilities; SAM capability enhancements for specific KP-FHR systems and components; performing code verification and validations; integrating uncertainty quantification (UQ), model calibration, and sensitivity analysis (SA) techniques in safety analyses; and raising the software quality rigor level for commercial-grade applications.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

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