Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Spacecraft 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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Next Generation Remote Agent Planner

In May 1999, as part of a unique technology validation experiment onboard the Deep Space One spacecraft, the Remote Agent became the first complete autonomous spacecraft control architecture to run as flight software onboard an active spacecraft. As one of the three components of the architecture, the Remote Agent Planner had the task of laying out the course of action to be taken, which included activities such as turning, thrusting, data gathering, and communicating. Building on the successful approach developed for the Remote Agent Planner, the Next Generation Remote Agent Planner is a completely redesigned and reimplemented version of the planner. The new system provides all the key capabilities of the original planner, while adding functionality, improving performance and providing a modular and extendible implementation. The goal of this ongoing project is to develop a system that provides both a basis for future applications and a framework for further research in the area of autonomous planning for spacecraft. In this article, we present an introductory overview of the Next Generation Remote Agent Planner. We present a new and simplified definition of the planning problem, describe the basics of the planning process, lay out the new system design and examine the functionality of the core reasoning module.

Jonsson, Ari K.↗
NASA NTRS2011

Software Certification - Coding, Code, and Coders

We describe a certification approach for software development that has been adopted at our organization. JPL develops robotic spacecraft for the exploration of the solar system. The flight software that controls these spacecraft is considered to be mission critical. We argue that the goal of a software certification process cannot be the development of "perfect" software, i.e., software that can be formally proven to be correct under all imaginable and unimaginable circumstances. More realistically, the goal is to guarantee a software development process that is conducted by knowledgeable engineers, who follow generally accepted procedures to control known risks, while meeting agreed upon standards of workmanship. We target three specific issues that must be addressed in such a certification procedure: the coding process, the code that is developed, and the skills of the coders. The coding process is driven by standards (e.g., a coding standard) and tools. The code is mechanically checked against the standard with the help of state-of-the-art static source code analyzers. The coders, finally, are certified in on-site training courses that include formal exams.

training↗
NASA NTRS2021

Case Studies in Verifying Spacecraft Autonomy

Spacecraft, operating with a time-to-effect faster than human command response, or with absent or delayed communication, have depended on autonomy. It is likely that this reliance will continue, and increase further in future missions. Spacecraft autonomy is used when operator intervention is not available or feasible, or when dynamic aspects of a spacecraft situation cannot be predicted in advance. This paper provides case studies of several successfully verified autonomous software systems across multiple spacecraft, flight phases (launch, transit, entry and landing, science utilization), and software classifications, and can serve as examples to future missions in methods of successfully assuring spacecraft autonomy.

Johnson, Stephen B.↗
NASA NTRS2005

Sequence System Building Blocks: Using a Component Architecture for Sequencing Software

Over the last few years software engineering has made significant strides in making more flexible architectures and designs possible. However, at the same time, spacecraft have become more complex and flight software has become more sophisticated. Typically spacecraft are often one-of-a-kind entities that have different hardware designs, different capabilities, different instruments, etc. Ground software has become more complex and operations teams have had to learn a myriad of tools that all have different user interfaces and represent data in different ways. At Jet Propulsion Laboratory (JPL) these themes have collided to require an new approach to producing ground system software. Two different groups have been looking at tackling this particular problem. One group is working for the JPL Mars Technology Program in the Mars Science Laboratory (MSL) Focused Technology area. The other group is the JPL Multi-Mission Planning and Sequencing Group . The major concept driving these two approaches on a similar path is to provide software that can be a more cohesive flexible system that provides a act of planning and sequencing system of services. This paper describes the efforts that have been made to date to create a unified approach from these disparate groups.

flexible architectures↗
NASA NTRS2006

Sequencing System Building Blocks: Using a Component Architecture for Sequencing Software

Over the last few years software engineering has made significant strides in making more flexible architectures and designs possible. However, at the same time, spacecraft have become more complex and flight software has become more sophisticated. Typically spacecraft are often one-of-a-kind entities that have different hardware designs, different capabilities, different instruments, etc. Ground software has become more complex and operations teams have had to learn a myriad of tools that all have different user interfaces and represent data in different ways. At Jet Propulsion Laboratory (JPL) these themes have collided to require a new approach to producing ground system software. Two different groups have been looking at tackling this particular problem. One group is working for the JPL Mars Technology Program in the Mars Science Laboratory (MSL) Focused Technology area. The other group is the JPL Multi-Mission Planning and Sequencing Group. The major concept driving these two approaches on a similar path is to provide software that can be a more cohesive flexible system that provides a set of planning and sequencing system of services. This paper describes the efforts that have been made to date to create a unified approach from these disparate groups.

