Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Flight Software”

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 1,081 records · Page 60
All sourcesNASA NTRSDOE OSTI
NASA NTRS1997

APMS: An Integrated Suite of Tools for Measuring Performance and Safety

This is a report of work in progress. In it, I summarize the status of the research and development of the Aviation Performance Measuring System (APMS) for managing, processing, and analyzing digital flight-recorded data. The objectives of the NASA-FAA APMS research project are to establish a sound scientific and technological basis for flight-data analysis, to define an open and flexible architecture for flight-data-analysis systems, and to articulate guidelines for a standardized database structure on which to continue to build future flight-data-analysis extensions . APMS will offer to the air transport community an open, voluntary standard for flight-data-analysis software, a standard that will help to ensure suitable functionality, and data interchangeability, among competing software programs. APMS will develop and document the methodologies, algorithms, and procedures for data management and analyses to enable users to easily interpret the implications regarding safety and efficiency of operations. APMS does not entail the implementation of a nationwide flight-data-collection system. It is intended to provide technical tools to ease the large-scale implementation of flight-data analyses at both the air-carrier and the national-airspace levels in support of their Flight Operations and Quality Assurance (FOQA) Programs and Advanced Qualifications Programs (AQP). APMS cannot meet its objectives unless it develops tools that go substantially beyond the capabilities of the current commercially available software and supporting analytic methods that are mainly designed to count special events. These existing capabilities, while of proven value, were created primarily with the needs of air crews in mind. APMS tools must serve the needs of the government and air carriers, as well as air crews, to fully support the FOQA and AQP programs. They must be able to derive knowledge not only through the analysis of single flights (special-event detection), but through statistical evaluation of the performance of large groups of flights. This paper describes the integrated suite of tools that will assist analysts in evaluating the operational performance and safety of the national air transport system, the air carrier, and the air crew.

Statler, Irving C.↗
NASA NTRS1997

APMS: An Integrated Suite of Tools for Measuring Performance and Safety

This is a report of work in progress. In it, I summarize the status of the research and development of the Aviation Performance Measuring System (APMS) for managing, processing, and analyzing digital flight-recorded data. The objectives of the NASA-FAA APMS research project are to establish a sound scientific and technological basis for flight-data analysis, to define an open and flexible architecture for flight-data-analysis systems, and to articulate guidelines for a standardized database structure on which to continue to build future flight-data-analysis extensions. APMS will offer to the air transport community an open, voluntary standard for flight-data-analysis software, a standard that will help to ensure suitable functionality, and data interchangeability, among competing software programs. APMS will develop and document the methodologies, algorithms, and procedures for data management and analyses to enable users to easily interpret the implications regarding safety and efficiency of operations. APMS does not entail the implementation of a nationwide flight-data-collection system. It is intended to provide technical tools to ease the large-scale implementation of flight-data analyses at both the air-carrier and the national-airspace levels in support of their Flight Operations and Quality Assurance (FOQA) Programs and Advanced Qualifications Programs (AQP). APMS cannot meet its objectives unless it develops tools that go substantially beyond the capabilities of the current commercially available software and supporting analytic methods that are mainly designed to count special events. These existing capabilities, while of proven value, were created primarily with the needs of air crews in mind. APMS tools must serve the needs of the government and air carriers, as well as air crews, to fully support the FOQA and AQP programs. They must be able to derive knowledge not only through the analysis of single flights (special-event detection), but through statistical evaluation of the performance of large groups of flights. This paper describes the integrated suite of tools that will assist analysts in evaluating the operational performance and safety of the national air transport system, the air carrier, and the air crew.

Statler, Irving C.↗
NASA NTRS1984

Reflight certification software design specifications

The PDSS/IMC Software Design Specification for the Payload Development Support System (PDSS)/Image Motion Compensator (IMC) is contained. The PDSS/IMC is to be used for checkout and verification of the IMC flight hardware and software by NASA/MSFC.

