Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight 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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

Addressing the Real-World Challenges in the Development of Propulsion IVHM Technology Experiment (PITEX)

The Propulsion IVHM Technology Experiment (PITEX) has been an on-going research effort conducted over several years. PITEX has developed and applied a model-based diagnostic system for the main propulsion system of the X-34 reusable launch vehicle, a space-launch technology demonstrator. The application was simulation-based using detailed models of the propulsion subsystem to generate nominal and failure scenarios during captive carry, which is the most safety-critical portion of the X-34 flight. Since no system-level testing of the X-34 Main Propulsion System (MPS) was performed, these simulated data were used to verify and validate the software system. Advanced diagnostic and signal processing algorithms were developed and tested in real-time on flight-like hardware. In an attempt to expose potential performance problems, these PITEX algorithms were subject to numerous real-world effects in the simulated data including noise, sensor resolution, command/valve talkback information, and nominal build variations. The current research has demonstrated the potential benefits of model-based diagnostics, defined the performance metrics required to evaluate the diagnostic system, and studied the impact of real-world challenges encountered when monitoring propulsion subsystems.

Maul, William A.↗
NASA NTRSDate not supplied

High Density Vertiplex: Scalable Autonomous Operations Flight Test

The NASA High Density Vertiport project has completed a multi-aircraft flight test of a scalable autonomous vertiport prototype system. These tests included end to end system integration testing of hardware and software, operational procedure testing of defined roles and responsibilities within a vertiport environment, and human factors data collection. This paper provides an overview of the flight test setup , scenarios, and summary results.

AAM↗
NASA NTRS2013

Space Data Systems Applications in the iPAS Pathfinder Laboratory

The iPAS is an integrated hardware/software test and evaluation environment, in support of current and future spacecraft development The iPAS has two main elements. A common avionics, hardware, and software architecture that can be applied over various missions. A common testbed framework that supports integrated hardware/software testing for a variety of applications. The iPAS includes the following (non-flight qualified) components: Core Flight Software (from GSFC). Commercially available Proton and S950 Flight Computer boards. Power and propulsion systems based on representative flight hardware. A realistic flight deck based on the Multi-Purpose Crew Vehicle (MPCV), including realistic flight controls and displays. A Space Data System based on CCSDS protocols.

Rich, Tom↗
NASA NTRS2003

Flight Test of an Intelligent Flight-Control System

The F-15 Advanced Controls Technology for Integrated Vehicles (ACTIVE) airplane (see figure) was the test bed for a flight test of an intelligent flight control system (IFCS). This IFCS utilizes a neural network to determine critical stability and control derivatives for a control law, the real-time gains of which are computed by an algorithm that solves the Riccati equation. These derivatives are also used to identify the parameters of a dynamic model of the airplane. The model is used in a model-following portion of the control law, in order to provide specific vehicle handling characteristics. The flight test of the IFCS marks the initiation of the Intelligent Flight Control System Advanced Concept Program (IFCS ACP), which is a collaboration between NASA and Boeing Phantom Works. The goals of the IFCS ACP are to (1) develop the concept of a flight-control system that uses neural-network technology to identify aircraft characteristics to provide optimal aircraft performance, (2) develop a self-training neural network to update estimates of aircraft properties in flight, and (3) demonstrate the aforementioned concepts on the F-15 ACTIVE airplane in flight. The activities of the initial IFCS ACP were divided into three Phases, each devoted to the attainment of a different objective. The objective of Phase I was to develop a pre-trained neural network to store and recall the wind-tunnel-based stability and control derivatives of the vehicle. The objective of Phase II was to develop a neural network that can learn how to adjust the stability and control derivatives to account for failures or modeling deficiencies. The objective of Phase III was to develop a flight control system that uses the neural network outputs as a basis for controlling the aircraft. The flight test of the IFCS was performed in stages. In the first stage, the Phase I version of the pre-trained neural network was flown in a passive mode. The neural network software was running using flight data inputs with the outputs provided to instrumentation only. The IFCS was not used to control the airplane. In another stage of the flight test, the Phase I pre-trained neural network was integrated into a Phase III version of the flight control system. The Phase I pretrained neural network provided realtime stability and control derivatives to a Phase III controller that was based on a stochastic optimal feedforward and feedback technique (SOFFT). This combined Phase I/III system was operated together with the research flight-control system (RFCS) of the F-15 ACTIVE during the flight test. The RFCS enables the pilot to switch quickly from the experimental- research flight mode back to the safe conventional mode. These initial IFCS ACP flight tests were completed in April 1999. The Phase I/III flight test milestone was to demonstrate, across a range of subsonic and supersonic flight conditions, that the pre-trained neural network could be used to supply real-time aerodynamic stability and control derivatives to the closed-loop optimal SOFFT flight controller. Additional objectives attained in the flight test included (1) flight qualification of a neural-network-based control system; (2) the use of a combined neural-network/closed-loop optimal flight-control system to obtain level-one handling qualities; and (3) demonstration, through variation of control gains, that different handling qualities can be achieved by setting new target parameters. In addition, data for the Phase-II (on-line-learning) neural network were collected, during the use of stacked-frequency- sweep excitation, for post-flight analysis. Initial analysis of these data showed the potential for future flight tests that will incorporate the real-time identification and on-line learning aspects of the IFCS.

