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 793 records · Page 44

R-Hope: Development Approach to Extreme Non-volatile Memory Reuse Onboard the Curiosity Rover

The MSL Curiosity rover landed on Mars on August~5, 2012. Over time, one of its two computers experienced critical hardware memory failure. This non-volatile NAND flash memory held file system partitions and tunable parameters needed for running rover flight software. The project assembled a design and development team to re-purpose a NOR flash memory hardware chip, only 1.5\% of the size of the NAND, to hold the file systems and parameters. The usable NOR memory required major software changes to accommodate the new limitations of slower access speeds, vastly different physical layout, and smaller size. This presentation discusses the approach, challenges, and outcomes of restoring function to the computer so it can act as a ``lifeboat'' in event of problems with the primary computer.

Peper, Nick↗

IKOS: Sound Static Program Analysis

This is a tutorial on how to use the IKOS tool for static analysis of C/C++ code for flight critical system. The tutorial explains what static code analysis is, what kind of errors IKOS can find, and how to use the tool on single or multiple file projects. Simple examples are given to illustrate the use of the tool. This tutorial also describes the use of IKOS on real mission code, in this case, the flight software for the BioSentinel mission and the Troupe project in the Robust Software Engineering group.

Aviation↗

FPP: A Modeling Language for F Prime

We present F Prime Prime (FPP), a new open-source modeling language for F Prime. F Prime is an open-source flight software framework developed at JPL and deployed, among other places, on the Mars helicopter Ingenuity. FPP provides a convenient way to model the architectural elements of an F Prime application, e.g., components, ports, and their connections. It has a succinct and readable syntax, a well- defined semantics, and robust error checking and reporting. The FPP tool suite, written in Scala, analyzes FPP models, reports errors, and translates correct FPP models to a combination of XML and C++. Existing F Prime tools translate the XML to a partial implementation in C++, to be completed by the developers. The model elements have clean interfaces and are highly reusable. An accompanying visualization tool constructs diagrams of components and connections that FSW developers can use to understand and communicate their designs, for ex- ample at reviews. We discuss the design and implementation of FPP and the integration of FPP into F Prime. We also discuss our experience using FPP to construct F Prime models. Finally, we discuss our plans for future work, including improved code generation, improved visualization, and more advanced analysis capabilities.

Starch, Michael D.↗

Radiation Tolerance and Mitigation for Neuromorphic Processors

Neuromorphic processors are designed to execute Deep Neural Networks (DNNs) at very high speed using only a fraction of the electrical power needed to run a DNN on a traditional CPU or GPU. This unique capability makes Neuromorphic processors a prime candidate for space systems, where advanced computational tasks like image analysis, depth map reconstruction, or rover control need to be executed in a power-starved environment. In contrast to the growing number of applications of Neuromorphic processors in smart phones, the automotive and robotics domain, the space environment is unforgiving because of extreme temperatures and high levels of radiation. Any space system, operating beyond LEO requires computing hardware that is resilient against radiation effects. However, Neuromorphic processors have not yet been designed or tested for their radiation tolerance. In this report, we consider traditional methods of detection of radiation events and mitigation via redundancy and gauge their effectiveness on DNNs. In contrast to traditional flight software, however, neural networks represent a statistical algorithm, which might affect its resilience against radiation events. We will focus on the analysis of the tolerance of DNNs with respect to radiation events and discuss techniques to detect radiation hits using on-chip triple modular redundancy (TMR) on an Intel Loihi neuromorphic processor and to mitigate radiation damage. We describe an architecture for on-chip TMR for the Intel Loihi and present results of initial experiments.

Neural Networks↗

Space ROS - ACO: Space Robot Operating System

Space ROS is a matured version of ROS 2 using flight software engineering practices to facilitate mission- and safety-critical applications. Our goal is to reduce the barrier to maturation and infusion of software developed using the popular ROS framework.

Austin Breien Probe↗

Space ROS: Architecture Roadmap

Space ROS is a matured version of ROS 2 using flight software engineering practices to facilitate mission- and safety-critical applications. This roadmap was developed by the team to communicate the planned future evolution of Space ROS

Austin Probe↗

Autonomous Maneuver Planning and Execution for GeoXO Station Keeping and Momentum Management

GOES-16 was launched in 2016 using GPS at GEO, a first for civil space. With the subsequent launch of GOES-17 in 2018, followed by GOES-18 in 2022, we have accumulated over a decade of error free GPS navigation experience at GEO. Confident in GPS performance at GEO, the next generation/NASA geosynchronous weather satellite program GeoXO will require the spacecraft flight software to automate station keeping and momentum management maneuver planning and execution. Coupled with low thrust propulsion, it gives us assurance that on-board maneuver planning and execution can be implemented at a very low risk, allowing instruments to operate through maneuvers while maintaining a more accurate orbital slot and reducing operational costs. In this paper, we discuss how GOES-R maneuver planning is currently performed on the ground and contrast this with our vision of how it might be automated on-board.

