Search NASA⌕ Search

SEARCH · Search NASA

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 343 records · Page 19

Investigation of passive atmospheric sounding using millimeter and submillimeter wavelength channels

Activities within the period from July 1, 1992 through December 31, 1992 by Georgia Tech researchers in millimeter and submillimeter wavelength tropospheric remote sensing have been centered around the calibration of the Millimeter-wave Imaging Radiometer (MIR), preliminary flight data analysis, and preparation for TOGA/COARE. The MIR instrument is a joint project between NASA/GSFC and Georgia Tech. In the current configuration, the MIR has channels at 90, 150, 183(+/-1,3,7), and 220 GHz. Provisions for three additional channels at 325(+/-1,3) and 8 GHz have been made, and a 325-GHz receiver is currently being built by the ZAX Millimeter Wave Corporation for use in the MIR. Past Georgia Tech contributions to the MIR and its related scientific uses have included basic system design studies, performance analyses, and circuit and radiometric load design, in-flight software, and post-flight data display software. The combination of the above millimeter wave and submillimeter wave channels aboard a single well-calibrated instrument will provide unique radiometric data for radiative transfer and cloud and water vapor retrieval studies. A paper by the PI discussing the potential benefits of passive millimeter and submillimeter wave observations for cloud, water vapor and precipitation measurements has recently been published, and is included as an appendix.

Gasiewski, Albin J.↗

MOBI and FEANICS Programming in Labview

The flight software engineering branch provides design and development of embedded real-time software applications for flight and supporting ground systems to support the NASA Aeronautics and Space Programs. In addition, this branch evaluates, develops and implements new technologies for embedded real-time systems, and maintains a laboratory for applications of embedded technology. This branch supports other divisions and is involved with many other projects. My mentor Rochelle and I are involved in the Fluids and Combustion Facility (FCF) project, the MOBI project, and the FEANICS project. The Fluids and Combustion Facility (FCF) will occupy two powered racks on the International Space Station (ISS). It will be a permanent modular, multiuser facility to accommodate microgravity science experiments onboard the ISS's U.S. Laboratory Module. FCF will support NASA Human Exploration and Development of Space program objectives requiring sustained, systematic research in the disciplines of fluid physics and combustion science. The fluids experiment is called FIR and the combustion experiment is called CIR. The MOBI Experiment is an experiment that is performed to understand the physics of bubble segregation and resuspension in an inertia, monodisperse gas-liquid suspension, and to understand how bubble pressure resists segregation in suspensions with continuous phase inertia. The main focus of FEANICS and the solid combustion experiments will be to conduct basic and applied scientific investigations in fire-safety to support NASA's Bioastronautics Initiative. Based on data obtained in microgravity and experience gained from the beginning of the U.S. manned space program, these normal gravity flammability assessments have been assumed to be conservative with respect to flammability in all environments. However, some of the complex interactions that govern ignition and flame growth can only be evaluated in the long durations of microgravity available on the ISS. Before any of these projects actually go to the ISS, they are going to be tested on NASA's KC-135 Low-G airplane, the KC-135 Low-G Flight Research aircraft (a predecessor of the Boeing 707) is used to fly parabolas to create 20-25 seconds of weightlessness so that the astronauts can experience and researchers can investigate the effects of zero gravity. My mentor and I have been working with Labview to write the programs that are going to acquire, analyze and present the data acquired from these Test flights on the KC-135. We have been working closely with electrical, and mechanical engineers to make sure the program and the hardware can communicate and perform the operations necessary for the flight test. LabVIEW delivers a powerful graphical development environment for signal acquisition, measurement analysis, and data presentation, giving you the flexibility of a programming language without the complexity of traditional development tools. The programming of the control panel and the code are both done in GUIs which allow for flexibility in the code and the program.

Rios, Jeffrey N.↗

High speed simulator: A simulator for all seasons

The evolution of a high speed spacecraft simulator (HSS) is discussed from development and operations perspectives. The HSS is a series of simulators capable of modeling the spacecraft and its subsystems at different levels. The HSS was developed for the validation of the Galileo low gain antenna mission's flight software. Due to the successful performance of the HSS in assisting with the flight software validation, additional Galileo validation applications were identified. These applications include the modeling of other onboard data systems, such as the command and data subsystem and the attitude and articulation control subsystem. The HSS architecture, which consists of a number of components, is described and the operational use of the system is outlined.

Patel, K.↗

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗

Flight dynamics software in a distributed network environment