Davidson, Ron↗
NASA NTRS1992

SEDS1 mission software verification using a signal simulator

The first flight of the Small Expendable Deployer System (SEDS1) is schedule to fly as the secondary payload of a Delta 2 in March, 1993. The objective of the SEDS1 mission is to collect data to validate the concept of tethered satellite systems and to verify computer simulations used to predict their behavior. SEDS1 will deploy a 50 lb. instrumented satellite as an end mass using a 20 km tether. Langley Research Center is providing the end mass instrumentation, while the Marshall Space Flight Center is designing and building the deployer. The objective of the experiment is to test the SEDS design concept by demonstrating that the system will satisfactorily deploy the full 20 km tether without stopping prematurely, come to a smooth stop on the application of a brake, and cut the tether at the proper time after it swings to the local vertical. Also, SEDS1 will collect data which will be used to test the accuracy of tether dynamics models used to stimulate this type of deployment. The experiment will last about 1.5 hours and complete approximately 1.5 orbits. Radar tracking of the Delta II and end mass is planned. In addition, the SEDS1 on-board computer will continuously record, store, and transmit mission data over the Delta II S-band telemetry system. The Data System will count tether windings as the tether unwinds, log the times of each turn and other mission events, monitor tether tension, and record the temperature of system components. A summary of the measurements taken during the SEDS1 are shown. The Data System will also control the tether brake and cutter mechanisms. Preliminary versions of two major sections of the flight software, the data telemetry modules and the data collection modules, were developed and tested under the 1990 NASA/ASEE Summer Faculty Fellowship Program. To facilitate the debugging of these software modules, a prototype SEDS Data System was programmed to simulate turn count signals. During the 1991 summer program, the concept of simulating signals produced by the SEDS electronics systems and circuits was expanded and more precisely defined. During the 1992 summer program, the SEDS signal simulator was programmed to test the requirements of the SEDS Mission software, and this simulator will be used in the formal verification of the SEDS Mission Software. The formal test procedures specification was written which incorporates the use of the signal simulator to test the SEDS Mission Software and which incorporates procedures for testing the other major component of the SEDS software, the Monitor Software.

Pierson, William E.↗
NASA NTRS2000

Support to X-33/Resusable Launch Vehicle Technology Program

The X-33 Guidance, Navigation, and Control (GN&C) Peer Review Team (PRT) was formed to assess the integrated X-33 vehicle GN&C system in order to identify any areas of disproportionate risk for initial flight. The eventual scope of the PRT assessment encompasses the GN&C algorithms, software, avionics, control effectors, applicable models, and testing. The initial (phase 1) focus of the PRT was on the GN&C algorithms and the Flight Control Actuation Subsystem (FCAS). The PRT held meetings during its phase 1 assessment at X-33 assembly facilities in Palmdale, California on May 17-18, 2000 and at Honeywell facilities in Tempe, Arizona on June 7, 2000. The purpose of these meetings was for the PRT members to get background briefings on the X-33 vehicle and for the PRT team to be briefed on the design basis and current status of the X-33 GN&C algorithms as well as the FCAS. The following material is covered in this PRT phase 1 final report. Some significant GN&C-related accomplishments by the X-33 development team are noted. Some topics are identified that were found during phase 1 to require fuller consideration when the PRT reconvenes in the future. Some new recommendations by the PRT to the X-33 program will likely result from a thorough assessment of these subjects. An initial list of recommendations from the PRT to the X-33 program is provided. These recommendations stem from topics that received adequate review by the PRT in phase 1. Significant technical observations by the PRT members as a result of the phase 1 meetings are detailed. (These are covered in an appendix.) There were many X-33 development team members who contributed to the technical information used by the PRT during the phase 1 assessment, who supported presentations to the PRT, and who helped to address the many questions posed by the PRT members at and after the phase 1 meetings. In all instances the interaction between the PRT and the X-33 development team members was cordial and very professional. The members of the PRT are grateful for the time and effort applied by all of these individuals and hope that the contents of this report will help to make the X-33 program a success.

Source record↗
NASA NTRS1985

A comparison of software verification techniques

