Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data engineering”

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 955 records · Page 53
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Enabling and Enhancing Space Mission Success and Reduction of Risk through the Application of an Integrated Data Architecture

The engineering phases of design, development, test, and evaluation (DDT and E) and subsequent planning, preparation, and operation (Ops) of space vehicles in a complex and distributed environment requires massive and continuous flows of information across the enterprise and across temporal stages of the vehicle lifecycle. The resulting capabilities at each subsequent stage depend in part on the capture, preparation, storage, and subsequent provision of information from prior stages. The United States National Aeronautics and Space Administration (NASA) is currently designing a fleet of new vehicles that will replace the Space Shuttle and expand space operations and exploration capabilities. This includes the 2 stage human rated lift vehicle Ares 1 and its associated crew vehicle the Orion, and a service module; the heavy lift cargo vehicle, Ares 5, and an associated cargo stage known as the Earth Departure Stage; and a Lunar Lander vehicle that contains a descent stage, and ascent stage, and a habitation module. A variety of concurrent assorted ground operations infrastructure including software and facilities are also being developed, assorted technology and assembly designs and development for equipment such as EVA suits, life support systems, command and control technologies are also in the pipeline. The development is occurring in a distributed manner, with project deliverables being contributed by a large and diverse assortment of vendors and most space faring nations. Critical information about all of the components, software, and procedures must be shared during the DDT and E phases and then made readily available to the mission operations staff for access during the planning, preparation, and operations phases, and also need to be readily available for system to system interactions. The Constellation Data Systems Project (CxDS) is identifying the needs, and designing and deploying systems and processes to support these needs. This paper details the steps and processes that NASA is applying within the Constellation Program to manage this data and information, and to insure that the correct information is available, correctly annotated, and can be provisioned digitally to enhance response times, and support engineering analysis and anomaly resolution.

Brummett, Robert C.↗
NASA NTRS1978

The stirling engine for vehicle propulsion

The performance data of experimental Stirling engines are considered along with questions of exhaust-gas composition, engine noise, engine volume and weight, engine control, and the engine-starting process. The Stirling engine can use practically any liquid or gaseous fuel for its operation. It is found that technically a use of the Stirling engine in motor vehicles is feasible. Economic questions related to an introduction of the Stirling engine are discussed along with possible new developments which could improve the economic situation in favor of a use of Stirling engine.

Kuhlman, P.↗
NASA NTRS1940

Correlation of Cooling Data from an Air-Cooled Cylinder and Several Multicylinder Engines

The theory of engine-cylinder cooling developed in a previous report was further substantiated by data obtained on a cylinder from a Wright r-1820-g engine. Equations are presented for the average head and barrel temperatures of this cylinder as functions of the engine and the cooling conditions. These equations are utilized to calculate the variation in cylinder temperature with altitude for level flight and climb. A method is presented for correlating average head and barrel temperatures and temperatures at individual points on the head and the barrel obtained on the test stand and in flight. The method is applied to the correlation and the comparison of data obtained on a number of service engines. Data are presented showing the variation of cylinder temperature with time when the power and the cooling pressure drop are suddenly changed.

Pinkel, Benjamin↗
NASA NTRS1992

Engine systems analysis results of the Space Shuttle Main Engine redesigned powerhead initial engine level testing

Engineers regularly analyze SSME ground test and flight data with respect to engine systems performance. Recently, a redesigned SSME powerhead was introduced to engine-level testing in part to increase engine operational margins through optimization of the engine internal environment. This paper presents an overview of the MSFC personnel engine systems analysis results and conclusions reached from initial engine level testing of the redesigned powerhead, and further redesigns incorporated to eliminate accelerated main injector baffle and main combustion chamber hot gas wall degradation. The conclusions are drawn from instrumented engine ground test data and hardware integrity analysis reports and address initial engine test results with respect to the apparent design change effects on engine system and component operation.

Sander, Erik J.↗
NASA NTRS2008

Application of the Systematic Sensor Selection Strategy for Turbofan Engine Diagnostics

The data acquired from available system sensors forms the foundation upon which any health management system is based, and the available sensor suite directly impacts the overall diagnostic performance that can be achieved. While additional sensors may provide improved fault diagnostic performance there are other factors that also need to be considered such as instrumentation cost, weight, and reliability. A systematic sensor selection approach is desired to perform sensor selection from a holistic system-level perspective as opposed to performing decisions in an ad hoc or heuristic fashion. The Systematic Sensor Selection Strategy is a methodology that optimally selects a sensor suite from a pool of sensors based on the system fault diagnostic approach, with the ability of taking cost, weight and reliability into consideration. This procedure was applied to a large commercial turbofan engine simulation. In this initial study, sensor suites tailored for improved diagnostic performance are constructed from a prescribed collection of candidate sensors. The diagnostic performance of the best performing sensor suites in terms of fault detection and identification are demonstrated, with a discussion of the results and implications for future research.

