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 919 records · Page 51
All sourcesNASA NTRSDOE OSTI
NASA NTRS1996

A Description of the Software Element of the NASA EME Flight Tests

In support of NASA's Fly-By-Light/Power-By-Wire (FBL/PBW) program, a series of flight tests were conducted by NASA Langley Research Center in February, 1995. The NASA Boeing 757 was flown past known RF transmitters to measure both external and internal radiated fields. The aircraft was instrumented with strategically located sensors for acquiring data on shielding effectiveness and internal coupling. The data are intended to support computational and statistical modeling codes used to predict internal field levels of an electromagnetic environment (EME) on aircraft. The software was an integral part of the flight tests, as well as the data reduction process. The software, which provided flight test instrument control, data acquisition, and a user interface, executes on a Hewlett Packard (HP) 300 series workstation and uses BP VEEtest development software and the C programming language. Software tools were developed for data processing and analysis, and to provide a database organized by frequency bands, test runs, and sensors. This paper describes the data acquisition system on board the aircraft and concentrates on the software portion. Hardware and software interfaces are illustrated and discussed. Particular attention is given to data acquisition and data format. The data reduction process is discussed in detail to provide insight into the characteristics, quality, and limitations of the data. An analysis of obstacles encountered during the data reduction process is presented.

Koppen, Sandra V.↗
NASA NTRS1986

An experiment in software reliability

The results of a software reliability experiment conducted in a controlled laboratory setting are reported. The experiment was undertaken to gather data on software failures and is one in a series of experiments being pursued by the Fault Tolerant Systems Branch of NASA Langley Research Center to find a means of credibly performing reliability evaluations of flight control software. The experiment tests a small sample of implementations of radar tracking software having ultra-reliability requirements and uses n-version programming for error detection, and repetitive run modeling for failure and fault rate estimation. The experiment results agree with those of Nagel and Skrivan in that the program error rates suggest an approximate log-linear pattern and the individual faults occurred with significantly different error rates. Additional analysis of the experimental data raises new questions concerning the phenomenon of interacting faults. This phenomenon may provide one explanation for software reliability decay.

Dunham, J. R.↗
NASA NTRS1984

The all-electric aircraft - A systems view and proposed NASA research Programs

It is expected that all-electric aircraft, whether military or commercial, will exhibit reduced weight, acquisition cost and fuel consumption, an expanded flight envelope and improved survivability and reliability, simpler maintenance, and reduced support equipment. Also noteworthy are dramatic improvements in mission adaptability, based on the degree to which control system performance relies on easily exchanged software. Flight-critical secondary power and control systems whose malfunction would mean loss of an aircraft pose failure detection and design methodology problems, however, that have only begun to be addressed. NASA-sponsored research activities concerned with these problems and prospective benefits are presently discussed.

Spitzer, C. R.↗
NASA NTRS2019

Free-Flight CFD Simulations of Ballistic Range and Flight Tests

Free-Flight CFD capability has been implemented into the finite-volume solver US3D under the Entry Systems Modeling project. Several simulations of ballistic range experiments have been performed in order to validate the simulation software and methodology. Extension of the software to flight scale trajectories with varying freestream conditions has been carried out. Results show promising ability to predict vehicle behavior as compared to flight. Finally, a multi-body free-flight capability has been developed to generalize the single-body free-flight solver to study multiple bodies in proximal flight.

Brock, Joseph M.↗
NASA NTRS2018

CAIDA CUI Confirmation for OMRS & LCC SOCRRATES Emulator and iSEE Upgrade, Operations, & Analysis

This internship has focused on providing solutions for the Customer Avionics Interface Development and Analysis (CAIDA) subsystem. The main emulator that has been used during this internship is the Software-Only CEV (Crew Exploration Vehicle) Risk Reduction Analysis and Test Engineering Simulator (SOCRRATES). This emulator uses advanced math and physics methods to simulate specific points in a mission, such as ascent, entry, and orbit. Exploration Ground Systems (EGS) must ensure that all KSC based ground systems can be properly integrated with the flight vehicle software, therefore, the Modeling and Simulation Branch (NE-XM) of the KSC (Kennedy Space Center) Engineering Directorate supports a virtual environment that simulates the interface between ground systems and the flight vehicle. A primary component in assuring that is knowing whether the emulators have incorporated the correct CUIs (Compact Unique Identifiers) into their system, as well as understanding both the static and dynamic responses of the individual CUIs. Also, an effort for verification of Operational Maintenance Requirements Specifications (OMRS) and Launch Commit Criteria (LCC) that are supported by SOCRRATES for the Orion Crew Module were part of the project tasks this semester. This internship also focused on comparing two different simulation Commercial-off-the-shelf (COTS) products and to determine whether or not a COTS package was a viable replacement for the current software that the iSEE (Immersive Simulations and Engineering Environment) lab uses. Upon research and testing, I found that this software was not feasible for the lab. It could not easily load CAD (Computer-Aided Design) or CREO models, give live feedback while the user is in the environment, and was not compatible with a virtual reality headset, all of which are necessary for the lab.