A controlled experiment performed by the Software Engineering Laboratory (SEL) to compare the effectiveness of code reading, functional testing, and structural testing as software verification techniques is described. The experiment results indicate that code reading provides the greatest error detection capability at the lowest cost, whereas structural testing is the least effective technique. The experiment plan is explained, the experiment results are described, related results from other studies are discussed. The application of these results to the development of software in the flight dynamics environment is considered. Appendices summarize the experiment data and list the test programs.

Source record↗
NASA NTRS1985

Space shuttle main engine hardware simulation

The Huntsville Simulation Laboratory (HSL) provides a simulation facility to test and verify the space shuttle main engine (SSME) avionics and software system using a maximum complement of flight type hardware. The HSL permits evaluations and analyses of the SSME avionics hardware, software, control system, and mathematical models. The laboratory has performed a wide spectrum of tests and verified operational procedures to ensure system component compatibility under all operating conditions. It is a test bed for integration of hardware/software/hydraulics. The HSL is and has been an invaluable tool in the design and development of the SSME.

Vick, H. G.↗
NASA NTRS2017

Upgrades to Common Data Acquisition System Software Development for NASA's Rocket Propulsion Test Facilities and Software Reuse

Approximately five years ago, the National Aeronautics and Space Administration (NASA) Stennis Space Center (SSC) resumed operation of its large rocket engine test facilities after thirty years of contractor control. During this period, contactors used their own proprietary Data Acquisition System (DAS) to record and process rocket propulsion test data. The transition from a contractor managed facility to a NASA managed facility posed a difficult challenge. In order to support the commercial space launch initiative, SSC needed to develop a software replacement for the contractor proprietary DAS. This replacement software would enable SSC to operate propulsion test facilities more cost effectively and to be more readily able to adapt software for reuse, while at the same time provide internal and external customers with reliable population test data. Therefore, SSC developed in-house, a non-proprietary software suite of applications to replace the previously used proprietary DAS. The requirements for the DAS suite included recording and processing propulsion test data. This capability eliminates the necessity for customers to provide a DAS or rely on a competitor's DAS. An additional benefit of owning the software suite included enabling the ability to add additional features and functionality at a lower cost. The Rocket Propulsion Test (RPT) Program Office reviewed consideration for funding this project with the caveat that development of the software included availability for use with minimal modifications to all SSC test facilities and RPT centers: Marshall Space Flight Center (MSFC), White Sands Test Facility (WSTF), and Glenn Research Center (GRC) Plum Brook Station. Based upon this guideline, SSC created the NASA Data Acquisition System (NDAS) software suite. The ability to use the software at multiple centers, even though each field center uses differing DAS hardware with different capabilities, drove a requirement that the software design be portable with minimal modifications to the software. Then, with software release requirements, evaluations, and approvals completed, the NDAS software suite could also become available to other government agencies, corporations, universities, and the general United States public.

Herbert, Phillip W., Sr.↗
NASA NTRS1989

Evolution of Ada technology in the flight dynamics area: Implementation/testing phase analysis

An analysis is presented of the software engineering issues related to the use of Ada for the implementation and system testing phases of four Ada projects developed in the flight dynamics area. These projects reflect an evolving understanding of more effective use of Ada features. In addition, the testing methodology used on these projects has changed substantially from that used on previous FORTRAN projects.

Quimby, Kelvin L.↗
NASA NTRS2017

Numerical Modeling of an Integrated Vehicle Fluids System Loop for Pressurizing a Cryogenic Tank

This paper presents a numerical model of the pressurization loop of the Integrated Vehicle Fluids (IVF) system using the Generalized Fluid System Simulation Program (GFSSP). The IVF propulsion system, being developed by United Launch Alliance to reduce system weight and enhance reliability, uses boiloff propellants to drive thrusters for the reaction control system as well as to run internal combustion engines to develop power and drive compressors to pressurize propellant tanks. NASA Marshall Space Flight Center (MSFC) conducted tests to verify the functioning of the IVF system using a flight-like tank. GFSSP, a finite volume based flow network analysis software developed at MSFC, has been used to support the test program. This paper presents the simulation of three different test series, comparison of numerical prediction and test data and a novel method of presenting data in a dimensionless form. The paper also presents a methodology of implementing a compressor map in a system level code.

LeClair, A. C.↗
NASA NTRS2009

Implementation of an Adaptive Controller System from Concept to Flight Test

The National Aeronautics and Space Administration Dryden Flight Research Center (Edwards, California) is conducting ongoing flight research using adaptive controller algorithms. A highly modified McDonnell-Douglas NF-15B airplane called the F-15 Intelligent Flight Control System (IFCS) is used to test and develop these algorithms. Modifications to this airplane include adding canards and changing the flight control systems to interface a single-string research controller processor for neural network algorithms. Research goals include demonstration of revolutionary control approaches that can efficiently optimize aircraft performance in both normal and failure conditions and advancement of neural-network-based flight control technology for new aerospace system designs. This report presents an overview of the processes utilized to develop adaptive controller algorithms during a flight-test program, including a description of initial adaptive controller concepts and a discussion of modeling formulation and performance testing. Design finalization led to integration with the system interfaces, verification of the software, validation of the hardware to the requirements, design of failure detection, development of safety limiters to minimize the effect of erroneous neural network commands, and creation of flight test control room displays to maximize human situational awareness; these are also discussed.