As with all NASA facilities, the announcement of reduced budgets, reduced staffing, and the desire to implement smaller/quicker/cheaper missions has required the Agency's organizations to become more efficient in what they do. To accomplish these objectives, the FDD has initiated the development of the Flight Dynamics Distributed System (FDDS). The underlying philosophy of FDDS is to build an integrated system that breaks down the traditional barriers of attitude, mission planning, and navigation support software to provide a uniform approach to flight dynamics applications. Through the application of open systems concepts and state-of-the-art technologies, including object-oriented specification concepts, object-oriented software, and common user interface, communications, data management, and executive services, the FDD will reengineer most of its six million lines of code.

Jeletic, J.↗

Operating System Abstraction Layer (OSAL)

This viewgraph presentation reviews the concept of the Operating System Abstraction Layer (OSAL) and its benefits. The OSAL is A small layer of software that allows programs to run on many different operating systems and hardware platforms It runs independent of the underlying OS & hardware and it is self-contained. The benefits of OSAL are that it removes dependencies from any one operating system, promotes portable, reusable flight software. It allows for Core Flight software (FSW) to be built for multiple processors and operating systems. The presentation discusses the functionality, the various OSAL releases, and describes the specifications.

Yanchik, Nicholas J.↗

Autonomous Navigation of a Lunar Relay Using GNSS and Other Measurements

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

Ben Ashman↗

Goddard Enhanced Onboard Navigation System (GEONS) Mathematical Specifications

The National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC) has developed the capability to provide high-accuracy attitude, orbit, and time autonomously onboard NASA spacecraft. The GSFC Mission Engineering and Systems Analysis Division has implemented NASA-developed navigation algorithms for high-accuracy real-time onboard orbit determination in the Global Positioning System (GPS) Enhanced Orbit Determination (GEODE) flight software. The Goddard Enhanced Onboard Navigation System (GEONS) extends the capabilities of the GEODE flight software to include additional measurement types and additional navigation algorithms.

Anne C. Long↗

On-Board Model Based Fault Diagnosis for CubeSat Attitude Control Subsystem: Flight Data Results

Self-sufficient, robotic spacecraft require estimates of their hardware health state in order to project future system state and plan actions toward achieving mission goals. In this paper, we report on integration of a Model-Based Fault Diagnosis (MBFD) model and reasoning engine into flight software leveraging the Arcsecond Space Telescope Enabling Research in Astrophysics (ASTERIA) mission, including test results against captured flight data using the ASTERIA system testbed. Our effort integrated the Model-based Off-Nominal State Identification and Detection (MONSID) model-based reasoning system, developed by Okean Solutions, into ASTERIA flight software using the F Prime software framework. The MONSID engine was supplied with a model of the Blue Canyon Technologies XACT attitude control system (ACS) and tested against flight data and seeded fault tests. While we were unable to conduct an on-board experiment due to the premature loss of ASTERIA, our effort proved the feasibility of on-board model-based fault management, demonstrating reliable and accurate diagnosis using captured data, and further supporting a closed-loop spacecraft autonomy demonstration including autonomous navigation in off-nominal conditions.

Prather, Maurice↗

HAL/S programmer's guide

This programming language was developed for the flight software of the NASA space shuttle program. HAL/S is intended to satisfy virtually all of the flight software requirements of the space shuttle. To achieve this, HAL/s incorporates a wide range of features, including applications-oriented data types and organizations, real time control mechanisms, and constructs for systems programming tasks. As the name indicates, HAL/S is a dialect of the original HAL language previously developed. Changes have been incorporated to simplify syntax, curb excessive generality, or facilitate flight code emission.

Newbold, P. M.↗

Inflight Performance of Cassini Reaction Wheel Bearing Drag in 1997-2013

As the first spacecraft to achieve orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004-08), and has since been approved for a first and second extended missions through September 2017. Cassini is a three-axis stabilized spacecraft. It uses reaction wheels to achieve high level of spacecraft pointing stability that is needed during imaging operations of several science instruments. The Cassini flight software makes in-flight estimates of reaction wheel bearing drag torque and made them available to the mission operations team. These telemetry data are being trended for the purpose of monitoring the long-term health of the reaction wheel bearings. Anomalous drag torque signatures observed over the past 15 years are described in this paper. One of these anomalous drag conditions is bearing cage instability that appeared (and disappeared) spontaneously and unpredictably. Cage instability is an uncontrolled vibratory motion of the bearing cage that can produce high-impact forces internal to the bearing that will cause intermittent and erratic torque transients. Characteristics of the observed cage instabilities and other drag torque "spikes" are described in this paper. In day-to-day operations, the reaction wheels' rates must be neither too high nor too low. To protect against operating the wheels in any undesirable conditions (such as prolonged low spin rate operations), a ground software tool named Reaction Wheel Bias Optimization Tool (RBOT) was developed for the management of the wheels. Disciplined and long-term use of this ground software has led to significant reduction in the daily consumption rate of the wheels' low spin rate dwell time. Flight experience on the use of this ground software tool as well as other lessons learned on the management of Cassini reaction wheels is given in this paper.