Sowers, T. Shane↗
NASA NTRS2008

Application of the Systematic Sensor Selection Strategy for Turbofan Engine Diagnostics

The data acquired from available system sensors forms the foundation upon which any health management system is based, and the available sensor suite directly impacts the overall diagnostic performance that can be achieved. While additional sensors may provide improved fault diagnostic performance, there are other factors that also need to be considered such as instrumentation cost, weight, and reliability. A systematic sensor selection approach is desired to perform sensor selection from a holistic system-level perspective as opposed to performing decisions in an ad hoc or heuristic fashion. The Systematic Sensor Selection Strategy is a methodology that optimally selects a sensor suite from a pool of sensors based on the system fault diagnostic approach, with the ability of taking cost, weight, and reliability into consideration. This procedure was applied to a large commercial turbofan engine simulation. In this initial study, sensor suites tailored for improved diagnostic performance are constructed from a prescribed collection of candidate sensors. The diagnostic performance of the best performing sensor suites in terms of fault detection and identification are demonstrated, with a discussion of the results and implications for future research.

Sowers, T. Shane↗
NASA NTRS1972

The Mariner Venus Mercury flight data subsystem.

The flight data subsystem (FDS) discussed handles both the engineering and scientific measurements performed on the MVM'73. It formats the data into serial data streams, and sends it to the modulation/demodulation subsystem for transmission to earth or to the data storage subsystem for storage on a digital tape recorder. The FDS is controlled by serial digital words, called coded commands, received from the central computer sequencer of from the ground via the modulation/demodulation subsystem. The eight major blocks of the FDS are: power converter, timing and control, engineering data, memory, memory input/output and control, nonimaging data, imaging data, and data output. The FDS incorporates some 4000 components, weighs 17 kg, and uses 35 W of power. General data on the mission and spacecraft are given.

Whitehead, P. B.↗
NASA NTRS1993

Impeller flow field characterization with a laser two-focus velocimeter

Use of Computational Fluid Dynamics (CFD) codes, prevalent in the rocket engine turbomachinery industry, necessitates data of sufficient quality and quantity to benchmark computational codes. Existing data bases for typical rocket engine configurations, in particular impellers, are limited. In addition, traditional data acquisition methods have several limitations: typically transducer uncertainties are 0.5% of transducer full scale and traditional pressure probes are unable to provide flow characteristics in the circumferential (blade-to-blade) direction. Laser velocimetry circumvents these limitations by providing +0.5% uncertainty in flow velocity and +0.5% uncertainty in flow angle. The percent of uncertainty in flow velocity is based on the measured value, not full range capability. The laser electronics multiple partitioning capability allows data acquired between blades as the impeller rotates, to be analyzed separately, thus providing blade-to-blade flow characterization. Unlike some probes, the non-intrusive measurements made with the laser velocimeter does not disturb the flow. To this end,, and under Contract (NAS8-38864) to the National Aeronautics and Space Administration (NASA) at Marshall Space Flight Center (MSFC), an extensive test program was undertaken at Rocketdyne. Impellers from two different generic rocket engine pump configurations were examined. The impellers represent different spectrums of pump design: the Space Shuttle Main Engine (SSME) high pressure fuel turbopump (HPFTP) impeller was designed in the 1 1970's the Consortium for CFD application in Propulsion Technology Pump Stage Technology Team (Pump Consortium) optimized impeller was designed with the aid of modern computing techniques. The tester configuration for each of the impellers consisted of an axial inlet, an inducer, a diffuser, and a crossover discharge. While the tested configurations were carefully chosen to be representative of generic rocket engine pumps, several features of both testers were intentionally atypical. A crossover discharge, downstream of the impeller, rather than a volute discharge was used to minimize asymmetric flow conditions that might be reflected in the impeller discharge flow data. Impeller shroud wear ring radial clearances were purposely close to minimize leakage flow, thus increasing confidence in using the inlet data as an input to CFD programs. The empirical study extensively examined the flow fields of the two impellers via performance of laser two-focus velocimeter surveys in an axial plane upstream of the impellers and in multiple radial planes downstream of the impellers. Both studies were performed at the impeller design flow coefficients. Inlet laser surveys that provide CFD code inlet boundary conditions were performed in one axial plane, with ten radial locations surveyed. Three wall static pressures, positioned circumferentially around the impeller inlet, were used to identify asymmetrical pressure distributions in the inlet survey plane. The impeller discharge flow characterization consisted of three radial planes for the SSME HPFTP impeller and two radial planes for the Pump Consortium optimized impeller. Housing wall static pressures were placed to correspond to the radial locations surveyed with the laser velocimeter. Between five and thirteen axial stations across the discharge channel width were examined in each radial plane during the extensive flow mapping. The largely successful empirical flow characterization of two different impellers resulted in a substantial contribution to the limited existing data base, and yielded accurate data for CFD code benchmarking.

