Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software design”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Case Study: Test Results of a Tool and Method for In-Flight, Adaptive Control System Verification on a NASA F-15 Flight Research Aircraft

Adaptive control technologies that incorporate learning algorithms have been proposed to enable autonomous flight control and to maintain vehicle performance in the face of unknown, changing, or poorly defined operating environments [1-2]. At the present time, however, it is unknown how adaptive algorithms can be routinely verified, validated, and certified for use in safety-critical applications. Rigorous methods for adaptive software verification end validation must be developed to ensure that. the control software functions as required and is highly safe and reliable. A large gap appears to exist between the point at which control system designers feel the verification process is complete, and when FAA certification officials agree it is complete. Certification of adaptive flight control software verification is complicated by the use of learning algorithms (e.g., neural networks) and degrees of system non-determinism. Of course, analytical efforts must be made in the verification process to place guarantees on learning algorithm stability, rate of convergence, and convergence accuracy. However, to satisfy FAA certification requirements, it must be demonstrated that the adaptive flight control system is also able to fail and still allow the aircraft to be flown safely or to land, while at the same time providing a means of crew notification of the (impending) failure. It was for this purpose that the NASA Ames Confidence Tool was developed [3]. This paper presents the Confidence Tool as a means of providing in-flight software assurance monitoring of an adaptive flight control system. The paper will present the data obtained from flight testing the tool on a specially modified F-15 aircraft designed to simulate loss of flight control faces.

Jacklin, Stephen A.↗
NASA NTRS1976

IPCS implications for future supersonic transport aircraft

The Integrated Propulsion Control System (IPCS) demonstrates control of an entire supersonic propulsion module - inlet, engine afterburner, and nozzle - with an HDC 601 digital computer. The program encompasses the design, build, qualification, and flight testing of control modes, software, and hardware. The flight test vehicle is an F-111E airplane. The L.H. inlet and engine will be operated under control of a digital computer mounted in the weapons bay. A general description and the current status of the IPCS program are given.

Billig, L. O.↗
NASA NTRS1990

Evaluation of the Trajectory Operations Applications Software Task (TOAST). Volume 2: Interview transcripts

The Trajectory Operations Applications Software Task (TOAST) is a software development project whose purpose is to provide trajectory operation pre-mission and real-time support for the Space Shuttle. The purpose of the evaluation was to evaluate TOAST as an Application Manager - to assess current and planned capabilities, compare capabilities to commercially-available off the shelf (COTS) software, and analyze requirements of MCC and Flight Analysis Design System (FADS) for TOAST implementation. As a major part of the data gathering for the evaluation, interviews were conducted with NASA and contractor personnel. Real-time and flight design users, orbit navigation users, the TOAST developers, and management were interviewed. Code reviews and demonstrations were also held. Each of these interviews was videotaped and transcribed as appropriate. Transcripts were edited and are presented chronologically.

Perkins, Sharon↗
NASA NTRS1991

Lessons learned from Space Shuttle flight software and Mission Control software

The techniques utilized by NASA to manage risk in the development and operations of flight software and Mission Control Center software for the Space Shuttle are reviewed. Particular attention is given to independent software in the backup flight system, structured requirements and design techniques, multiple levels of testing in development and production, independent testing following production, and independence of development and production, and the Mission Control Center model for Real Time Data System project.

Muratore, John F.↗
NASA NTRS2004

Adding Assurance to Automatically Generated Code

Code to estimate position and attitude of a spacecraft or aircraft belongs to the most safety-critical parts of flight software. The complex underlying mathematics and abundance of design details make it error-prone and reliable implementations costly. AutoFilter is a program synthesis tool for the automatic generation of state estimation code from compact specifications. It can automatically produce additional safety certificates which formally guarantee that each generated program individually satisfies a set of important safety policies. These safety policies (e.g.. array-bounds, variable initialization) form a core of properties which are essential for high-assurance software. Here we describe the AutoFilter system and its certificate generator and compare our approach to the static analysis tool PolySpace.

Denney, Ewen↗
NASA NTRS2004

Autonomous Vegetation Cover Scene Classification of EO-1 Hyperion Hyperspectral Data

The Autonomous Sciencecraft Experiment (ASE) is a JPL-led, New Millennium Program mission containing new technology in the form of software to be flown on the Earth Observer-1 (EO-1) satellite in early 2004. This new technology will facilitate an artificially intelligent machine with autonomous science-driven capabilities. Among the ASE flight software is a set of onboard science algorithms designed for autonomous data processing, primarily based on change detection from observation to observation. Using the output from these algorithms, ASE has the ability to autonomously modify the EO-1 observation plan, retargeting itself for a more in-depth observation of a scientific event in progress. Furthermore, intelligent and selective information down-linking will maximize return of the most valuable scientific data. Among the algorithms developed for use on ASE is a Lava-Vegetation (L-V) detection algorithm. This algorithm can effectively identify the initial location and extent of lava and vegetation coverage based on spectral shape. Comparison of several different observations, all classified via this algorithm, can make change detection possible.

Lee, R. J.↗
NASA NTRS2015

