SEARCH · Search NASA

Results for “Data Reuse”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 271 records · Page 15

All sources NASA NTRS DOE OSTI

NASA NTRS1999

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗

NASA NTRS2003

Proposed Space Flight Experiment Hardware

The primary thrust for this plan is to develop design tools and fundamental understanding that are timely and consistent with the goal of the various exploration initiatives. The plan will utilize ISS facilities, such as the Fluids Integrated Rack (FIR) and the Microgravity Science Glovebox (MSG). A preliminary flow schematic of Two-Phase Flow Facility (T(phi)FFy) which would utilize FIR is shown in Figure 3. MSG can be utilized to use the Boiling eXperiment Facility (BXF) and Contact Line Dynamics Experiment (CLiDE) Facility. The T(phi)FFy system would have multiple test sections whereby different configurations of heat exchangers could be used to study boiling and condensation phenomena. The test sections would be instrumented for pressure drop, void fraction, heat fluxes, temperatures, high-speed imaging and other diagnostics. Besides a high-speed data acquisition system with a large data storage capability, telemetry could be used to update control and test parameters and download limited amounts of data. In addition, there would be multiple accumulators that could be used to investigate system stability and fluid management issues. The system could accommodate adiabatic tests through either the space station nitrogen supply or have an experiment-specific compressor to pressurize a sufficient amount of air or other non-condensable gas for reuse as the supply bottle is depleted.

Source record↗

NASA NTRS1979

An evaluation of the NASA Tech House, including live-in test results, volume 1

The NASA Tech House was designed and constructed at the NASA Langley Research Center, Hampton, Virginia, to demonstrate and evaluate new technology potentially applicable for conservation of energy and resources and for improvements in safety and security in a single-family residence. All technology items, including solar-energy systems and a waste-water-reuse system, were evaluated under actual living conditions for a 1 year period with a family of four living in the house in their normal lifestyle. Results are presented which show overall savings in energy and resources compared with requirements for a defined similar conventional house under the same conditions. General operational experience and performance data are also included for all the various items and systems of technology incorporated into the house design.

Abbott, I. H. A.↗

NASA NTRS1991

NASA information systems commonality and convergence

Efforts to identify high payback functions performed by the Office of Space Science Applications (OSSA) data systems package existing operationally proven implementations as system building blocks and foster their use in the OSSA environment. An overview is given of the current state of OSSA data systems and the major challenges facing system developers over the next five years. Current trends in system commonality are discussed, and development is examined in the context of system design. Central system engineering approaches to solving the commonality and interoperability challenges are described. Efforts to package three diverse building blocks and to foster their reuse are documented.

Handley, Thomas H., Jr.↗

NASA NTRS1994

Application Reuse Library for Software, Requirements, and Guidelines

Better designs are needed for expert systems and other operations automation software, for more reliable, usable and effective human support. A prototype computer-aided Application Reuse Library shows feasibility of supporting concurrent development and improvement of advanced software by users, analysts, software developers, and human-computer interaction experts. Such a library expedites development of quality software, by providing working, documented examples, which support understanding, modification and reuse of requirements as well as code. It explicitly documents and implicitly embodies design guidelines, standards and conventions. The Application Reuse Library provides application modules with Demo-and-Tester elements. Developers and users can evaluate applicability of a library module and test modifications, by running it interactively. Sub-modules provide application code and displays and controls. The library supports software modification and reuse, by providing alternative versions of application and display functionality. Information about human support and display requirements is provided, so that modifications will conform to guidelines. The library supports entry of new application modules from developers throughout an organization. Example library modules include a timer, some buttons and special fonts, and a real-time data interface program. The library prototype is implemented in the object-oriented G2 environment for developing real-time expert systems.

Malin, Jane T.↗

NASA NTRS2022

Natural Language Processing Techniques for Intelligent Knowledge Management of Safety Reports

