Search NASA⌕ Search

SEARCH · Search NASA

Results for “engine starts”

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 253 records · Page 14

NASAs Succeeds in Testing of Advanced Rotating Detonation Rocket Engine for New US Space Flight Capability

June-August 2022, NASA engineers at Marshall Space Flight Center in Huntsville Alabama have successfully fired two regeneratively cooled advanced rotating detonation rocket engines (RDRE’s). The engines have accumulated 17 starts at over 600 seconds of total duration. Multiple firings were achieved of greater than 110 seconds each with detonation modes. A single full throttle test produced over 4000 lbf for 15 seconds with detonation modes. The mean pressure at a single point on the injector face was 620 psia. These tests completed the project’s main objective: demonstrating that additive GRCop-alloy hardware could survive long durations while subjected to the detonative events. 4-5 co-rotating detonations were observed during most tests with a single test showing 2-3 waves. Several other milestones were also achieved including successful demonstration of active throttling with detonation modes, successful ignition without a predetonator, and the use of novel additive manufacturing techniques. The primary collaborator was IN Space, LLC (West Lafayette, IN) through an STMD announcement for collaborative opportunity (ACO). Hot fire testing was conducted at Marshall Space Flight Centers heritage east test area at Test Stand 115 in collaboration with Marshall ET10.

Thomas Teasley↗

EVA Hand Tool Design Considerations, Development, and General Requirements Interpretation: A Junior Engineer’s Guide

This paper serves as a guide to developing hand tools for use by crewmembers during extravehicular activity (EVA) in outer space. It outlines the fundamentals of EVAs and related provisions, providing a starting point and perspective for engineers unfamiliar with designing equipment to be used during manned spaceflight. Common EVA hardware constraints, which are often unclear, are interpreted and traced back to a source or justification because, as in any design field, fully understanding the basis and intent of a design requirement is needed to properly satisfy it. Lastly, miscellaneous design considerations and lessons learned in tool development are discussed. The information found within is drawn from commonly cited NASA and EVA related documents as well as from professional experiences.

EVA↗

Performance and Operational Characteristics of a Python Turbine-propeller Engine at Simulated Altitude Conditions / Carl L. Meyer and Lavern A. Johnson

The performance and operational characteristics of a Python turbine propeller engine have been investigated over a range of engine operating conditions at simulated altitudes from 5000 to 40,000 feet in the NACA Lewis altitude wind tunnel . For the performance phase of the investigation, a single cowl-inlet ram pressure ratio was maintained and independent control of engine speed and fuel flow was used to obtain a range of power at each engine speed. Engine performance data obtained at a given altitude could not be used to predict performance accurately at other altitudes by use of the standard air pressure and temperature generalizing factors. Specific fuel consumption based on shaft horsepower decreased as the shaft horsepower increased at a given engine speed. At a given altitude condition and turbine -inlet total temperature, there was an optimum engine speed at which maximum shaft horsepower was obtained. At a given engine speed and turbine-inlet total temperature, a greater portion of the total available energy was converted to propulsive power as the altitude increased. Windmilling starts were made at altitudes up to 40,000 feet; the minimum true airspeed required for successful windmilling starts increased as the altitude was raised. In general, the engine control prevented large overshoots or undershoots of engine speed during starts, accelerations, and decelerations.

Engines - Armstrong-Siddely Python Turbo-Propeller↗

Identification and Classification of Common Risks in Space Science Missions

Due to the highly constrained schedules and budgets that NASA missions must contend with, the identification and management of cost, schedule and risks in the earliest stages of the lifecycle is critical. At the Jet Propulsion Laboratory (JPL) it is the concurrent engineering teams that first address these items in a systematic manner. Foremost of these concurrent engineering teams is Team X. Started in 1995, Team X has carried out over 1000 studies, dramatically reducing the time and cost involved, and has been the model for other concurrent engineering teams both within NASA and throughout the larger aerospace community. The ability to do integrated risk identification and assessment was first introduced into Team X in 2001. Since that time the mission risks identified in each study have been kept in a database. In this paper we will describe how the Team X risk process is evolving highlighting the strengths and weaknesses of the different approaches. The paper will especially focus on the identification and classification of common risks that have arisen during Team X studies of space based science missions.

Risk Identification↗

A Model-Based Systems Engineering Journey to Developing a Concept of Operations

Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.

Jeffrey Robert Cohen↗

Knowledge-Based Aircraft Automation: Managers Guide on the use of Artificial Intelligence for Aircraft Automation and Verification and Validation Approach for a Neural-Based Flight Controller