Brozowski, L. A.↗
NASA NTRS2019

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation↗
NASA NTRS1990

Reliability growth modeling analysis of the space shuttle main engines based upon the Weibull process

The Weibull process, identified as the inhomogeneous Poisson process with the Weibull intensity function, is used to model the reliability growth assessment of the space shuttle main engine test and flight failure data. Additional tables of percentage-point probabilities for several different values of the confidence coefficient have been generated for setting (1-alpha)100-percent two sided confidence interval estimates on the mean time between failures. The tabled data pertain to two cases: (1) time-terminated testing, and (2) failure-terminated testing. The critical values of the three test statistics, namely Cramer-von Mises, Kolmogorov-Smirnov, and chi-square, were calculated and tabled for use in the goodness of fit tests for the engine reliability data. Numerical results are presented for five different groupings of the engine data that reflect the actual response to the failures.

Wheeler, J. T.↗
NASA NTRS2006

Integrating International Engineering Organizations For Successful ISS Operations

The International Space Station (ISS) is a multinational orbiting space laboratory that is built in cooperation with 16 nations. The design and sustaining engineering expertise is spread worldwide. As the number of Partners with orbiting elements on the ISS grows, the challenge NASA is facing as the ISS integrator is to ensure that engineering expertise and data are accessible in a timely fashion to ensure ongoing operations and mission success. Integrating international engineering teams requires definition and agreement on common processes and responsibilities, joint training and the emergence of a unique engineering team culture. ISS engineers face daunting logistical and political challenges regarding data sharing requirements. To assure systematic information sharing and anomaly resolution of integrated anomalies, the ISS Partners are developing multi-lateral engineering interface procedures. Data sharing and individual responsibility are key aspects of this plan. This paper describes several examples of successful multilateral anomaly resolution. These successes were used to form the framework of the Partner to Partner engineering interface procedures, and this paper describes those currently documented multilateral engineering processes. Furthermore, it addresses the challenges experienced to date, and the forward work expected in establishing a successful working relationship with Partners as their hardware is launched.

Blome, Elizabeth↗
NASA NTRS1977

Altimeter waveform software design

Techniques are described for preprocessing raw return waveform data from the GEOS-3 radar altimeter. Topics discussed include: (1) general altimeter data preprocessing to be done at the GEOS-3 Data Processing Center to correct altimeter waveform data for temperature calibrations, to convert between engineering and final data units and to convert telemetered parameter quantities to more appropriate final data distribution values: (2) time "tagging" of altimeter return waveform data quantities to compensate for various delays, misalignments and calculational intervals; (3) data processing procedures for use in estimating spacecraft attitude from altimeter waveform sampling gates; and (4) feasibility of use of a ground-based reflector or transponder to obtain in-flight calibration information on GEOS-3 altimeter performance.

Hayne, G. S.↗
NASA NTRS1987

Mod II engine development

The Mod II engine, a four-cylinder, automotive Stirling engine utilizing the Siemens-Rinia double-acting concept, was assembled and became operational in January 1986. This paper describes the Mod II engine, its first assembly, and the subsequent development work done on engine components up to the point that engine performance characterization testing took place. Performance data for the engine are included.

Karl, David W.↗
NASA NTRS2004

Initial Processing of Infrared Spectral Data

The Atmospheric Infrared Spectrometer (AIRS) Science Processing System is a collection of computer programs, denoted product generation executives (PGEs), for processing the readings of the AIRS suite of infrared and microwave instruments orbiting the Earth aboard NASA's Aqua spacecraft. Following from level 0 (representing raw AIRS data), the PGEs and their data products are denoted by alphanumeric labels (1A, 1B, and 2) that signify the successive stages of processing. Once level-0 data have been received, the level-1A PGEs begin processing, performing such basic housekeeping tasks as ensuring that all the Level-0 data are present and ordering the data according to observation times. The level-1A PGEs then perform geolocation-refinement calculations and conversions of raw data numbers to engineering units. Finally, the level-1A data are grouped into packages, denoted granules, each of which contain the data from a six-minute observation period. The granules are forwarded, along with calibration data, to the Level-1B PGEs for processing into calibrated, geolocated radiance products. The Level-2 PGEs, which are not yet operational, are intended to process the level-1B data into temperature and humidity profiles, and other geophysical properties.

De Picciotto, Solomon↗
NASA NTRS2012

Lessons Learned from Ares I Upper Stage Structures and Thermal Design