Safety, failure, and incident reports are common artifacts across various domains, including aviation and wildfire response. These reports are often mandatory to submit, resulting in the culmination of large repositories of text-based documents. Simultaneously, these reports and corresponding repositories are often only manually analyzed and queried by users via out-of-date search engines. As a consequence, we have been developing the Manager for Intelligent Knowledge Access (MIKA) toolkit, which uses natural language processing to improve information access and reuse. In this presentation, we discuss natural language processing techniques for knowledge discovery and apply these methods to a repository of aerial wildfire mishap reports. Two methods are used for knowledge discovery: topic modeling and named-entity recognition. We use topic modeling to identify hazards and perform a trend analysis to produce a data-driven risk matrix. A custom named-entity recognition model, build from fine tuning a pre-trained language model, is used to identify failure modes, failure causes, failure effects, control processes, and recommendations to aid in failure modes and effects analysis (FMEA). Throughout the presentation, we discuss and apply natural language processing techniques to better leverage the vast amount of information contained in report repositories.

Machine learning↗

NASA NTRS2015

NASA Data Acquisition System Software Development for Rocket Propulsion Test Facilities

Current NASA propulsion test facilities include Stennis Space Center in Mississippi, Marshall Space Flight Center in Alabama, Plum Brook Station in Ohio, and White Sands Test Facility in New Mexico. Within and across these centers, a diverse set of data acquisition systems exist with different hardware and software platforms. The NASA Data Acquisition System (NDAS) is a software suite designed to operate and control many critical aspects of rocket engine testing. The software suite combines real-time data visualization, data recording to a variety formats, short-term and long-term acquisition system calibration capabilities, test stand configuration control, and a variety of data post-processing capabilities. Additionally, data stream conversion functions exist to translate test facility data streams to and from downstream systems, including engine customer systems. The primary design goals for NDAS are flexibility, extensibility, and modularity. Providing a common user interface for a variety of hardware platforms helps drive consistency and error reduction during testing. In addition, with an understanding that test facilities have different requirements and setups, the software is designed to be modular. One engine program may require real-time displays and data recording; others may require more complex data stream conversion, measurement filtering, or test stand configuration management. The NDAS suite allows test facilities to choose which components to use based on their specific needs. The NDAS code is primarily written in LabVIEW, a graphical, data-flow driven language. Although LabVIEW is a general-purpose programming language; large-scale software development in the language is relatively rare compared to more commonly used languages. The NDAS software suite also makes extensive use of a new, advanced development framework called the Actor Framework. The Actor Framework provides a level of code reuse and extensibility that has previously been difficult to achieve using LabVIEW. The

Herbert, Phillip W., Sr.↗

NASA NTRS2006

SpaceWire Protocol ID: What Does It Mean To You?

Spacewire is becoming a popular solution for satellite high-speed data buses because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of Spacewire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because Spacewire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of Spacewire to define unique packet formats and define how these packets are to be processed. Each mission writes their own Interface Control Document (ICD) and tailors Spacewire for their specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions. A new packet format for Spacewire has been defined as a solution for this problem. This new packet format is a compliment to the Spacewire standard that will support protocol development upon Spacewire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over Spacewire. The Spacewire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the Spacewire. The new extended packet format adds one new field to the packet that greatly enhances the capability of Spacewire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the Spacewire working group and the protocol description published for others to use. The development of Protocols for Spacewire is currently the area of greatest activity by the Spacewire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.

Rakow, Glenn↗

NASA NTRS2015

Towards a Generic and Adaptive System-On-Chip Controller for Space Exploration Instrumentation

This paper introduces one of the first efforts conducted at NASA’s Jet Propulsion Laboratory (JPL) to develop a generic System-on-Chip (SoC) platform to control science instruments that are proposed for future NASA missions. The SoC platform is named APEX-SoC, where APEX stands for Advanced Processor for space Exploration, and is based on a hybrid Xilinx Zynq that combines an FPGA and an ARM Cortex-A9 dual-core processor on a single chip. The Zynq implements a generic and customizable on-chip infrastructure that can be reused with a variety of instruments, and it has been coupled with a set of off-chip components that are necessary to deal with the different instruments. We have taken JPL’s Compositional InfraRed Imaging Spectrometer (CIRIS), which is proposed for NASA icy moons missions, as a use-case scenario to demonstrate that the entire data processing, control and interface of an instrument can be implemented on a single device using the on-chip infrastructure described in this paper. We show that the performance results achieved in this preliminary version of the instrumentation controller are sufficient to fulfill the science requirements demanded to the CIRIS instrument in future NASA missions, such as Europa.