The ultimate goal of this report was to integrate the powerful tools of artificial intelligence into the traditional process of software development. To maintain the US aerospace competitive advantage, traditional aerospace and software engineers need to more easily incorporate the technology of artificial intelligence into the advanced aerospace systems being designed today. The future goal was to transition artificial intelligence from an emerging technology to a standard technology that is considered early in the life cycle process to develop state-of-the-art aircraft automation systems. This report addressed the future goal in two ways. First, it provided a matrix that identified typical aircraft automation applications conducive to various artificial intelligence methods. The purpose of this matrix was to provide top-level guidance to managers contemplating the possible use of artificial intelligence in the development of aircraft automation. Second, the report provided a methodology to formally evaluate neural networks as part of the traditional process of software development. The matrix was developed by organizing the discipline of artificial intelligence into the following six methods: logical, object representation-based, distributed, uncertainty management, temporal and neurocomputing. Next, a study of existing aircraft automation applications that have been conducive to artificial intelligence implementation resulted in the following five categories: pilot-vehicle interface, system status and diagnosis, situation assessment, automatic flight planning, and aircraft flight control. The resulting matrix provided management guidance to understand artificial intelligence as it applied to aircraft automation. The approach taken to develop a methodology to formally evaluate neural networks as part of the software engineering life cycle was to start with the existing software quality assurance standards and to change these standards to include neural network development. The changes were to include evaluation tools that can be applied to neural networks at each phase of the software engineering life cycle. The result was a formal evaluation approach to increase the product quality of systems that use neural networks for their implementation.

Broderick, Ron↗

Development of thermostable carbonic anhydrases using structure-guided recombination for use in CO2 removal systems on spacecraft

Carbon capture and storage has been a research area of great interest in recent years asa method for mitigation of CO2emissions, due to the effects of climate change. The development of technologies for the efficient capture of CO2are also of great interest for human spaceflight applications. One of the most promising technologies in this area is CO2 scrubbing using liquid amines, unfortunately, liquid amines with low heats of desorption tend to have slow CO2binding kinetics. One potential solution to this problem is to use the enzyme carbonic anhydrase (CA) to enhance the kinetics of CO2binding to liquid amines, allowing the overall process to be more energy efficient. Interest in using carbonic anhydrase as a biocatalyst has led to a number of efforts to improve the thermostability and solvent tolerance of several distinct carbonic anhydrase enzymes. In the work described here, we screened through a diverse set of natural carbonic anhydrases to identify candidates for protein engineering aimed at increased stability and activity in various liquid amines. We then used SCHEMA structure-guided recombination to develop a set of chimeric carbonic anhydrases with high thermostability and activity. These chimeras were used as the starting points for further protein engineering work targeting activity in liquid amine systems. Our ultimate goal is to test the engineered enzymes in a liquid amine system for cabin air revitalization on ISS or other spacecraft.

Life Support↗

Development of Thermostable Carbonic Anhydrases Using Structure-Guided Recombination for Use in CO2 Removal Systems on Spacecraft

Carbon capture and storage has been a research area of great interest in recent years as a method for mitigation of CO2 emissions, due to the effects of climate change. The development of technologies for the efficient capture of CO2 are also of great interest for human spaceflight applications. One of the most promising technologies in this area is CO2 scrubbing using liquid amines, unfortunately, liquid amines with low heats of desorption tend to have slow CO2 binding kinetics. One potential solution to this problem is to use the enzyme carbonic anhydrase (CA) to enhance the kinetics of CO2 binding to liquid amines, allowing the overall process to be more energy efficient. Interest in using carbonic anhydrase as a biocatalyst has led to a number of efforts to improve the thermostability and solvent tolerance of several distinct carbonic anhydrase enzymes. In the work described here, we screened through a diverse set of natural carbonic anhydrases to identify candidates for protein engineering aimed at increased stability and activity in various liquid amines. We then used SCHEMA structure-guided recombination to develop a set of chimeric carbonic anhydrases with high thermostability and activity. These chimeras were used as the starting points for further protein engineering work targeting activity in liquid amine systems. Our ultimate goal is to test the engineered enzymes in a liquid amine system for cabin air revitalization on ISS or other spacecraft.

Life Support, Carbon dioxide, Carbonic anhydrase, ↗

Liquid Oxygen/Liquid Methane Ascent Main Engine Technology Development

The National Aeronautics & Space Administration (NASA) has identified Liquid Oxygen (LO2)/Liquid Methane (LCH4) as a potential propellant combination for future space vehicles based upon the Exploration Systems Architecture Study (ESAS). The technology is estimated to have higher performance and lower overall systems mass compared to existing hypergolic propulsion systems. The current application considering this technology is the lunar ascent main engine (AME). AME is anticipated to be an expendable, pressure-fed engine to provide ascent from the moon at the completion of a 210 day lunar stay. The engine is expected to produce 5,500 lbf (24,465 N) thrust with variable inlet temperatures due to the cryogenic nature of the fuel and oxidizer. The primary technology risks include establishing reliable and robust ignition in vacuum conditions, maximizing specific impulse, developing rapid start capability for the descent abort, providing the capability for two starts and producing a total engine bum time over 500 seconds. This paper will highlight the efforts of the Marshall Space Flight Center (MSFC) in addressing risk reduction activities for this technology.