Astrobee Systems Engineering Design Overview

The Astrobee preliminary design documents include subsystem design overview slides and a 3D model of the preliminary design of the Astrobee system including: mechanical, electrical, flight software, network, and ground subsystems.

Smith, Marion F.↗
NASA NTRS1990

What can formal methods offer to digital flight control systems design

Formal methods research begins to produce methods which will enable mathematic modeling of the physical behavior of digital hardware and software systems. The development of these methods directly supports the NASA mission of increasing the scope and effectiveness of flight system modeling capabilities. The conventional, continuous mathematics that is used extensively in modeling flight systems is not adequate for accurate modeling of digital systems. Therefore, the current practice of digital flight control system design has not had the benefits of extensive mathematical modeling which are common in other parts of flight system engineering. Formal methods research shows that by using discrete mathematics, very accurate modeling of digital systems is possible. These discrete modeling methods will bring the traditional benefits of modeling to digital hardware and hardware design. Sound reasoning about accurate mathematical models of flight control systems can be an important part of reducing risk of unsafe flight control.

Good, Donald I.↗
NASA NTRSDate not supplied

Autonomous Navigation of a Lunar Relay Using GNSS and Other Measurements

Many of the highest priority destinations at the Moon lack a continuous view of Earth, such as the lunar poles or lunar far side. Exploration of these sites will require spacecraft in cislunar space to relay communications and provide position, navigation, and timing (PNT) services. Accurate knowledge of relay position, velocity, and time is essential to these services. This paper describes a concept for a PNT Instrument being developed for the Lunar Communications Relay and Navigation Systems (LCRNS) Project. The instrument is intended as a payload that would enable autonomous, on-board, real-time navigation and timing using Global Navigation Satellite System (GNSS), optical navigation, and one-way measurements from Earth-based ground stations. Hardware-in-the-loop simulations using flight software are used to realistically characterize performance on hardware platforms with a path to flight. These results provide preliminary validation of the proposed PNT Instrument, demonstrate the benefits of augmenting GNSS with other measurements, and serve as an insightful reference for the design of future lunar missions, including those that will operate within the LunaNet framework of standards. This instrument concept relies on several technologies developed at NASA Goddard Space Flight Center (GSFC). For GNSS observables, the instrument relies on the high-altitude NavCube 3 mini (NC3m) GNSS receiver specifically designed for cislunar applications. The autoNGC system, which consists of flight software and a hardware platform, is responsible for fusing the observables using its extended Kalman filter, the Goddard Enhanced Onboard Navigation System (GEONS). Optical navigation observables are processed within autoNGC (“autonomous Navigation, Guidance, and Control”) using the Goddard Image Analysis & Navigation Tool (GIANT) which is also responsible for simulating high-fidelity images for test and analysis. In addition to describing the PNT Instrument and its components, the paper will present predicted performance based on simulation results. As a baseline, it will present GNSS-only hardware-in-the loop results using a NC3m test unit to process Spirent-simulated GPS signals in a potential lunar relay trajectory: a 12-hour elliptical frozen lunar orbit (ELFO). GEONS then processes the GPS pseudorange and time differenced carrier phase measurements to estimate and propagate the relay state (position, velocity, and time). These results extend previously published work that showed preliminary ELFO performance. Previous work has shown the importance of other measurement types, so additional simulations are performed which augment GNSS with ground station observables and several methods of optical navigation, including celestial navigation, limb-finding (e.g., observations of the lunar horizon), and terrain relative navigation (TRN). TRN involves correlating simulated predicted images of the lunar surface with actual imagery; misalignments of landmarks identified in each image are translated into relay state updates. TRN is valuable as a measurement of the relay’s state relative to the Moon, especially during GNSS outages or after maneuvers. One-way Pseudorange and Doppler measurements from Earth-based ground stations are also simulated. The full set of observables is processed using autoNGC. These simulations make use of autoNGC and NC3m test units, a lab atomic clock, and a pulse-per-second (PPS) generation and distribution system. This combination of subsystems, and the hardware platforms used in this analysis, represents a PNT Instrument that could be flown on a lunar relay. Results from the hardware-in-the-loop simulations presented in this paper provide a preliminary assessment of the achievable navigation performance of this instrument concept. PNT Instrument performance is compared to the GPS-only performance, and a discussion is provided on the apparent merits and challenges of each measurement type.

Ben Ashman↗
NASA NTRS2014

Morpheus Vertical Test Bed Flight Testing

NASA's Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing, that is designed to serve as a testbed for advanced spacecraft technologies. The lander vehicle, propelled by a LOX/Methane engine and sized to carry a 500kg payload to the lunar surface, provides a platform for bringing technologies from the laboratory into an integrated flight system at relatively low cost. Morpheus onboard software is autonomous from ignition all the way through landing, and is designed to be capable of executing a variety of flight trajectories, with onboard fault checks and automatic contingency responses. The Morpheus 1.5A vehicle performed 26 integrated vehicle test flights including hot-fire tests, tethered tests, and two attempted freeflights between April 2011 and August 2012. The final flight of Morpheus 1.5A resulted in a loss of the vehicle. In September 2012, development began on the Morpheus 1.5B vehicle, which subsequently followed a similar test campaign culminating in free-flights at a simulated planetary landscape built at Kennedy Space Center's Shuttle Landing Facility. This paper describes the integrated test campaign, including successes and setbacks, and how the system design for handling faults and failures evolved over the course of the project.