Source record↗
NASA NTRS2003

Initial SVS Integrated Technology Evaluation Flight Test Requirements and Hardware Architecture

This document presents the flight test requirements for the Initial Synthetic Vision Systems Integrated Technology Evaluation flight Test to be flown aboard NASA Langley's ARIES aircraft and the final hardware architecture implemented to meet these requirements. Part I of this document contains the hardware, software, simulator, and flight operations requirements for this light test as they were defined in August 2002. The contents of this section are the actual requirements document that was signed for this flight test. Part II of this document contains information pertaining to the hardware architecture that was realized to meet these requirements as presented to and approved by a Critical Design Review Panel prior to installation on the B-757 Airborne Research Integrated Experiments Systems (ARIES) airplane. This information includes a description of the equipment, block diagrams of the architecture, layouts of the workstations, and pictures of the actual installations.

Harrison, Stella V.↗
NASA NTRS2014

Design and Analysis of Morpheus Lander Flight Control System

The Morpheus Lander is a vertical takeoff and landing test bed vehicle developed to demonstrate the system performance of the Guidance, Navigation and Control (GN&C) system capability for the integrated autonomous landing and hazard avoidance system hardware and software. The Morpheus flight control system design must be robust to various mission profiles. This paper presents a design methodology for employing numerical optimization to develop the Morpheus flight control system. The design objectives include attitude tracking accuracy and robust stability with respect to rigid body dynamics and propellant slosh. Under the assumption that the Morpheus time-varying dynamics and control system can be frozen over a short period of time, the flight controllers are designed to stabilize all selected frozen-time control systems in the presence of parametric uncertainty. Both control gains in the inner attitude control loop and guidance gains in the outer position control loop are designed to maximize the vehicle performance while ensuring robustness. The flight control system designs provided herein have been demonstrated to provide stable control systems in both Draper Ares Stability Analysis Tool (ASAT) and the NASA/JSC Trick-based Morpheus time domain simulation.

Jang, Jiann-Woei↗
NASA NTRS2005

Autonomous Flight Safety System Road Test

On February 3, 2005, Kennedy Space Center (KSC) conducted the first Autonomous Flight Safety System (AFSS) test on a moving vehicle -- a van driven around the KSC industrial area. A subset of the Phase III design was used consisting of a single computer, GPS receiver, and UPS antenna. The description and results of this road test are described in this report.AFSS is a joint KSC and Wallops Flight Facility project that is in its third phase of development. AFSS is an independent subsystem intended for use with Expendable Launch Vehicles that uses tracking data from redundant onboard sensors to autonomously make flight termination decisions using software-based rules implemented on redundant flight processors. The goals of this project are to increase capabilities by allowing launches from locations that do not have or cannot afford extensive ground-based range safety assets, to decrease range costs, and to decrease reaction time for special situations.

Simpson, James C.↗
NASA NTRS2005

Autonomous Flight Safety System September 27, 2005, Aircraft Test

This report describes the first aircraft test of the Autonomous Flight Safety System (AFSS). The test was conducted on September 27, 2005, near Kennedy Space Center (KSC) using a privately-owned single-engine plane and evaluated the performance of several basic flight safety rules using real-time data onboard a moving aerial vehicle. This test follows the first road test of AFSS conducted in February 2005 at KSC. AFSS is a joint KSC and Wallops Flight Facility (WEF) project that is in its third phase of development. AFSS is an independent subsystem intended for use with Expendable Launch Vehicles that uses tracking data from redundant onboard sensors to autonomously make flight termination decisions using software-based rules implemented on redundant flight processors. The goals of this project are to increase capabilities by allowing launches from locations that do not have or cannot afford extensive ground-based range safety assets, to decrease range costs, and to decrease reaction time for special situations. The mission rules are configured for each operation by the responsible Range Safety authorities and can be loosely categorized in four major categories: Parameter Threshold Violations, Physical Boundary Violations present position and instantaneous impact point (TIP), Gate Rules static and dynamic, and a Green-Time Rule. Examples of each of these rules were evaluated during this aircraft test.

