SEARCH · Search NASA
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.
Saturn I /SA-8/ launch vehicle and launch complex systems - H- 1 rocket engine, and hydraulic systems
The United States' National Aeronautics and Space Administration (NASA) has established a strategic plan for future activities in space. A primary goal of this plan is to make drastic improvements in the cost and safety of earth to low-earth-orbit transportation. One approach to achieving this goal is through the development of highly reusable, highly reliable space transportation systems analogous to the commercial airline system. In the year 2000, NASA selected the Rocket Based Combined Cycle (RBCC) engine as the next logical step towards this goal. NASA will develop a complete flight-weight, pump-fed engine system under the Integrated System Test of an Airbreathing Rocket (I(sup STAR)) Project. The objective of this project is develop a reusable engine capable of self-powering a vehicle through the air-augmented rocket, ramjet and scramjet modes required in all RBCC based operational vehicle concepts. The project is currently approved and funded to develop the engine through ground test demonstration. Plans are in place to proceed with flight demonstration pending funding approval. The project is in formulation phase and the Preliminary Requirements Review has been completed. The engine system and vehicle have been selected at the conceptual level. The I(sup STAR) engine concept is based on an air-breathing flowpath downselected from three configurations evaluated in NASA's Advanced Reusable Technology contract. The selected flowpath features rocket thrust chambers integrated into struts separating modular flowpath ducts, a variable geometry inlet, and a thermally choked throat. The engine will be approximately 220 inches long and 79 inches wide and fueled with a hydrocarbon fuel using liquid oxygen as the primary oxidizer candidate. The primary concept for the pump turbine drive is pressure-fed catalyzed hydrogen peroxide. In order to control costs, the flight demonstration vehicle will be launched from a B-52 aircraft. The vehicle concept is based on the Air Breathing Launch Vehicle 4 (ABLV4) lifting body configuration which has design heritage from NASA's NASP Program. The vehicle will be designed to accelerate from Mach 0.8 to Mach 7 and will be equipped with landing gear for horizontal landing. The complete vehicle, including the engine, will be designed for 25 flights and will be approximately 33 feet long with a total vehicle weight of approximately 25000 lbs.
The systems engineering process for the concept definition phase of the program involves requirements definition, system definition, and consistent concept definition. The requirements definition process involves obtaining a complete understanding of the system requirements based on customer needs, mission scenarios, and nuclear thermal propulsion (NTP) operating characteristics. A system functional analysis is performed to provide a comprehensive traceability and verification of top-level requirements down to detailed system specifications and provides significant insight into the measures of system effectiveness to be utilized in system evaluation. The second key element in the process is the definition of system concepts to meet the requirements. This part of the process involves engine system and reactor contractor teams to develop alternative NTP system concepts that can be evaluated against specific attributes, as well as a reference configuration against which to compare system benefits and merits. Quality function deployment (QFD), as an excellent tool within Total Quality Management (TQM) techniques, can provide the required structure and provide a link to the voice of the customer in establishing critical system qualities and their relationships. The third element of the process is the consistent performance comparison. The comparison process involves validating developed concept data and quantifying system merits through analysis, computer modeling, simulation, and rapid prototyping of the proposed high risk NTP subsystems. The maximum amount possible of quantitative data will be developed and/or validated to be utilized in the QFD evaluation matrix. If upon evaluation of a new concept or its associated subsystems determine to have substantial merit, those features will be incorporated into the reference configuration for subsequent system definition and comparison efforts.
The Highly Integrated Digital Electronic Control (HIDEC) program will demonstrate and evaluate the improvements in performance and mission effectiveness that result from integrated engine/airframe control systems. This system is being used on the F-15 airplane. An integrated flightpath management mode and an integrated adaptive engine stall margin mode are implemented into the system. The adaptive stall margin mode is a highly integrated mode in which the airplane flight conditions, the resulting inlet distortion, and the engine stall margin are continuously computed; the excess stall margin is used to uptrim the engine for more thrust. The integrated flightpath management mode optimizes the flightpath and throttle setting to reach a desired flight condition. The increase in thrust and the improvement in airplane performance is discussed.
For heavy-duty diesel engines, NO X emissions reduction is strongly constrained by fuel efficiency. This paper presents a hierarchical model predictive controller (H-MPC) for coordinated control of tailpipe NO X emissions and fuel consumption. The H-MPC uses the separation of slow and fast dynamics that exist in the engine and its aftertreatment system. The controller is synthesized with an architecture in which a high-level MPC uses a longer prediction horizon compared to the low-level predictive controller which tracks the high-level controller command and manages the thermal dynamics of the aftertreatment system. Engine load preview enables the high-level controller to estimate the desired catalyst temperature ahead of time and addresses the selective catalytic reduction (SCR) slow thermal dynamics. Calculated by the high-level controller, the intake manifold pressure, and the start of injection (SOI) crank angle is used as reference trajectories in the low-level controller that regulates fast dynamical behaviors such as engine out NO X emissions. Hardware-in-the-loop (HIL) validation of this integrated H-MPC on a rapid prototype controller shows that when the SCR catalyst temperature is above light-off temperature (warmed-up condition), the engine operation is shifted to operate with the best fuel economy since the warmed-up SCR can efficiently reduce the engine-out NO X emissions. Results indicate that up to 0.8% benefit in cycle averaged BSFC along with a 13% reduction in tailpipe NO X compared to a stock engine calibration can be achieved with the coordinated engine and aftertreatment system through H-MPC.
Software Quality Assurance (SQA) is an important component of the software development process. SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. Typical techniques include: (1) Testing (2) Simulation (3) Model checking (4) Symbolic execution (5) Management reviews (6) Technical reviews (7) Inspections (8) Walk-throughs (9) Audits (10) Analysis (complexity analysis, control flow analysis, algorithmic analysis) (11) Formal method Our work over the last few years has resulted in substantial knowledge about SQA techniques, especially the areas of technical reviews and inspections. But can we apply the same QA techniques to the system development process? If yes, what kind of tailoring do we need before applying them in the system engineering context? If not, what types of QA techniques are actually used at system level? And, is there any room for improvement.) After a brief examination of the system engineering literature (especially focused on NASA and DoD guidance) we found that: (1) System and software development process interact with each other at different phases through development life cycle (2) Reviews are emphasized in both system and software development. (Figl.3). For some reviews (e.g. SRR, PDR, CDR), there are both system versions and software versions. (3) Analysis techniques are emphasized (e.g. Fault Tree Analysis, Preliminary Hazard Analysis) and some details are given about how to apply them. (4) Reviews are expected to use the outputs of the analysis techniques. In other words, these particular analyses are usually conducted in preparation for (before) reviews. The goal of our work is to explore the interaction between the Quality Assurance (QA) techniques at the system level and the software level.
Automatic control systems for electron bombardment and contact ion engines
This paper summarizes a subset of the Advanced Modeling Simulation and Analysis (AMSA) Capability Roadmap that was developed for NASA in 2005. The AMSA Capability Roadmap Team was chartered to "To identify what is needed to enhance NASA's capabilities to produce leading-edge exploration and science missions by improving engineering system development, operations, and science understanding through broad application of advanced modeling, simulation and analysis techniques." The AMSA roadmap stressed the need for integration, not just within the science, engineering and operations domains themselves, but also across these domains. Here we discuss the roadmap element pertaining to integration within the engineering domain, with a particular focus on implications for future observatory missions. The AMSA products supporting the system engineering function are mission information, bounds on information quality, and system validation guidance. The Engineering roadmap element contains 5 sub-elements: (1) Large-Scale Systems Models, (2) Anomalous Behavior Models, (3) advanced Uncertainty Models, (4) Virtual Testing Models, and (5) space-based Robotics Manufacture and Servicing Models.
While the causes of failures in complex engineered systems are often clear in hindsight, it can be challenging to predict failures proactively during the design of novel engineered products or systems. Identifying patterns can be useful for capturing common characteristics that may lead to failure. In this paper, we present a methodology for identifying patterns of failure from NASA’s publicly available Lessons Learned Information System (LLIS). We apply an ontology development and clustering approach to identify representative patterns leading to failures in historical lessons learned. A joint inductive-deductive approach reveals the key themes in lessons that lead to failure, which are formalized and recorded as an ontology of complex systems failure causes. Documents from the LLIS are manually tagged with relevant characteristics from the ontology. From the tagged set, clustering is used to capture co-occurring sets of characteristics that lead to failure. The primary contribution of this work is a method for extracting a set of generic failure patterns in complex engineered systems and characteristics for these patterns that can be identified at design time, knowledge of which can be used to plan mitigation strategies.
The Molten Chloride Reactor Experiment (MCRE) will be the first reactor featuring a fast-spectrum molten chloride circulating nuclear fuel system in the world. Planning for equipment removal and disposal (ERD) of MCRE has identified several technology gaps due to the unique environment of this nuclear experiment. Some of the gaps arise from the application of existing disassembly and/or sizing methods to novel material forms or in novel configurations. Others arise from unknown material behavior. This paper summarizes proposed test plans for ERD validation experiments to address these complicated or unknown equipment removal procedures. At the Waste Management Symposia in 2024, the Idaho National Laboratory (INL) MCRE ERD team presented the challenges associated with hosting multiple nuclear experiments in series with only brief transition periods between systems. Such difficulties include higher dose rates, the presence of radioisotopes infrequently encountered in reactor decommissioning and radioactive waste management, lack of intrinsic remote-operations infrastructure in the test bed, space constraints in the test bed, and contamination minimization requirements. To address these challenges, remote or semi-remote technologies are planned to be implemented in a non-hot cell environment with limited space availability. The team also discussed how a systems engineering approach is being used for conceptual development and design of equipment removal systems to address these challenges. For example, to reduce constraints for the removal of more difficult components, non-activated, noncontaminated elements are planned to be taken out first where possible. Still, there are complexities associated with the remaining components. In this work, the operational framework for MCRE ERD was reviewed for technical gaps and open questions, and test plans were drafted to address these areas. The tests plans were written for the following categories: vision systems, pipe cutting, drill/grout/filler, flush salt, and miscellaneous, with the miscellaneous group consisting of tests like techniques for removing bearings and reflector bricks. The test plans explore material, infrastructure, and staffing requirements needed for test execution. The test plans additionally focus on the evaluation of success. Determining the outcome of a test is imperative - as these explorative actions have the potential to rearrange or re-scope planned ERD activities. Success criteria identified thus far include required tool output, required area(s), debris production and mitigation, and repeatability. Test plans are an essential aspect of the systems engineering approach to MCRE ERD. They are used as the beginning steps in defining use cases for the ERD system. Performance of the validation tests is expected to begin in the summer of 2025 and will take approximately 9 to 12 months to complete. Execution of these plans will be expedited by specifying test needs ahead of time, facilitating efficient interactions with any subcontractors tasked with running the requested tests. Evaluating the outcomes of these tests will inform MCRE ERD procedures and timing and will also identify additional technical constraints for the MCRE ERD System. This upfront process optimization effort will help the project save time and resources at the end of the experiment.
An algorithm is derived for the real-time calibration of the engine mixture ratio during SSME ground testing. Because currently used calibration methods are post-test operations, there exists no fail-safe way of predicting at what mixture ratio a planned test will run. It is proposed that the algorithm developed here be used as part of an AECS which could ensure that nearly all SSME tests are run at the proper mixture ratio. In this way, AECS has the potential of increasing the efficiency of the SSME ground test program. This algorithm is an alternative to that presented in a previous paper. In addition to the derivation of the algorithm, an overview of this calibration system is presented along with a discussion of a possible single coefficient calibration system and the list of test stand facility instrumentation necessary for AECS implementation.
VITROCISET has in house developed a prototype tool named System Dynamic Analysis Environment (SDAE) to support system engineering activities in the initial definition phase of a complex space system. The SDAE goal is to provide powerful means for the definition, analysis, and trade-off of operations and design concepts for the space and ground elements involved in a mission. For this purpose SDAE implements a dedicated modeling methodology based on the integration of different modern (static and dynamic) analysis and simulation techniques. The resulting 'system model' is capable of representing all the operational, functional, and behavioral aspects of the system elements which are part of a mission. The execution of customized model simulations enables: the validation of selected concepts with respect to mission requirements; the in-depth investigation of mission specific operational and/or architectural aspects; and the early assessment of performances required by the system elements to cope with mission constraints and objectives. Due to its characteristics, SDAE is particularly tailored for nonconventional or highly complex systems, which require a great analysis effort in their early definition stages. SDAE runs under PC-Windows and is currently used by VITROCISET system engineering group. This paper describes the SDAE main features, showing some tool output examples.
A 150 lb f thrust class, modular, bi-propellant, rocket engine/gas-generator and supporting test infrastructure has been developed in a cooperative effort between Sandia National Laboratories and the New Mexico Institute of Mining and Technology’s (NMIMT’s) Energetic Materials Research and Testing Center (EMRTC). This modular test engine design consists of a head end fuel-oxidizer injector, a spark ignition gaseous H 2 /O 2 torch igniter, combustion chamber and nozzle module. This robust design allows for rapid configuration changes as well as economical repair should hardware become damaged in testing. The engine interfaces with a permanently installed pressurizing system capable of delivering liquid nitrous oxide and a variety of liquid fuels for both rocket engine development and propellant performance evaluation. The regulated high pressure systems allow for delivery of liquefied gases above their saturation pressure as well as allowing for high pressure rocket engine/gas-generator operation. The facility test cell houses a 1 ton thrust capacity test stand leaving room for larger scale engine development.
During the last year, significant progress was made toward the development of the Space Shuttle Main Engine, which will provide propulsion for the Space Shuttle Orbiter vehicle. Engine system testing continued at the National Space Technology Laboratories on both single engines and a three-engine cluster. A third single engine test position was activated at the Rocketdyne Santa Susana Field Laboratory to provide additional capability for demonstrating increasing engine maturity and for solving problems. The results of engine system testing is discussed as well as the major problems identified and the design changes incorporated to solve those problems. A review of the program efforts toward the delivery of the first set of flight engines and the certification of the SSME for manned flight is included.
A major open question for advocates of Model-Based Systems Engineering (MBSE) is the question of how system and subsystem engineers will work together. The Systems Modeling Language (SysML), like any language intended for a large audience, is in tension between the desires for simplicity and for expressiveness. In order to be more expressive, many specialized language elements may be introduced, which will unfortunately make a complete understanding of the language a more daunting task. While this may be acceptable for systems modelers, it will increase the challenge of including subsystem engineers in the modeling effort. One possible answer to this situation is the use of Domain-Specific Languages (DSL), which are fully supported by the Unified Modeling Language (UML). SysML is in fact a DSL for systems engineering. The expressive power of a DSL can be enhanced through the use of diagram customization. Various domains have already developed their own schematic vocabularies. Within the space engineering community, two excellent examples are the propulsion and telecommunication subsystems. A return to simple box-and-line diagrams (e.g., the SysML Internal Block Diagram) are in many ways a step backward. In order allow subsystem engineers to contribute directly to the model, it is necessary to make a system modeling tool at least approximate in accessibility to drawing tools like Microsoft PowerPoint and Visio. The challenge is made more extreme in a concurrent engineering environment, where designs must often be drafted in an hour or two. In the case of the Jet Propulsion Laboratory's Team X concurrent design team, a subsystem is specified using a combination of PowerPoint for drawing and Excel for calculation. A pilot has been undertaken in order to meld the drawing portion and the production of master equipment lists (MELs) via a SysML authoring tool, MagicDraw. Team X currently interacts with its customers in a process of sharing presentations. There are several inefficiencies that arise from this situation. The first is that a customer team must wait two weeks to a month (which is 2-4 times the duration of most Team X studies themselves) for a finalized, detailed design description. Another is that this information must be re-entered by hand into the set of engineering artifacts and design tools that the mission concept team uses after a study is complete. Further, there is no persistent connection to Team X or institutionally shared formulation design tools and data after a given study, again reducing the direct reuse of designs created in a Team X study. This paper presents the underpinnings of subsystem DSLs as they were developed for this pilot. This includes specialized semantics for different domains as well as the process by which major categories of objects were derived in support of defining the DSLs. The feedback given to us by the domain experts on usability, along with a pilot study with the partial inclusion of these tools is also discussed.
The development of a modular solar thermal power system for application in the 1 to 10 MWe range is presented. The system is used in remote utility applications, small communities, rural areas, and for industrial uses. Investigations are performed on the energy storage requirements and type of energy storage, concentrator design and field optimization, energy transport, and power conversion subsystems. The system utilizes a Rankine cycle, an axial flow steam turbine for power conversion, and heat transfer sodium for collector fluid.
The pressure recovery of incoming cooling air and the drag associated with engine cooling of a typical general aviation twin-engine aircraft was Investigated experimentally. The semispan model was mounted vertically in the 40 x 80-Foot Wind Tunnel at Ames Research Center. The propeller was driven by an electric motor to provide thrust with low vibration levels for the cold-now configuration. It was found that the propeller slip-stream reduces the frontal air spillage around the blunt nacelle shape. Consequently, this slip-stream effect promotes flow reattachment at the rear section of the engine nacelle and improves inlet pressure recovery. These effects are most pronounced at high angles of attack; that is, climb condition. For the cruise condition those improvements were more moderate.
The General MACOS Interface (GMI) for Modeling and Analysis for Controlled Optical Systems (MACOS) enables the use of MATLAB as a front-end for JPL s critical optical modeling package, MACOS. MACOS is JPL s in-house optical modeling software, which has proven to be a superb tool for advanced systems engineering of optical systems. GMI, coupled with MACOS, allows for seamless interfacing with modeling tools from other disciplines to make possible integration of dynamics, structures, and thermal models with the addition of control systems for deformable optics and other actuated optics. This software package is designed as a tool for analysts to quickly and easily use MACOS without needing to be an expert at programming MACOS. The strength of MACOS is its ability to interface with various modeling/development platforms, allowing evaluation of system performance with thermal, mechanical, and optical modeling parameter variations. GMI provides an improved means for accessing selected key MACOS functionalities. The main objective of GMI is to marry the vast mathematical and graphical capabilities of MATLAB with the powerful optical analysis engine of MACOS, thereby providing a useful tool to anyone who can program in MATLAB. GMI also improves modeling efficiency by eliminating the need to write an interface function for each task/project, reducing error sources, speeding up user/modeling tasks, and making MACOS well suited for fast prototyping.