Bundy, Caleb↗
NASA NTRS1986

Experiments in software reliability - Life-critical applications

The paper discusses four reliability data gathering experiments which were conducted using a small sample of programs for two problems having ultrareliability requirements, n-version programming for fault detection, and repetitive run modeling for failure and fault rate estimation. The experimental results agree with those of Nagel and Skrivan in that the program error rates suggest an approximate log-linear pattern and the individual faults occurred with significantly different error rates. Additional analysis of the experimental data raises new questions concerning the phenomenon of interacting faults. This phenomenon may provide one explanation for software reliability decay. The fourth experiment underscored the difficulty in distinguishing between observations of deficiencies in the design of the algorithm and observations of software faults for real-time process control software. These experiments are a part of a program of serial experiments being pursued by the System Validation Methods of NASA-Langley Research Center to find a means of credibly performing reliability evaluations of flight control software.

Dunham, J. R.↗
NASA NTRS2016

Link Adaptation for Mitigating Earth-To-Space Propagation Effects on the NASA SCaN Testbed

In Earth-to-Space communications, well-known propagation effects such as path loss and atmospheric loss can lead to fluctuations in the strength of the communications link between a satellite and its ground station. Additionally, the typically unconsidered effect of shadowing due to the geometry of the satellite and its solar panels can also lead to link degradation. As a result of these anticipated channel impairments, NASA's communication links have been traditionally designed to handle the worst-case impact of these effects through high link margins and static, lower rate, modulation formats. The work presented in this paper aims to relax these constraints by providing an improved trade-off between data rate and link margin through utilizing link adaptation. More specifically, this work provides a simulation study on the propagation effects impacting NASA's SCaN Testbed flight software-defined radio (SDR) as well as proposes a link adaptation algorithm that varies the modulation format of a communications link as its signal-to-noise ratio fluctuates. Ultimately, the models developed in this work will be utilized to conduct real-time flight experiments on-board the NASA SCaN Testbed.

software defined radio↗
NASA NTRS1995

A Laboratory Glass-Cockpit Flight Simulator for Automation and Communications Research

A laboratory glass-cockpit flight simulator supporting research on advanced commercial flight deck and Air Traffic Control (ATC) automation and communication interfaces has been developed at the Aviation Operations Branch at the NASA Ames Research Center. This system provides independent and integrated flight and ATC simulator stations, party line voice and datalink communications, along with video and audio monitoring and recording capabilities. Over the last several years, it has been used to support the investigation of flight human factors research issues involving: communication modality; message content and length; graphical versus textual presentation of information, and human accountability for automation. This paper updates the status of this simulator, describing new functionality in the areas of flight management system, EICAS display, and electronic checklist integration. It also provides an overview of several experiments performed using this simulator, including their application areas and results. Finally future enhancements to its ATC (integration of CTAS software) and flight deck (full crew operations) functionality are described.

Pisanich, Gregory M.↗
NASA NTRS1989

NASA-LaRc Flight-Critical Digital Systems Technology Workshop

The outcome is documented of a Flight-Critical Digital Systems Technology Workshop held at NASA-Langley December 13 to 15 1988. The purpose of the workshop was to elicit the aerospace industry's view of the issues which must be addressed for the practical realization of flight-critical digital systems. The workshop was divided into three parts: an overview session; three half-day meetings of seven working groups addressing aeronautical and space requirements, system design for validation, failure modes, system modeling, reliable software, and flight test; and a half-day summary of the research issues presented by the working group chairmen. Issues that generated the most consensus across the workshop were: (1) the lack of effective design and validation methods with support tools to enable engineering of highly-integrated, flight-critical digital systems, and (2) the lack of high quality laboratory and field data on system failures especially due to electromagnetic environment (EME).

Meissner, C. W., Jr.↗
NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2013

Orion GNC Mitigation Efforts for Van Allen Radiation