GeoXO↗

On-Orbit Performance of the Spitzer Space Telescope: Science Meets Engineering

The Spitzer Space Telescope operated for over 16 years in an Earth-trailing solar orbit, returning not only a wealth of scientific data but also, as a by-product, spacecraft and instrument engineering data that will be of interest to future mission planners. These data will be particularly useful because Spitzer operated in an environment essentially identical to that at the L2 LaGrange point, where many future astrophysics missions will operate. In particular, the radiative cooling demonstrated by Spitzer has been adopted by other infrared space missions, from JWST to SPHEREx. We aim to facilitate the utility of the Spitzer engineering data by collecting the more unique and potentially useful portions into a single, readily accessible publication. We avoid discussion of less unique systems, such as the telecom, flight software, and electronics systems, and do not address the innovations in mission and science operations that the Spitzer team initiated. These and other items of potential interest are addressed in references supplied in an appendix to this paper.

Spitzer↗

Should’ve Could’ve: Progress in the Systems Engineering of the Mars2020 On-Board Planner

Mars rover operations has traditionally controlled behavior using meticulously compiled, so-called “Master” sequences that enforce deterministic timing and ordering of activities. While the approach is effective at managing risk and complexity, it can also be inefficient. Extended operations of the Mars2020 rover envisions a fundamentally different scheduling and execution approach. Atomic activities are constrained by mission operators in time, resource usage, and a structure of dependencies. The rover flight software will create and re-create schedules, responding to available energy, data volume, actual activity durations and execution status, observed temperatures, and other on-board state. Schedules are expected to change substantially in the course of execution. The solution space is prohibitively large and probabilistic in nature. A range of emergent behavior is accessible depending on the interaction between actual on-board state and a given formulation of constraints. For years, the specification and implementation of this capability have been considered and refined, as testing and analysis have mapped the contours of the system. Many concepts that could have been adopted were rejected, and in some cases, emergent properties have been exposed and beaten back with approaches to steer the behavior. This paper discusses some of the design history and underlying reasoning in the systems engineering of the first autonomous activity planner on Mars.

Kuhn, Stephen R↗

Visual Odometry Thinking While Driving for the Curiosity Mars Rover's Three-Year Test Campaign: Impact of Evolving Constraints on Verification and Validation

Over the first 9 years of the Mars Science Laboratory (MSL) Curiosity rover's surface mission, more than 87\% of its driving has been performed using Visual Odometry (VO). The benefits of using VO during driving are that it minimizes rover position uncertainty and can be used to monitor wheel slip, halting a drive if excessive wheel slip is occurring. The VO implementation on board Curiosity acquires and processes VO images in between drive steps while the rover is stationary. A VO Thinking While Driving (VTWD) flight software capability has been developed which enables the processing of VO images during rover driving, increasing the distance Curiosity can drive with VO in a given time period up to as much as 1.75x total distance. Verification and Validation (V\&V) of the capability has been challenging due to impacts from the COVID-19 pandemic and unavailability of the JPL Mars Yard outdoor test site. The VTWD V\&V test procedures were modified to use a small indoor space with Mars-like terrain. This paper describes the 3 year V\&V effort under challenging conditions to approve the VTWD capability for use on the Curiosity rover.

Rankin, Arturo↗

Actuator and Motor Control End-to-End V&V on the Mars 2020 Rover

The Mars 2020 Perseverance rover is the most advanced robotic exploration system ever sent to another planet. To support the complex scientific and mobility needs of the mission, the rover utilizes 33 actuators, three multi-degree-of-freedom force-torque sensors, fifteen single or dual-speed resolvers, two solenoid valves, and twelve contact switches. The control for these actuators and sensors is achieved by several levels of flight software, coordinated between two computers with varying bandwidth control loops. Furthermore, the actuators and sensors were integrated into multiple larger robotic mechanisms that were delivered by different organizations at various points in the Integration and Test (I&T) timeline. All of this created a very complex Verification and Validation (V&V) scenario involving multiple subsystems and teams, several hardware and software testbeds with varying levels of fidelity, and significant systems engineering to ensure the overall I&T schedule could be maintained while ensuring system hardware safety.This paper details the integrated V&V effort across multiple teams and venues to provide full coverage of all necessary functionality, performance, and fault protection. First, it provides an overview of how the V&V campaign was subdivided among teams and venues and provides descriptions of the various hardware configurations used to support the testing. The Mars 2020 implementation of the plan incorporates many of the lessons learned from Mars Science Laboratory’s test campaign, and these value-added modifications are discussed here. Also included in this section is the system-level environmental testing approach used for mechanisms. Second, the paper describes the phased approach used by the teams to support new hardware and software deliveries to testbed and Systems I&T. In this approach the test campaign was built upon higher-level mechanism needs for performance, functionality, and safety at specific times in the campaign. Finally, the paper discusses lessons learned from the V&V campaign that should be applied to future large-scale motion control testing efforts.