embedded system↗

NASA NTRSDate not supplied

An Overview of MaGIXS-2: The second flight of the Marshall Grazing Incidence X-ray Spectrometer

The Marshall Grazing Incidence X-ray Spectrometer (MaGIXS) is a sounding rocket mission that completed a successful flight from the White Sands Missile Range on July 30, 2021. MaGIXS captured spatially resolved soft X-ray spectra from portions of two solar active regions during its roughly 5-minute flight. The instrument was originally designed as a grazing incidence slit spectrograph but flew in a slit-less configuration that produced overlapping spectroheliograms. For the second flight, MaGIXS-2, the instrument has been reconfigured to a more simplified optical layout that reuses the Wolter-I telescope and blazed varied-line space reflective grating. The field stop at the telescope focal plane and the finite conjugate spectrometer mirror pair have been removed – the telescope now directly feeds the grating. Additionally, an identical but new 2k x 1k CCD camera has been built for this flight. The MaGIXS-2 data product will again be overlapping spectroheliograms of at least one solar active region, but with improved resolution, a larger field of view and increased effective area. Here we present the updated instrument layout, the expected performance, the integration and calibration approach, and proposed future improvements, including the implementation of additional complimentary spectral diagnostics.

Imaging Spectrometer↗

NASA NTRS1983

Customer premise service study for 30/20 GHz satellite system

Satellite systems in which the space segment operates in the 30/20 GHz frequency band are defined and compared as to their potential for providing various types of communications services to customer premises and the economic and technical feasibility of doing so. Technical tasks performed include: market postulation, definition of the ground segment, definition of the space segment, definition of the integrated satellite system, service costs for satellite systems, sensitivity analysis, and critical technology. Based on an analysis of market data, a sufficiently large market for services is projected so as to make the system economically viable. A large market, and hence a high capacity satellite system, is found to be necessary to minimize service costs, i.e., economy of scale is found to hold. The wide bandwidth expected to be available in the 30/20 GHz band, along with frequency reuse which further increases the effective system bandwidth, makes possible the high capacity system. Extensive ground networking is required in most systems to both connect users into the system and to interconnect Earth stations to provide spatial diversity. Earth station spatial diversity is found to be a cost effective means of compensating the large fading encountered in the 30/20 GHz operating band.

Milton, R. T.↗

NASA NTRS2006

A Concept for Run-Time Support of the Chapel Language

A document presents a concept for run-time implementation of other concepts embodied in the Chapel programming language. (Now undergoing development, Chapel is intended to become a standard language for parallel computing that would surpass older such languages in both computational performance in the efficiency with which pre-existing code can be reused and new code written.) The aforementioned other concepts are those of distributions, domains, allocations, and access, as defined in a separate document called "A Semantic Framework for Domains and Distributions in Chapel" and linked to a language specification defined in another separate document called "Chapel Specification 0.3." The concept presented in the instant report is recognition that a data domain that was invented for Chapel offers a novel approach to distributing and processing data in a massively parallel environment. The concept is offered as a starting point for development of working descriptions of functions and data structures that would be necessary to implement interfaces to a compiler for transforming the aforementioned other concepts from their representations in Chapel source code to their run-time implementations.

James, Mark↗

NASA NTRS1991

Liquid booster engine reuse - A recovery system

The paper presents the design of a recovery system for a suborbital payload of an Atlas E rocket. This program utilizes off-the-shelf and previously qualified avionics, flotation, and decelerator systems. A brief history of liquid-engine recoveries is presented first, then the system design utilizing two self-contained structurally-identical pods diametrically mounted to the thrust section is outlined. A mortar-deployed drogue and the main parachute are described, and experimental procedures are considered. Data obtained from one tricluster drop employing a cylindrical test vehicle and helicopter is analyzed, and a satisfactory load balance between the parachutes is observed.

Von Eckroth, Wulf↗

NASA NTRS1979

Summary results from the NASA Tech House one year live-in