The Orion Crew Module (CM) is NASA's next generation manned space vehicle, scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and GN&C architectures have progressed through a number of project phases and are nearing completion of a major milestone. The first unmanned test mission, dubbed "Exploration Flight Test One" (EFT-1) is scheduled to launch from NASA Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and software. The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, which will be launched on an expendable launch vehicle (ELV). The ELV will place CM and the ELV upper stage into a low Earth orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a relatively high velocity, high heating environment. While not producing entry velocities as high as those experienced in returning from a lunar orbit, the trajectory was chosen to provide higher stresses on the thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required entry geometry with constraints on inclination and landing site result in a trajectory that lingers for many hours in the Van Allen radiation belts. This exposes the vehicle and avionics to much higher levels of high energy proton radiation than a typical LEO or lunar trajectory would encounter. As a result, Van Allen radiation poses a significant risk to the Orion avionics system, and particularly the Flight Control Module (FCM) computers that house the GN&C flight software. The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated with the Van Allen radiation on EFT-1 are covered in the paper. Background on the Orion avionics subsystem is provided, as well as an overview of the GN&C software architecture. The measures taken to handle radiation induced failure of the one or both of the FCM's are presented, and finally simulation and actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. The paper presents an overview of the Orion avionics architecture describing the GNC sensors, onboard data network as well as the flight control computers and their planned restart capabilities. GN&C sensors include two Orion Inertial Measurement Units (OIMU's), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters and a single GPS receiver. All of the sensors communicate to one of two Power and Data Units (PDU's). The PDU's multiplex analog and serial data from the sensors and write the data to the Orion Data Network (ODN). The OIMU s write measurement messages directly as onto the ODN, but they are routed through PDU network switches.

King, Ellis T.↗
NASA NTRS1986

Research and technology

Activities of the Goddard Space Flight Center are described in the areas of planets and interplanetary media, comets, astronomy and high-energy physics, solar physics, atmospheres, terrestrial physics, ocean science, sensors and space technology, techniques, user space data systems, space communications and navigation, and system and software engineering. Flight projects and mission definition studies are presented, and institutional technology is described.

Source record↗
NASA NTRS1997

HARV ANSER Flight Test Data Retrieval and Processing Procedures

Under the NASA High-Alpha Technology Program the High Alpha Research Vehicle (HARV) was used to conduct flight tests of advanced control effectors, advanced control laws, and high-alpha design guidelines for future super-maneuverable fighters. The High-Alpha Research Vehicle is a pre-production F/A-18 airplane modified with a multi-axis thrust-vectoring system for augmented pitch and yaw control power and Actuated Nose Strakes for Enhanced Rolling (ANSER) to augment body-axis yaw control power. Flight testing at the Dryden Flight Research Center (DFRC) began in July 1995 and continued until May 1996. Flight data will be utilized to evaluate control law performance and aircraft dynamics, determine aircraft control and stability derivatives using parameter identification techniques, and validate design guidelines. To accomplish these purposes, essential flight data parameters were retrieved from the DFRC data system and stored on the Dynamics and Control Branch (DCB) computer complex at Langley. This report describes the multi-step task used to retrieve and process this data and documents the results of these tasks. Documentation includes software listings, flight information, maneuver information, time intervals for which data were retrieved, lists of data parameters and definitions, and example data plots.

Yeager, Jessie C.↗
NASA NTRS2007

General Mission Analysis Tool (GMAT) Architectural Specification. Draft

Early in 2002, Goddard Space Flight Center (GSFC) began to identify requirements for the flight dynamics software needed to fly upcoming missions that use formations of spacecraft to collect data. These requirements ranged from low level modeling features to large scale interoperability requirements. In 2003 we began work on a system designed to meet these requirement; this system is GMAT. The General Mission Analysis Tool (GMAT) is a general purpose flight dynamics modeling tool built on open source principles. The GMAT code is written in C++, and uses modern C++ constructs extensively. GMAT can be run through either a fully functional Graphical User Interface (GUI) or as a command line program with minimal user feedback. The system is built and runs on Microsoft Windows, Linux, and Macintosh OS X platforms. The GMAT GUI is written using wxWidgets, a cross platform library of components that streamlines the development and extension of the user interface Flight dynamics modeling is performed in GMAT by building components that represent the players in the analysis problem that is being modeled. These components interact through the sequential execution of instructions, embodied in the GMAT Mission Sequence. A typical Mission Sequence will model the trajectories of a set of spacecraft evolving over time, calculating relevant parameters during this propagation, and maneuvering individual spacecraft to maintain a set of mission constraints as established by the mission analyst. All of the elements used in GMAT for mission analysis can be viewed in the GMAT GUI or through a custom scripting language. Analysis problems modeled in GMAT are saved as script files, and these files can be read into GMAT. When a script is read into the GMAT GUI, the corresponding user interface elements are constructed in the GMAT GUI. The GMAT system was developed from the ground up to run in a platform agnostic environment. The source code compiles on numerous different platforms, and is regularly exercised running on Windows, Linux and Macintosh computers by the development and analysis teams working on the project. The system can be run using either a graphical user interface, written using the open source wxWidgets framework, or from a text console. The GMAT source code was written using open source tools. GSFC has released the code using the NASA open source license.

Hughes, Steven P.↗
NASA NTRS2016

Safety Characteristics in System Application Software for Human Rated Exploration

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.

exploration↗