The Ares 1 Upper Stage was part of the vehicle intended to succeed the Space Shuttle as the United States manned spaceflight vehicle. Although the Upper Stage project was cancelled, there were many lessons learned that are applicable to future vehicle design. Lessons learned that are briefly detailed in this Technical Memorandum are for specific technical areas such as tank design, common bulkhead design, thrust oscillation, control of flight and slosh loads, purge and hazardous gas system. In addition, lessons learned from a systems engineering and vehicle integration perspective are also included, such as computer aided design and engineering, scheduling, and data management. The need for detailed systems engineering in the early stages of a project is emphasized throughout this report. The intent is that future projects will be able to apply these lessons learned to keep costs down, schedules brief, and deliver products that perform to the expectations of their customers.

Ahmed, Rafiq↗
NASA NTRS2020

Tuning a variational autoencoder for data accountability problem in the Mars Science Laboratory ground data system

The Mars Curiosity rover is frequently sending back engineering and science data that goes through a pipeline of systems before reaching its final destination at the mission operations center making it prone to volume loss and data corruption. A ground data system analysis (GDSA) team is charged with the monitoring of this flow of information and the detection of anomalies in that data in order to request a re-transmission when necessary. This work presents ∆-MADS, a derivative-free optimization method applied for tuning the architecture and hyperparameters of a variational autoencoder trained to detect the data with missing patches in order to assist the GDSA team in their mission.

Lakhmiri, Dounia↗
NASA NTRSDate not supplied

A Science-Focused Artificial Intelligence (AI) Responding in Real-Time to New Information: Capability Demonstration for Ocean World Missions

Introduction: Artificial intelligence (AI) has long been considered a potential mechanism to explore increasingly challenging environments, including those with extreme temperatures and pressures, limited communication capabilities, or those with demanding terrain. We posit that missions in extreme environments could deploy an onboard AI focused on science observations and goals in order to augment a traditional concept(s) of operations (ConOps). An onboard AI capability could perform functions such as data analysis in order to make high-level decisions, including prioritized data transmission for analysis by ground-based teams or autonomously-guided follow-on analyses that maximize science return. Such a capability would empower missions to respond to scientific data of interest in real-time; a mission could make observations and perform a preliminary analysis to alert ground-based scientists to an observation of interest, enabling an informed, rapid response from Earth-based teams. Enceladus Case Study for Onboard AI: We are developing an onboard AI capability for real-time telemetry response that formulates and carries-out informed decisions in service to established mission goals, enabling increased science return of a mission. We focus our AI development for use on a constellation of SmallSats orbiting Enceladus. Our Enceladus case study tests autonomous decision-making capabilities in scenarios with complex orbital dynamics, plume ejecta, extreme cold environments, power restrictions, and a requirement to maximize science return for a potential positive detection of life, while critically evaluating the potential for false positives. Telemetry includes simulated scientific data, spacecraft onboard operational data (e.g., position, velocity, and rotation), and engineering hardware performance data. Enceladus SmallSat Constellation. Our constellation includes eight SmallSat spacecraft in an 8:35 resonant orbit-based formation, leveraging Saturn’s gravitational forces to maintain stable orbits with global coverage around Enceladus. To our knowledge, we simulate the first stable configuration of multiple spacecraft in closed orbits around Enceladus, using a full ephemeris force model (Russell and Lara, 2009). Each spacecraft’s orbit will precess, causing an eastward ground track shift (from an orbiter’s perspective) of each spacecraft for each orbit. However, all spacecraft return to their original positions relative to Enceladus after eight Enceladus revolutions around Saturn. We model communication pathways between SmallSats to understand how information would need to be transmitted across the constellation to enable AI-driven decision-making and resource allocation across the fleet. Capability Demonstration. Our simulated capability demonstration inputs position, velocity, and rotation telemetry from our Enceladus-focused constellation simulations, and mass spectrometry data collected from abiotic and biotic laboratory-analog ocean world experiments (Theiling et al., 2018; Theiling, 2021; Da Poian et al., 2023). Data from these experiments are used to simulate MS measurements and different scenarios of science observations for onboard analysis performed on each of the eight spacecraft. For these demonstrations, we integrate 24 machine learning (ML) algorithms into an onboard intelligence as a ‘knowledge base’, including algorithms evaluating data quality and those predicting (with % confidence) gas composition, ocean aqueous chemistry, and whether the sample was influenced by microbial life. The onboard AI capability is designed to use the knowledge base to come to a consensus-based decision in the interpretation of the observed data in order to request additional action outside of a pre-defined ConOps. Requested actions could include e.g., prioritized downlink to Earth (for analysis by ground-based teams) or follow-on analyses performed across the constellation. The spacecraft’s intelligent onboard planner must then determine whether sufficient resources (e.g., time, power, etc.) are available and weigh the request with mission priorities. In our simulation, the constellation is able to identify potential biosignatures using onboard ML algorithms, evaluate the confidence of that prediction, and perform follow-on analyses across the fleet to confirm the detection, in order to best prepare a transmission of these data to Earth-based teams.

astrobiology↗