Robinson, Joel W.↗

Structural analysis

Hot section components of aircraft gas turbine engines are subjected to severe thermal-structural loading conditions, especially during the start-up and take-off portions of the engine cycle. The most severe and damaging stresses and strains are those induced by the steep thermal gradients induced during the start-up transient. These transient stresses and strains are also the most difficult to predict, in part because the temperature gradients and distributions are not well known or predictable, and also because the cyclic elasto-viscoplastic behavior of the materials at these extremes of temperature and strain are not well known or predictable. One element of the structures program will develop improved time-varying thermal-mechanical load models for the entire engine mission cycle from start-up to shutdown. The thermal model refinements will be consistent with those required by the structural code including considerations of mesh-point density, strain concentrations, and thermal gradients. Models will be developed for the burner liner, turbine vane and turbine blade.

Johns, R. H.↗

Breadboard RL10-11B low thrust operating mode

Cryogenic space engines require a cooling process to condition engine hardware to operating temperature before start. This can be accomplished most efficiently by burning propellants that would otherwise be dumped overboard after cooling the engine. The resultant low thrust operating modes are called Tank Head Idle and Pumped Idle. During February 1984, Pratt & Whitney conducted a series of tests demonstrating operation of the RL10 rocket engines at low thrust levels using a previously untried hydrogen/oxygen heat exchanger. The initial testing of the RL10-11B Breadboard Low Thrust Engine is described. The testing demonstrated operation at both tank head idle and pumped idle modes.

Kmiec, Thomas D.↗

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

Design study of RL10 derivatives. Volume 3, part 2: Operational and flight support plan

Transportation requirements are considered during the engine design layout reviews and maintenance engineering analyses. Where designs cannot be influenced to avoid transportation problems, the transportation representative is advised of the problems permitting remedies early in the program. The transportation representative will monitor and be involved in the shipment of development engine and GSE hardware between FRDC and vehicle manufacturing plant and thereby will be provided an early evaluation of the transportation plans, methods and procedures to be used in the space tug support program. Unanticipated problems discovered in the shipment of development hardware will be known early enough to permit changes in packaging designs and transportation plans before the start of production hardware and engine shipments. All conventional transport media can be used for the movement of space tug engines. However, truck transport is recommended for ready availability, variety of routes, short transit time, and low cost.

Shubert, W. C.↗

Rotary engine performance computer program (RCEMAP and RCEMAPPC): User's guide

This report is a user's guide for a computer code that simulates the performance of several rotary combustion engine configurations. It is intended to assist prospective users in getting started with RCEMAP and/or RCEMAPPC. RCEMAP (Rotary Combustion Engine performance MAP generating code) is the mainframe version, while RCEMAPPC is a simplified subset designed for the personal computer, or PC, environment. Both versions are based on an open, zero-dimensional combustion system model for the prediction of instantaneous pressures, temperature, chemical composition and other in-chamber thermodynamic properties. Both versions predict overall engine performance and thermal characteristics, including bmep, bsfc, exhaust gas temperature, average material temperatures, and turbocharger operating conditions. Required inputs include engine geometry, materials, constants for use in the combustion heat release model, and turbomachinery maps. Illustrative examples and sample input files for both versions are included.

Bartrand, Timothy A.↗

Intelligent Engine Systems Work Element 1.3: Sub System Health Management

The objectives of this program were to develop health monitoring systems and physics-based fault detection models for engine sub-systems including the start, lubrication, and fuel. These models will ultimately be used to provide more effective sub-system fault identification and isolation to reduce engine maintenance costs and engine down-time. Additionally, the bearing sub-system health is addressed in this program through identification of sensing requirements, a review of available technologies and a demonstration of a demonstration of a conceptual monitoring system for a differential roller bearing. This report is divided into four sections; one for each of the subtasks. The start system subtask is documented in section 2.0, the oil system is covered in section 3.0, bearing in section 4.0, and the fuel system is presented in section 5.0.

Ashby, Malcolm↗

High-Flux, High Performance H2O2 Catalyst Bed for ISTAR

On NASA's ISTAR RBCC program packaging and performance requirements exceeded traditional H2O2 catalyst bed capabilities. Aerojet refined a high performance, monolithic 90% H202 catalyst bed previously developed and demonstrated. This approach to catalyst bed design and fabrication was an enabling technology to the ISTAR tri-fluid engine. The catalyst bed demonstrated 55 starts at throughputs greater than 0.60 lbm/s/sq in for a duration of over 900 seconds in a physical envelope approximately 114 of traditional designs. The catalyst bed uses photoetched plates of metal bonded into a single piece monolithic structure. The precise control of the geometry and complete mixing results in repeatable, quick starting, high performing catalyst bed. Three different beds were designed and tested, with the best performing bed used for tri-fluid engine testing.

Ponzo, J.↗