Larson, Richard R.↗
NASA NTRSDate not supplied

S-Band Transponder Multi-Network Compatibility, Space Environment and Radiation Testing

This paper presents the development and testing of the Software Define Radio (SDR) transceiver to meet the emerging needs for SmallSat communication and navigation. Vulcan Wireless and NASA Goddard Space Flight Center (GSFC) collaborated in testing the Vulcan Wireless S-band SDR engineering model. Apart from testing, communication link analysis was performed for a Low Earth Orbit (LEO) 400 km scenario. The results of the compatibility, radiation, environmental testing, and link analysis are presented. Also, this paper reviews a set of SmallSat missions under development at NASA GSFC.

Software Define Radio, transceiver, S-band↗
NASA NTRS1999

Automated Testing Experience of the Linear Aerospike SR-71 Experiment (LASRE) Controller

System controllers must be fail-safe, low cost, flexible to software changes, able to output health and status words, and permit rapid retest qualification. The system controller designed and tested for the aerospike engine program was an attempt to meet these requirements. This paper describes (1) the aerospike controller design, (2) the automated simulation testing techniques, and (3) the real time monitoring data visualization structure. Controller cost was minimized by design of a single-string system that used an off-the-shelf 486 central processing unit (CPU). A linked-list architecture, with states (nodes) defined in a user-friendly state table, accomplished software changes to the controller. Proven to be fail-safe, this system reported the abort cause and automatically reverted to a safe condition for any first failure. A real time simulation and test system automated the software checkout and retest requirements. A program requirement to decode all abort causes in real time during all ground and flight tests assured the safety of flight decisions and the proper execution of mission rules. The design also included health and status words, and provided a real time analysis interpretation for all health and status data.

Larson, Richard R.↗
NASA NTRS2015

Generation of Simulated Tracking Data for LADEE Operational Readiness Testing

Operational Readiness Tests were an important part of the pre-launch preparation for the LADEE mission. The generation of simulated tracking data to stress the Flight Dynamics System and the Flight Dynamics Team was important for satisfying the testing goal of demonstrating that the software and the team were ready to fly the operational mission. The simulated tracking was generated in a manner to incorporate the effects of errors in the baseline dynamical model, errors in maneuver execution and phenomenology associated with various tracking system based components. The ability of the mission team to overcome these challenges in a realistic flight dynamics scenario indicated that the team and flight dynamics system were ready to fly the LADEE mission. Lunar Atmosphere and Dust Environment.

Tracking↗
NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗
NASA NTRSDate not supplied

Design and Testing of an Approach to Automated In-Flight Safety Risk Management for sUAS Operations

An onboard risk management automation design is presented based on run-time assurance principles, as well as the concept for In-Time Aviation Safety Management Systems (IASMS) as described by the National Academies. The automation is designed to operate independently of the autopilot and perform real-time risk assessment spanning multiple classes of hazards, predict constraint violations, and track autopilot states. In the event of elevated risk conditions or predicted constraint violations, the automation will select from a set of available contingencies and trigger autopilot mode changes if necessary to mitigate risk exposure. The onboard automation also informs the remote operator/pilot of what the independent monitor is observing and any contingency decisions or actions that may arise during flight. Details of an implementation of this design and results of verification and validation activities, as required to meet stringent NASA software and system assurance standards, are also presented. This includes simulation and flight testing using small unmanned aircraft systems.

Ersin Ancel↗
NASA NTRS1993

Cooperative GN&C development in a rapid prototyping environment

The Navigation, Control and Aeronautics Division (NCAD) at NASA-JSC is exploring ways of producing Guidance, Navigation and Control (GN&C) flight software faster, better, and cheaper. To achieve these goals NCAD established two hardware/software facilities that take an avionics design project from initial inception through high fidelity real-time hardware-in-the-loop testing. Commercially available software products are used to develop the GN&C algorithms in block diagram form and then automatically generate source code from these diagrams. A high fidelity real-time hardware-in-the-loop laboratory provides users with the capability to analyze mass memory usage within the targeted flight computer, verify hardware interfaces, conduct system level verification, performance, acceptance testing, as well as mission verification using reconfigurable and mission unique data. To evaluate these concepts and tools, NCAD embarked on a project to build a real-time 6 DOF simulation of the Soyuz Assured Crew Return Vehicle flight software. To date, a productivity increase of 185 percent has been seen over traditional NASA methods for developing flight software.

Bordano, Aldo↗