Simpson, James C.↗
NASA NTRS2013

Experiment Description and Results for Arrival Operations Using Interval Management with Spacing to Parallel Dependent Runways (IMSPiDR)

The predicted increase in the number of commercial aircraft operations creates a need for improved operational efficiency. Two areas believed to offer increases in aircraft efficiency are optimized profile descents and dependent parallel runway operations. Using Flight deck Interval Management (FIM) software and procedures during these operations, flight crews can achieve by the runway threshold an interval assigned by air traffic control (ATC) behind the preceding aircraft that maximizes runway throughput while minimizing additional fuel consumption and pilot workload. This document describes an experiment where 24 pilots flew arrivals into the Dallas Fort-Worth terminal environment using one of three simulators at NASA?s Langley Research Center. Results indicate that pilots delivered their aircraft to the runway threshold within +/- 3.5 seconds of their assigned time interval, and reported low workload levels. In general, pilots found the FIM concept, procedures, speeds, and interface acceptable. Analysis of the time error and FIM speed changes as a function of arrival stream position suggest the spacing algorithm generates stable behavior while in the presence of continuous (wind) or impulse (offset) error. Concerns reported included multiple speed changes within a short time period, and an airspeed increase followed shortly by an airspeed decrease.

Baxley, Brian T.↗
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 NTRSDate not supplied

Predicting the Seawater Chemistry of an Ocean World Using Machine Learning on Isotopic Measurements of Volatile CO2

Introduction: Given the long time intervals required for data transmission to and from ocean worlds targets, low bandwidth for data transmission, time required for data processing and analysis, and potentially extreme radiation environments (e.g., Europa), it is clear that ocean worlds missions will need more autonomous flight instruments and software in order to achieve established science goals. Protracted time intervals for data analysis (e.g., Europa Lander) strongly motivates the development of rapid, consistent and streamlined methods for interpreting data from flight mass spectrometers to e.g., determine how mass spectra from a plume or surface liquid/ice relates to the surface/subsurface. Since mass spectrometry also has the potential to correctly identify biosignatures[1], it is imperative that such methods for interpreting data are consistent and accurate. We used 848 isotope ratio mass spectra from laboratory analyses of CO2 that interacted with ocean worlds-relevant seawaters as a ‘training’ dataset for ‘unsupervised’ machine learning. In unsupervised learning, characteristics of the data are not labeled or linked, and any similarities found only result from the neural network. CO2 isotopologues analyzed for this dataset mimic the remote measurements of CO2 by a flight mass spectrometer, and are detailed in Theiling [2]. From this dataset, we used measured features of the spectra, such as retention time, intensity, and (isotopologue) mass ratios as inputs for our autoencoder neural network. Our neural network was trained to find similarities in these and other spectral features for seawaters of a particular composition and amount of initial CO2. Successful training then created an output of these similarities for various seawaters, which included MgSO4, Na2SO4, NaCl, MgCl2, KCl, and NaHCO3, and combinations of these salts. We then applied dimensionality reduction techniques such as Principal Component Analysis (PCA), T-Distributed Stochastic Neighbor Embedding (TSNE), and Uniform Manifold Approximation and Projection (UMAP) to demonstrate latent data features as a two-dimensional projection in a unitless, high-dimensional space. In this projection, a data point represents the combined effect of spectral features such as intensity, retention time, and isotope ratio. Our initial UMAP demonstrates data clustering (organization of the data by the neural network) based on the amount of CO2 that had initially interacted with each seawater. Further training using more ‘supervised’ learning techniques demonstrate strong clustering of preliminary data based on initial CO2 concentration, seawater chemical composition, and ionic strength (salinity). Our preliminary work therefore suggests that machine learning has the potential to identify compositional variants of an ocean world seawater based on mass spectra from volatile CO2 measurements. Acknowledgments: This work was funded through a Strategic Task Group at NASA Goddard Space Flight Center. The training dataset was collected through funding from the Oklahoma Space Grant Consortium. References: [1] Pappalardo, R. et al. (2013) Astrobiology, 13, 740–773. [2] Theiling (2020) Icarus, 114216.