Borne, Davis↗

New Rover Conops with High-Performance Onboard Computing: Give Up Raw Data to Reduce Ops Cost and Do More Science

A major portion of time during the tactical operation of Mars rovers is spent for selecting, prioritizing, and coordinating sciences and engineering activities such that they fit within resource constraints, including the downlink data volume, energy, and time. In particular, the downlink data volume constraint is getting particularly tighter in recent missions because modern instruments produce increasingly high data volume while the communication bandwidth is essentially bounded by the law of physics. Tactical operation would be substantially simplified, hence the operation cost could be reduced, if the data volume constraint is relaxed or even removed. In this abstract, we propose a new operation paradigm for achieving this goal. The key observation is that, both in science and engineering applications, the bit size of raw data is typically much greater than the volume of processed information that is needed for scientific or engineering analysis. For example, a full-resolution image from Mastcam-Z, the main science camera on Perseverance, is about 700 kB in volume and we downlinked 29,685 images up to Sol 243, totaling ~20 GB of data. But of course, scientists do not use every pixel of these images; what they really look for in the images are geological features, typically represented by specific geometric configurations or textures. An end product after processing hundreds of Mascam-Z images could be a single geological map summarizing the spatial distribution of the features. For another example, a 100-meter drive of Perseverance produces 7-12 MB of drive telemetry, which records every detail of the rover's motion at 8 Hz, including position, attitude, steering angles, encoder readings, motor currents and many other information. But what the ground engineers eventually pay attention to is the signs of anomaly, such as excessive motor currents or high slip; if a drive is nominal, the vast majority of this data is unused. What if, then, we process the raw data onboard and only downlink the processed data that is relevant to scientific or engineering analyses, such as a list of detected science features (with cropped images) or a list of potential signs of anomaly while driving? A major roadblock for such onboard, high-level information processing has been the onboard computational resource. RAD750, the main onboard computer of Perseverance, is obviously not sufficient for performing complex image or signal processing such as object detection, semantic segmentation, or anomaly detection. Interestingly, RAD750 is not the best processor that Perseverance has; Qualcomm's Snapdragon 801, a modern mobile processor, is on her Heli Base Station, a device for communicating with Mars Helicopter Ingenuity; also, Intel's Atom E3845 processors are on engineering cameras. In the reminder of this paper, we will introduce two particular uses cases of these high-performance co-processors (meaning auxiliary CPU, GPU, or other types of processors that are separate from the main processor that runs the main flight software) for lowering operation cost and accommodating more science activities for a given communication constraint.

Didier, A.↗

Safe and Precise Landing Integrated Capabilities Evolution (SPLICE)

NASA needs for entry, descent, and landing call for improved Precision Landing and Hazard Avoidance (PL&HA) technologies. SPLICE continues to develop, mature, demonstrate, and infuse these technologies as a portfolio. SPLICE will achieve TRL 5 on a hazard detection lidar mapping sensor and TRL 6 on two key flight software libraries for advanced guidance and hazard detection. A High-Performance Space Computing surrogate multiprocessor (ARM A53) integrates sensors and FSW. This portfolio of technologies may be infused separately or fully integrated.

Guidance Navigation and Control↗

BioSentinel: Leading the Way for Deep Space CubeSat Missions

Flagship science missions are not alone in Deep Space thanks to BioSentinel, a 6U spacecraft launched on Artemis-1. BioSentinel is one of the longest operating CubeSats beyond cislunar space. The subsystems and COTS components of the BioSentinel bus are a template for future deep space missions, and the lessons learned from over a year of operations will enable improved performance for the next missions. BioSentinel achieved its unprecedented performance for an SLS secondary payload due to preparation, planning, and a robust design. Pre-launch antenna and interface testing with both DSN and ESA confirmed command and data pathways and allowed for operational flexibility in the critical early hours post-deployment. Mission Operations simulations prior to launch identified potential risks and primed operators to respond in flight, preparing the team to react quickly to successfully detumble the spacecraft and enter a power-positive state. The spacecraft would not have survived without the inclusion of the trailblazing 3D-printed composite cold gas propulsion system. The non-standard tank geometry enabled efficient use of the limited space available in the CubeSat, as well as the capability to detumble the spacecraft and manage momentum, while providing sufficient margin to execute potential delta-V maneuvers. The Iris radio has operated for over 18 months with no significant issues. Initial Iris performance estimates have been accurate throughout the mission. BioSentinel continues to collect data on thermal conditions and to validate our performance models with real-world knowledge. We have received exemplary support from our DSN partners. Following the conclusion of the primary science mission, the Linear Energy Transfer (LET) Spectrometer continued to collect solar and galactic radiation data from its location in heliocentric orbit. The free space dataset offered by the BioSentinel LET is a valuable source of data for model validation and future mission planning. As the spacecraft travels farther from Earth it is poised to provide longitudinally distributed measurements of solar particle events during solar maximum. The lessons learned from BioSentinel suggest key areas to enhance performance. The ability to upload modified flight software can increase the stability of memory management. Additional heaters in the propulsion system design have already proven successful on the Starling mission. Streamlining mission operations can reduce costs, increase data return, and better utilize DSN time. Enhancements such as these will facilitate reliable, long-duration deep space exploration using the proven BioSentinel 6U CubeSat bus.