multi mission planning↗
NASA NTRS2007

Cassini's Test Methodology for Flight Software Verification and Operations

The Cassini spacecraft was launched on 15 October 1997 on a Titan IV-B launch vehicle. The spacecraft is comprised of various subsystems, including the Attitude and Articulation Control Subsystem (AACS). The AACS Flight Software (FSW) and its development has been an ongoing effort, from the design, development and finally operations. As planned, major modifications to certain FSW functions were designed, tested, verified and uploaded during the cruise phase of the mission. Each flight software upload involved extensive verification testing. A standardized FSW testing methodology was used to verify the integrity of the flight software. This paper summarizes the flight software testing methodology used for verifying FSW from pre-launch through the prime mission, with an emphasis on flight experience testing during the first 2.5 years of the prime mission (July 2004 through January 2007).

Cassini Mission↗
NASA NTRS2013

Development of Autonomous Aerobraking - Phase 2

Phase 1 of the Development of Autonomous Aerobraking (AA) Assessment investigated the technical capability of transferring the processes of aerobraking maneuver (ABM) decision-making (currently performed on the ground by an extensive workforce and communicated to the spacecraft via the deep space network) to an efficient flight software algorithm onboard the spacecraft. This document describes Phase 2 of this study, which was a 12-month effort to improve and rigorously test the AA Development Software developed in Phase 1. Aerobraking maneuver; Autonomous Aerobraking; Autonomous Aerobraking Development Software; Deep Space Network; NASA Engineering and Safety Center

Murri, Daniel G.↗
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS2010

AutoGNC Testbed

A simulation testbed architecture was developed and implemented for the integration, test, and development of a TRL-6 flight software set called Auto- GNC. The AutoGNC software will combine the TRL-9 Deep Impact AutoNAV flight software suite, the TRL-9 Virtual Machine Language (VML) executive, and the TRL-3 G-REX guidance, estimation, and control algorithms. The Auto- GNC testbed was architected to provide software interface connections among the AutoNAV and VML flight code written in C, the G-REX algorithms in MATLAB and C, stand-alone image rendering algorithms in C, and other Fortran algorithms, such as the OBIRON landmark tracking suite. The testbed architecture incorporates software components for propagating a high-fidelity truth model of the environment and the spacecraft dynamics, along with the flight software components for onboard guidance, navigation, and control (GN&C). The interface allows for the rapid integration and testing of new algorithms prior to development of the C code for implementation in flight software. This testbed is designed to test autonomous spacecraft proximity operations around small celestial bodies, moons, or other spacecraft. The software is baselined for upcoming comet and asteroid sample return missions. This architecture and testbed will provide a direct improvement upon the onboard flight software utilized for missions such as Deep Impact, Stardust, and Deep Space 1.

Carson, John M., III↗
NASA NTRS2008

SDO FlatSat Facility

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

Amason, David L.↗
NASA NTRS1996

Magnetospheric Atmospheric X-ray Imaging Experiment (MAXIE)

This report summarizes the activities sponsored by the Office of Naval Research for the Magnetospheric Atmospheric X-ray Imaging Experiment (MAXIE). The MAXIE instrument was developed as a joint activity of Lockheed, The Aerospace Corporation, and the University of Bergen, Norway. Lockheed was responsible for the overall management of the program, interfacing with the appropriate government agencies, the overall electrical and mechanical design, flight software, environmental testing, spacecraft integration activities, on orbit checkout, and data processing activities. The Magnetospheric Atmospheric X-ray Imaging Experiment (MAXIE), the ONR 401 experiment, is the first in a new class of satellite-borne remote sensing instruments. The primary innovation is the ability to obtain rapid, sequential, images with high sensitivity of the earth's X ray aurora from a low altitude polar orbiting satellite. These images can be used to identify dynamic temporal variations in the three-dimensional (energy and position) distribution of electron precipitation into the atmosphere. MAXIE was launched on the TIROS NOAA-13 satellite on 9 August 1993. The experiment performed well during its turn-on sequence; however, the spacecraft bus failed on 21 August 1993. New spacebased technologies successfully used in MAXIE were mixed-mode ASIC microcircuits, a zero torque scanning system with associated viscoelastic damping, a paraffin stow release mechanism, a parallel integrating PHA processor, a low noise Si(Li) sensor telescope, and an advanced thermal cooling system. MAXIE's on orbit operation, control of penetrating particle backgrounds, and scientific data indicated good overall performance.