Europa↗
NASA NTRS2022

Electrical Ground Support Equipment for the Sampling Caching System of the Mars 2020 Rover

In this work we describe in detail the architecture, design, testing and operation of the Electrical Ground Support Equipment (EGSE) “Blue Box” used to test and validate the Sampling Caching System (SCS) of the Mars 2020 Perseverance rover. The Blue Box architecture is centered around COTS motor controllers and COTS input-output modules communicating over an EtherCAT bus. A custom, low-level safety subsystem ensures no harm can be done to the flight articles. The modular architecture of the EGSE reduces cost and complexity while expediting assembly time. The Blue Box drives the 19 actuators of the SCS which span the main robotic arm, the corer system, the internal sample handling arm, the sample tube sealing system and the gas dust removal tool; mimicking the Rover Motor Control Assembly (RMCA). Due to the limited availability of RMCA’s, the EGSE enabled and performed the bulk of testing activities for SCS. The majority of the SCS actuators are composed of a 3-phase DC brushless motors, hall sensors for commutation, dual resolvers for output angular measurement, brakes, heaters and platinum thermistors. Additionally, the EGSE read 12 strain gauges forming part of a force torque sensor, and switches used for external positioning references. Over the 3-year span of the V&V campaign for the SCS, over 32 EGSE systems were built, tested and deployed to test venues at JPL and externally. The EGSE tested several families of the SCS subsystem, ranging from engineering units, life test units and two flight units. Test venues that this EGSE supported included lab benches, ultra-clean cleanrooms, ATLO facilities, and thermal vacuum chambers. Together with the test software systems, SSDEV and SSDEV-ECAT, the Blue Box EGSE enabled the team to efficiently test flight hardware and flight software together. We go over the safety features and fault management techniques employed to protect flight hardware. The effects of the long, 50-feet, EGSE harnesses on motor performance, EMI, electrical noise, and motor control performance are explained. Mitigations to these unwanted effects, including shielding strategy and inductance compensation, are summarized. We go over an excerpt of notable anomalies that this EGSE suffered through its operation, along with investigations and resolutions. Lessons learned, areas of improvement as part of future work, and recommendations for future implementations for similar EGSE’s, are shared.

Levine, Dan↗
NASA NTRS1991

Advanced automation in space shuttle mission control

The Real Time Data System (RTDS) Project was undertaken in 1987 to introduce new concepts and technologies for advanced automation into the Mission Control Center environment at NASA's Johnson Space Center. The project's emphasis is on producing advanced near-operational prototype systems that are developed using a rapid, interactive method and are used by flight controllers during actual Shuttle missions. In most cases the prototype applications have been of such quality and utility that they have been converted to production status. A key ingredient has been an integrated team of software engineers and flight controllers working together to quickly evolve the demonstration systems.

Heindel, Troy A.↗
DOE OSTI2021

Time managed virtualization for simulating systems of systems

Software is an integral part of almost every non-trivial system. Yet simulation technologies to understand how software affects system performance lag behind what is available to understand physical behavior. This is not surprising. An abstract model of software tells us what it is supposed to do, not what it actually does. In this respect software is very different from a physical system. Kirchhoff’s laws predict the behavior of an electrical circuit with great precision. The mathematics of fluids do an adequate job of anticipating how a wing will perform in flight. Only the software itself, observed in operation, can tell us how it behaves.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2026

Development of the Orion Life-Support Integration Facility (OLIF)