The NASA Tech House was designed and constructed at the Langley Research Center, Hampton, Va., to demonstrate and evaluate new technology potentially applicable for conservation of energy and resources and for improvements in safety and security in a single-family residence. All technology items, including solar energy systems and a waste water reuse system, were evaluated under actual living conditions for a one-year period with a family of four living in the house in their normal life style. Results are presented which show overall savings in energy and resources compared to requirements for a defined similar conventional house under the same conditions. Also included are general operational experience and performance data for all the various items and systems of technology incorporated into the house design.

Hamlet, I. L.↗

NASA NTRS1994

Generic trending and analysis system

The Generic Trending and Analysis System (GTAS) is a generic spacecraft performance monitoring tool developed by NASA Code 511 and Loral Aerosys. It is designed to facilitate quick anomaly resolution and trend analysis. Traditionally, the job of off-line analysis has been performed using hardware and software systems developed for real-time spacecraft contacts; then, the systems were supplemented with a collection of tools developed by Flight Operations Team (FOT) members. Since the number of upcoming missions is increasing, NASA can no longer afford to operate in this manner. GTAS improves control center productivity and effectiveness because it provides a generic solution across multiple missions. Thus, GTAS eliminates the need for each individual mission to develop duplicate capabilities. It also allows for more sophisticated tools to be developed because it draws resources from several projects. In addition, the GTAS software system incorporates commercial off-the-shelf tools software (COTS) packages and reuses components of other NASA-developed systems wherever possible. GTAS has incorporated lessons learned from previous missions by involving the users early in the development process. GTAS users took a proactive role in requirements analysis, design, development, and testing. Because of user involvement, several special tools were designed and are now being developed. GTAS users expressed considerable interest in facilitating data collection for long term trending and analysis. As a result, GTAS provides easy access to large volumes of processed telemetry data directly in the control center. The GTAS archival and retrieval capabilities are supported by the integration of optical disk technology and a COTS relational database management system.

Keehan, Lori↗

NASA NTRS2024

Considerations for Using Autonomous Flight Termination Software in Crewed Launch Vehicles

Autonomous flight termination systems (AFTS) are being progressively employed onboard launch vehicles to replace ground personnel and infrastructure needed to terminate flight or destruct the vehicle should an anomaly occur. This automation uses on-board real-time data and encoded logic to determine if the flight should be self-terminated. For uncrewed launch vehicles, FTS systems are required to protect the public and governed by the United States Space Force (USSF). For crewed missions, NASA must augment range AFTS requirements for crew safety and certify each flight according to human rating standards, thus adding unique requirements for reuse of software originally intended for uncrewed missions. This bulletin summarizes new information relating to AFTS to raise awareness of key distinctions, summarize considerations and outline best practices for incorporating AFTS into human-rated systems.

Avionics↗

NASA NTRS1990

Advanced Communications Technology Satellite (ACTS)

The benefits that will be offered by the NASA-sponsored communication spacecraft ACTS which is scheduled for launch in 1992 are described together with examples of demonstrations on proposed data, video, and voice applications supported by the advanced ACTS technologies. Compared to existing satellite service, the ACTS will provide lower cost, better service, greater convenience, and improved service reliability of telecommunications to customers around the world. In addition, the pioneering ACTS technology will provide many capabilities qualitatively different from those of current satellite systems, such as on-demand assignment, frequency reuse, and the flexible targeting of spot beams directly to the very-small-aperture terminals at customer premises.

Olmstead, Dean A.↗

NASA NTRS1993

Structural design/margin assessment

Determining structural design inputs and the structural margins following design completion is one of the major activities in space exploration. The end result is a statement of these margins as stability, safety factors on ultimate and yield stresses, fracture limits (fracture control), fatigue lifetime, reuse criteria, operational criteria and procedures, stability factors, deflections, clearance, handling criteria, etc. The process is normally called a load cycle and is time consuming, very complex, and involves much more than structures. The key to successful structural design is the proper implementation of the process. It depends on many factors: leadership and management of the process, adequate analysis and testing tools, data basing, communications, people skills, and training. This process and the various factors involved are discussed.

Ryan, R. S.↗