Hart, Jeremy↗
NASA NTRS1979

Maneuver analysis

The maneuver design for Viking was accomplished in two phases. First, there was the preflight design and strategy development that was dictated by mission objectives and requirements. Orbit determination and maneuver execution accuracy statistics were used, together with propellant budget considerations, to determine specific maneuver requirements and strategies. The second phase of the maneuver design occurred in flight. The maneuver analyses that were performed in flight, the software that was employed, and the actual inflight results for the entire orbital phase of the nominal Viking Mission are described with emphasis on prelanding objectives and geometry considerations. The actual adaptive design and implementation of the maneuvers as the mission progressed are considered. This design process included the minimization of both propellant usage and the effects of maneuver execution errors, while complying with several mechanization constraints.

Mitchell, R. T.↗
NASA NTRS2017

Design and Control of an Experimental Tilt-Wing Aircraft

In this project, work has been done in the field of conceptual design of experimental tiltrotors. The main tools that have been used are NDARC (NASA Design and Analysis of Rotorcraft) and SIMPLI-FLYD. NDARC is a conceptual design tool for rotorcraft, and it is used to find trim points under various flight conditions. SIMPLI-FLYD is an integrated collection of software tools that enables a flight dynamics and control assessment of the rotorcraft vehicle design generated from NDARC. Two different tiltrotors have been investigated. Initially, work was done with the Bell XV- 15 tiltrotor. NDARCs ability to correctly model the tiltwing transition between airplane mode and hover mode was looked into. In addition, data from old flight tests were compared to the NDARC output, to see how accurately performance could be predicted. After the XV-15 analysis, an NDRARC model of a novel tiltwing concept from Elytron Aircraft was written and analyzed together with SIMPLI-FLYD. Elytron 2S is an experimental tiltwing aircraft, consisting of a joined-wing design with a small central wing for the proprotor. An alternative approach to hover control is used, where the typical rotor hub and swash plate are substituted for linear actuators controlling pitch, yaw and roll. The objective with the analysis of Elytron is to obtain a more complete understanding of the maneuverability and possible performance of this alternative aircraft configuration.

Conceptual Design↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink (R)

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the vali-dation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aero-space Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and as-cent. The GLASS framework utilizes the off-the-shelf Mathworks ® Simscape Multibody® toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparisons demonstrate that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check cases and verifies the GLASS core framework dynamics and the correct implementation of the check case scenario models.

6-Dof↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the validation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aerospace Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and ascent. The GLASS framework utilizes the off-the-shelf Mathworks (R) Simscape (TM) Multibody (TM) toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparison demonstrates that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check-cases and verify the GLASS core framework dynamics and the implementation of the check case scenario models.

6-Dof↗
NASA NTRS2010

The Role and Quality of Software Safety in the NASA Constellation Program

In this study, we examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Obtaining an accurate, program-wide picture of software safety risk is difficult across multiple, independently-developing systems. We leverage one source of safety information, hazard analysis, to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. The goal of this research is two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to quantify the level of risk presented by software in the hazard analysis. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. To quantify the importance of software, we collected metrics based on the number of software-related causes and controls of hazardous conditions. To quantify the level of risk presented by software, we created a metric scheme to measure the specificity of these software causes. We found that from 49-70% of hazardous conditions in the three systems could be caused by software or software was involved in the prevention of the hazardous condition. We also found that 12-17% of the 2013 hazard causes involved software, and that 23-29% of all causes had a software control. Furthermore, 10-12% of all controls were software-based. There is potential for inaccuracy in these counts, however, as software causes are not consistently scoped, and the presence of software in a cause or control is not always clear. The application of our software specificity metrics also identified risks in the hazard reporting process. In particular, we found a number of traceability risks in the hazard reports may impede verification of software and system safety.

Layman, Lucas↗
NASA NTRS1983

Digital Instrumentation Analysis and Navigation System (DIANS) for system identification

Hardware, software, and performance features of the Digital Instrumentation and Navigation System (DIANS) designed for NASA research to collect flight data as a strap-down system are detailed. The support software for the system has a cross compiler, a linkage editor, and cross assembler, extended communication capabilities, postflight processing applications, and compilers for PASCAL, FORTRAN, CBASIC and MT. The DIANS microcomputer has a 1 Mbyte RAM module, a fast floating point processor board, a 68000 monoboard computer with 64 RAM, a 128 Kbyte bubble memory card, and a navigation radio. The system also carries a battery for full system operation for over an hour. The support software is also stored on a host mainframe computer, which has a CP/M operating system. Pitch, roll, and heading data are gathered from the on-board system, and communication is possible between the airborne and ground-based computer.

Smyth, R. K.↗