BioSentinel↗

Autonomous Navigation of a Lunar Relay Using GNSS and Other Measurements

NASA’s Lunar Communications Relay and Navigation Services (LCRNS) project will establish a relay constellation at the Moon to provide the south pole region with communications and position, navigation, and time (PNT) services. These services will require highly accurate knowledge of position, velocity, and time (PVT) for each relay. This paper explores one approach for performing onboard PVT estimation, the LCRNS PNT Instrument (LPI). This paper considers different configurations of the instrument, specifically different measurement types and clocks, and the resulting navigation performance. Simulation results are first shown for an instrument configuration that uses GPS pseudorange and Doppler measurements with a highly sensitive GPS receiver (i.e., an acquisition and tracking threshold of 23 dB-Hz) and a chip-scale atomic clock (CSAC). The importance of Doppler, clock quality, receiver sensitivity, and optical navigation is examined through comparison of these results to other instrument configurations. Clock quality (i.e., stability) is the strongest determinant of achievable performance, and the inclusion of GPS Doppleralso has a significant effect. Finally, simulation results are compared to two laboratory tests: first a case that includes GPS receiver hardware in the loop, then a case that includes optical navigation and filter flight software in the loop. These agreeclosely with the simulation results and provide evidence the simulation is accurately modeling the instrument under development.

Benjamin W Ashman↗

Design Considerations of an Ascent Abort Monitor Algorithm for Use During Service Module Aborts

In support of human rating the Artemis missions, NASA's Orion program requires continuous abort coverage from liftoff through mission destination. During a portion of the ascent trajectory, the currently achievable abort mode is determined by an Orion algorithm using the onboard navigated vehicle state. This ascent abort monitor determines achievability for Orion's Mode 2 abort, Untargeted Abort Splashdown (UAS), by propagating the current vehicle state through ascent abort events to determine sufficient timing to perform the abort and to a ballistic touchdown point to approximate landing location relative to prescribed keep out boundaries. The algorithm was updated for Artemis 2 to allow the capability to limit loads for the majority of ascent. Performance of the algorithm has been demonstrated and verified through dispersed trajectory analysis with emulated flight software, unit testing, and hardware in the loop testing.

Esteban Guzman↗

A study of software management and guidelines for flight projects

A survey of present software development policies and practices, and an analysis of these policies and practices are summarized. Background information necessary to assess the adequacy of present NASA flight software development approaches is presented.

Source record↗

Radiation Hardening by Software Techniques on FPGAs: Flight Experiment Evaluation and Results

We present our work on implementing Radiation Hardening by Software (RHBSW) techniques on the Xilinx Virtex5 FPGAs PowerPC 440 processors on the SpaceCube 2.0 platform. The techniques have been matured and tested through simulation modeling, fault emulation, laser fault injection and now in a flight experiment, as part of the Space Test Program- Houston 4-ISS SpaceCube Experiment 2.0 (STP-H4-ISE 2.0). This work leverages concepts such as heartbeat monitoring, control flow assertions, and checkpointing, commonly used in the High Performance Computing industry, and adapts them for use in remote sensing embedded systems. These techniques are extremely low overhead (typically <1.3%), enabling a 3.3x gain in processing performance as compared to the equivalent traditionally radiation hardened processor. The recently concluded STP-H4 flight experiment was an opportunity to upgrade the RHBSW techniques for the Virtex5 FPGA and demonstrate them on-board the ISS to achieve TRL 7. This work details the implementation of the RHBSW techniques, that were previously developed for the Virtex4-based SpaceCube 1.0 platform, on the Virtex5-based SpaceCube 2.0 flight platform. The evaluation spans the development and integration with flight software, remotely uploading the new experiment to the ISS SpaceCube 2.0 platform, and conducting the experiment continuously for 16 days before the platform was decommissioned. The experiment was conducted on two PowerPCs embedded within the Virtex5 FPGA devices and the experiment collected 19,400 checkpoints, processed 253,482 status messages, and incurred 0 faults. These results are highly encouraging and future work is looking into longer duration testing as part of the STP-H5 flight experiment.

Hybrid Flight Architectures↗