Imhof, W. L.↗
NASA NTRS2000

The Cassini/Huyegens Mission to Saturn and Titan

This paper summarizes the principal accomplishments of the Cassini/Huygens mission over the past year, which include a complete reload of the flight software on the spacecraft, including that of most of the orbiter science instruments, the final definition of the exact orbital tour to be flown at Saturn, and considerable progress in designing the sequence of science observations to be made in the tour.

Cassini Huygens Saturn Titan↗
NASA NTRS2005

Predicting Numbers of Problems in Development of Software

A method has been formulated to enable prediction of the amount of work that remains to be performed in developing flight software for a spacecraft. The basic concept embodied in the method is that of using an idealized curve (specifically, the Weibull function) to interpolate from (1) the numbers of problems discovered thus far to (2) a goal of discovering no new problems after launch (or six months into the future for software already in use in orbit). The steps of the method can be summarized as follows: 1. Take raw data in the form of problem reports (PRs), including the dates on which they are generated. 2. Remove, from the data collection, PRs that are subsequently withdrawn or to which no response is required. 3. Count the numbers of PRs created in 1-week periods and the running total number of PRs each week. 4. Perform the interpolation by making a least-squares fit of the Weibull function to (a) the cumulative distribution of PRs gathered thus far and (b) the goal of no more PRs after the currently anticipated launch date. The interpolation and the anticipated launch date are subject to iterative re-estimation.

Simonds, Charles H.↗
NASA NTRS2009

Testing Flight Systems with Machine Executable Scripts

The MSAP project at JPL has been testing spacecraft avionics and flight software since 2005, in part using computer executable scripts. The scripts are document files of a common word processor and comply with the format of a traditional, formal test procedure common at JPL. These procedures use keywords to issue commands and evaluate responses, mimicking a human test operator. In effect, script lines are inserted into a normal procedure. Even though the executable structure of the procedures is limited to linear sequences of fairly simple operations, we have found significant value in certain test regimes given the repeatability, ease of execution, and readily understandable intent of these procedures.

Gibbs, Don↗
NASA NTRS2018

An Investigation of Parallel Programming Techniques Applied to Monte Carlo Simulations for Post-Flight Reconstruction of Spacecraft Trajectory

Parallelizing software to execute on multi-core central processing units (CPUs) and graphics processing units (GPUs) can be challenging. For some fields outside of Computer Science, this transition comes with new issues. For example, memory limitations can require modifications to code not initially developed to run on GPUs. This work applies the Open Multi-Processing (OpenMP) and Open Accelerators (OpenACC) directive-based parallelization strategies on a Monte Carlo simulation approach for trajectory reconstruction enabling it to run on multi-core CPUs and GPUs. Large matrix operations are the most common use of GPUs, which are not present in this algorithm; however, the natural parallelism of independent trajectories in Monte Carlo simulations is exploited. Benchmarking data are presented comparing execution times of the software for single-thread CPUs, multi-thread CPUs with OpenMP, and multi-thread GPUs using OpenACC. These data were collected using nodes with Intel® Xeon® E5-2670 (Sandy Bridge) CPUs enhanced with NVIDIA® Tesla® K40 GPUs on the Pleiades Supercomputer cluster at the National Aeronautics and Space Administration (NASA) Ames Research Center (ARC) and a local Intel® Xeon Phi™ node at NASA Langley Research Center (LaRC).

Williams, R. Anthony↗
NASA NTRS2023

Fault Detection and Diagnosis in Spacecraft Electrical Power Systems

The ability to accurately identify and isolate failures in the electrical power system (EPS) is critical to ensure the reliability of spacecraft. This paper proposes a novel solution to the problem of fault detection and diagnosis in direct current (DC) electric power systems for spacecraft. Autonomous operation becomes essential during deep space missions that lack the ability to monitor and control the spacecraft from ground locations. The current state of EPS fault supervision is insufficient to guarantee highly reliable operation. To solve this issue, a combination of model-based and knowledge-based techniques are used in a hierarchical framework to improve the diagnostic performance of the system. Noise, disturbances, and modeling errors are considered in the design of the fault detection system. Practical considerations related to spacecraft flight hardware and software are accounted for in the system design for flight applications. To assess the functionality of the design, a wide array of failures are simulated in a series of experiments. The experiments showed that the technique improved the capability of the autonomous system by increasing the number of fault types diagnosed. The significance of this study is to provide a framework capable of advanced diagnostics of an EPS with little to no interaction from human operators.

Autonomous Power Systems↗