SEARCH · Engineering Papers
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.
Misalignment estimation software system for calibrating in-flight slew angle scale factors and drift rates of OAO gyros
Misalignment estimation software system /MESS/ for in-flight celestial and inertial reference attitude sensor alignment and calibration on OAO
The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.
The parallel development of digital engine and flight controls for U.S. Army helicopters has made possible the future derivation of a fully integrated digital flight/propulsion control system. A NASA/Army research program has been undertaken to exploit these possibilities, ultimately yielding a generation of helicopters with exceptional agility and maneuverability in military roles and low pilot workloads in all-weather civil aviation missions. The program's three phases respectively address system modeling and analysis, flight hardware and software development, and flight evaluations aboard a research vehicle.
NASA Marshall Space Flight Center and John Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.
NASA Marshall Space Flight Center and the Johns Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.
Wireless avionics could revolutionize current flight systems by reducing nonrecurring engineering, providing a means to rapidly develop and implement flight systems, and providing unprecedented insight into vehicle health, maintenance, and performance. Despite these benefits, there is still a relatively high level of cost and complexity associated with flight testing wireless systems.
The ASTEC (Analysis and Simulation Tools for Engineering Controls) software is under development at the Goddard Space Flight Center (GSFC). The design goal is to provide a wide selection of controls analysis tools at the personal computer level, as well as the capability to upload compute-intensive jobs to a mainframe or supercomputer. In the last three years the ASTEC (Analysis and Simulation Tools for Engineering Controls) software has been under development. ASTEC is meant to be an integrated collection of controls analysis tools for use at the desktop level. MODEL (Multi-Optimal Differential Equation Language) is a translator that converts programs written in the MODEL language to FORTRAN. An upgraded version of the MODEL program will be merged into ASTEC. MODEL has not been modified since 1981 and has not kept with changes in computers or user interface techniques. This paper describes the changes made to MODEL in order to make it useful in the 90's and how it relates to ASTEC.
The Communications and Tracking System on board Space Station Freedom (SSF) provides space-to-ground, space-to-space, audio, and video communications, as well as tracking data reception and processing services. Each major category of service is provided by a communications subsystem which is controlled and monitored by software. Among these subsystems, the Assembly/Contingency Subsystem (ACS) and the Space-to-Ground Subsystem (SGS) provide communications with the ground via the Tracking and Data Relay Satellite (TDRS) System. The ACS is effectively SSF's command link, while the SGS is primarily intended as the data link for SSF payloads. The research activities of this project focused on the ACS and SGS antenna management algorithms identified in the Flight System Software Requirements (FSSR) documentation, including: (1) software modeling and evaluation of antenna management (positioning) algorithms; and (2) analysis and investigation of selected variables and parameters of these antenna management algorithms i.e., descriptions and definitions of ranges, scopes, and dimensions. In a related activity, to assist those responsible for monitoring the development of this flight system software, a brief summary of software metrics concepts, terms, measures, and uses was prepared.
The Joint Execute Package Development and Integration tool is a Web utility program that provides an integrated capability to generate and manage messages and execute package data for members of a space shuttle and the International Space Station (ISS). (An execute package consists of flight plans, short-term plans, procedure updates, data needed to operate the space-shuttle and ISS systems, in-flight maintenance procedures, inventory-stowage data, software upgrades, flight notes, scripts for publicized events, and other instructions.) This program is a third-generation "execute"-package Web tool, built on experience gained from two programs used previously to support realtime operations. This program provides integration and synchronization between the space-shuttle and ISS teams during joint operations. Hundreds of messages per week must be uplinked as "joint" messages; that is, messages for crewmembers of both spacecraft. The program includes configuration-management components that ensure that the same message goes to both crews and spacecraft, effectively eliminating the potential for error in manual direction of messages. The program also controls the format and layout of the crews Web pages, ensuring consistency between uplinks. If the crews Web pages were edited manually, hyperlink and formatting errors would be common.
An algorithm for computationally lightweight simulation of automated air traffic control (ATC) at a busy airport has been derived. The algorithm is expected to serve as the basis for development of software that would be incorporated into flight-simulator software, the ATC component of which is not yet capable of handling realistic airport loads. Software based on this algorithm could also be incorporated into other computer programs that simulate a variety of scenarios for purposes of training or amusement.
… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.
… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.
GeoSAR Geographic Synthetic Aperture Radar) is a new 3 year effort to build a unique, dual-frequency, airborne Interferometric SAR for mapping of terrain. This is being pursued via a Consortium of the Jet Propulsion Laboratory (JPL), Calgis, Inc., and the California Department of Conservation. The airborne portion of this system will operate on a Calgis Gulfstream-II aircraft outfitted with P- and X-band Interferometric SARs. The ground portions of this system will be a suite of Flight Planning Software, an IFSAR Processor and a Radar-GIS Workstation. The airborne P-band and X-band radars will be constructed by JPL with the goal of obtaining foliage penetration at the longer P-band wavelengths. The P-band and X-band radar will operate at frequencies of 350 Mhz and 9.71 Ghz with bandwidths of either 80 or 160 Mhz. The airborne radars will be complemented with airborne laser system for measuring antenna positions. Aircraft flight lines and radar operating instructions will be computed with the Flight Planning Software The ground processing will be a two-step step process. First, the raw radar data will be processed into radar images and interferometer derived Digital Elevation Models (DEMs). Second, these radar images and DEMs will be processed with a Radar GIS Workstation which performs processes such as Projection Transformations, Registration, Geometric Adjustment, Mosaicking, Merging and Database Management. JPL will construct the IFSAR Processor and Calgis, Inc. will construct the Radar GIS Workstation. The GeoSAR Project was underway in November 1996 with a goal of having the radars and laser systems fully integrated onto the Calgis Gulfstream-II aircraft in early 1999. Then, Engineering Checkout and Calibration-Characterization Flights will be conducted through November 1999. The system will be completed at the end of 1999 and ready for routine operations in the year 2000.
This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.
A new fault-tolerant system software concept employing the primary digital computers as host for the backup software portion has been implemented and flight tested in the F-8 digital fly-by-wire airplane. The system was implemented in such a way that essentially no transients occurred in transferring from primary to backup software. This was accomplished without a significant increase in the complexity of the backup software. The primary digital system was frame synchronized, which provided several advantages in implementing the resident backup software system. Since the time of the flight tests, two other flight vehicle programs have made a commitment to incorporate resident backup software similar in nature to the system described in this paper.
A new fault-tolerant system software concept employing the primary digital computers as host for the backup software portion has been implemented and flight tested in the F-8 digital fly-by-wire airplane. The system was implemented in such a way that essentially no transients occurred in transferring from primary to backup software. This was accomplished without a significant increase in the complexity of the backup software. The primary digital system was frame synchronized, which provided several advantages in implementing the resident backup software system. Since the time of the flight tests, two other flight vehicle programs have made a commitment to incorporate resident backup software similar in nature to the system described here.