Testing the life support hardware of a vehicle that is going to take humans beyond low-Earth orbit (LEO) in conditions similar to space is crucial. The Orion Life-Support Integration Facility (OLIF) at NASA Johnson Space Center (JSC) was designed and built to test the Orion vehicle’s hardware and software as integrated systems to provide a complete Environmental Control and Life Support System (ECLSS) system-level qualification. The existing 11 Foot human rated vacuum chamber has been adapted to accommodate and integrate various qualification and flight like components of the Orion vehicle’s Air Revitalization System (ARS), Pressure Control System (PCS), Active Thermal Control System (ATCS) and the Orion Crew Survival System Suits (OCSS). The ultimate goal was to create an analog testbed that could safely support up to four test subjects in open “shirt-sleeve” or closed suit loop configurations and simulate Orion Cabin conditions. This integrated hardware/software ARS and PCS will help identify any technical issues that should be addressed prior to the Artemis-2 mission. This paper will discuss the history of Orion ECLSS hardware development testing in the 11 Foot Chamber, the challenge of integrating flight hardware and software control systems, and the capabilities that make it a unique, world class facility for NASA. It will provide an overview of past and future testing, and the lessons learned along the way.

Peter A Masi↗
NASA NTRS2021

Ultra Long-Lived, Self-Surveying Autonomous Air Quality Sensing - Executive Summary

We set out to evolve ultra-low power air quality sensing technologies developed at JSC to add a highly accurate positioning sensor based on SBIR technology to give a self-surveying air quality monitoring platform with years-long lifetime on a small, disposable coin cell battery. Using Radio Frequency Identification (RFID) technology for data transport, the system can take advantage of RFID-based inventory management systems in place on lunar exploration assets to provide this capability with extremely small SWAP impacts. Years-long operational lifetimes enable flexible, autonomous environmental monitoring during lengthy intervals between and unprecedented situational awareness during crewed missions. Software integration of the localization system into the JSC RFID sensing platform was advanced, but the COVID-19 pandemic complicated and slowed maturation of the localization system SBIR product, and center closure indefinitely deferred a final hardware integration and system demonstration. In the meantime, progress was made to mature the air-quality sensing platform for flight, including hardware, software, antenna, and mechanical improvements. The underlying RFID sensing capability was also adapted to a drawer motion sensing system, which is currently (FY21) being taken toward an ISS flight demonstration as part of the RFID Enhanced Autonomous Logistics Management (REALM)-3 experiment.

Raymond Summers Wagner↗
NASA NTRS2012

Orion Script Generator

NASA Engineering's Orion Script Generator (OSG) is a program designed to run on Exploration Flight Test One Software. The script generator creates a SuperScript file that, when run, accepts the filename for a listing of Compact Unique Identifiers (CUIs). These CUIs will correspond to different variables on the Orion spacecraft, such as the temperature of a component X, the active or inactive status of another component Y, and so on. OSG will use a linked database to retrieve the value for each CUI, such as "100 05," "True," and so on. Finally, OSG writes SuperScript code to display each of these variables before outputting the ssi file that allows recipients to view a graphical representation of Orion Flight Test One's status through these variables. This project's main challenge was creating flexible software that accepts and transfers many types of data, from Boolean (true or false) values to "Unsigned Long Long'' values (any number from 0 to 18,446,744,073,709,551,615). We also needed to allow bit manipulation for each variable, requiring us to program functions that could convert any of the multiple types of data into binary code. Throughout the project, we explored different methods to optimize the speed of working with the CUI database and long binary numbers. For example, the program handled extended binary numbers much more efficiently when we stored them as collections of Boolean values (true or false representing 1 or 0) instead of as collections of character strings or numbers. We also strove to make OSG as user-friendly and accommodating of different needs as possible its default behavior is to display a current CUI's maximum value and minimum value with three to five intermediate values in between, all in descending order. Fortunately, users can also add other input on the same lines as each CUI name to request different high values, low values, display options (ascending, sine, and so on), and interval sizes for generating intermediate values. Developing input validation took up quite a bit of time, but OSG's flexibility in the end was worth it.

Dooling, Robert J.↗