Cassini/Huygens Mission↗

HAL/SM language specification

A programming language is presented for the flight software of the NASA Space Shuttle program. It is intended to satisfy virtually all of the flight software requirements of the space shuttle. To achieve this, it incorporates a wide range of features, including applications-oriented data types and organizations, real time control mechanisms, and constructs for systems programming tasks. It is a higher order language designed to allow programmers, analysts, and engineers to communicate with the computer in a form approximating natural mathematical expression. Parts of the English language are combined with standard notation to provide a tool that readily encourages programming without demanding computer hardware expertise. Block diagrams and flow charts are included. The semantics of the language is discussed.

Williams, G. P. W., Jr.↗

Software and system level tests of a test flight mercury ion thruster subsystem

A U.S. Air Force technology spacecraft flight is scheduled to carry an Ion Auxiliary Propulsion System (IAPS) as part of its experimental payload. This paper presents the results of the successful flight-software qualification and system-level tests which were performed on IAPS. The software tests were performed with an operating engineering model ion thruster and power processing unit, and failure/off-normal recovery modes, operation with and without temperature telemetry from the thruster vaporizers, and with closed-loop control or fixed setpoint operation of the thruster vaporizers. The system-level tests cover a wide range of thermal and operating conditions with the entire system exposed to a simulated space environment.

Robson, R. R.↗

Tutorial: MATLAB Implementation of a Successive Convexification Algorithm for 3 DoF Rocket Landings

The primary objective of this work is to fill in gaps and explore an alternate way of solving the 3 DoF rocket-powered landing problem presented in the 2016 AIAA paper by Szmuk, Ackimese, and Berning using successive convexification (SCvx). In the original paper, CVX, an automatic parsing package, was used to transcribe the high-level trajectory optimization problem into a format that could be read by a conic solver. The parsing step, generally computationally intensive, is hidden from the user. The use of CVX is sufficient for the generation of trajectories off-line due to the lack of runtime and flight software implementation constraints. For on-line applications, it is necessary to parse the problem for flight software implementation. References on hand-parsing powered descent guidance (PDG) problems are sparse. In this Tech Memo, the process of transcribing the 3 DoF PDG problem into the format required by MATLAB’s built-in second-order cone solver, coneprog.m, is presented in detail. Due to the abridged 3 DoF dynamics and the relatively simple nonlinearities, this reference is the natural starting point for anyone interested in grasping the concepts behind SCvx pertaining to PDG and the parsing step. Simulation results shown in this report were independently created by solving the problem using coneprog.m. The intent of this memo is to serve as a supplemental material to the original paper by breaking down the concept behind successive convexification and shed light into the parsing process. Readers are encouraged to first familiarize themselves with the material laid out in the original reference.

Alex Hayes↗

Software System for the Mars 2020 Mission Sampling and Caching Testbeds

The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.

Vieira, Peter↗

Loran-C flight test software

The software package developed for the KIM-1 Micro-System and the Mini-L PLL receiver to simplify taking flight test data is described along with the address and data bus buffers used in the KIM-1 Micro-system. The interface hardware and timing are also presented to describe completely the software programs.

Nickum, J. D.↗

OASSIS: Onboard Adaptive Safe-site Identification System Y3

The OASSIS Year 3 project continues to innovate with three goals: 1) transition to a generic configuration compatible with GNC flight software, 2) implement a new, computationally-efficient TRN algorithm for lunar landing, and 3) integrate with the a HWIL testbed to validate lunar landing GNC systems. This project enables lunar lander GNC flight software to be tested dynamically without the need of a costly flight campaign and without the risk of catastrophic hardware loss. Additionally, the TRN algorithm development and testing enhances the state-of-the-art in pinpoint landing navigation, ultimately improving the overall landing accuracy, safety, and reliability of a crewed lunar landing mission.

James S Mccabe↗