Search NASA⌕ Search

SEARCH · Search NASA

Results for “plug”

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 343 records · Page 19

Friction Plug Weld Repair for the Space Shuttle External Tank

Lockheed Martin Space Systems, Michoud Operations in New Orleans, LA is the manufacturer of the External Fuel Tanks (ET) for the Space Transportation System (STS). The ET contains and delivers the propellants used by the Orbiters three main engines. Additionally, it also serves as the structural backbone for the Orbiter and the two Solid Rocket Boosters (SRB), which combined, constitute the STS. In 1994, NASA established that in order to launch the International Space Station, the performance of the STS must be improved. One option was to reduce the weight of the ET, which would enable sufficient increase in performance. With the development of the Weldalite(R) series of Al-Cu-Li alloys in the late 1980's, Lockheed Martin was postured to replace the current A12219 fuel tanks with the high strength, light weight A12195 alloy. With the use of A12195 and some component redesign, the weight of the Super Lightweight (SLWT) ET was reduced by approximately 7,000 pounds, which added as much capability to the Space Shuttle. Since June 1998, seven STS missions have been successful with the use of the SLWT ET's.

Hartley, Paula J.↗

A Core Plug and Play Architecture for Reusable Flight Software Systems

The Flight Software Branch, at Goddard Space Flight Center (GSFC), has been working on a run-time approach to facilitate a formal software reuse process. The reuse process is designed to enable rapid development and integration of high-quality software systems and to more accurately predict development costs and schedule. Previous reuse practices have been somewhat successful when the same teams are moved from project to project. But this typically requires taking the software system in an all-or-nothing approach where useful components cannot be easily extracted from the whole. As a result, the system is less flexible and scalable with limited applicability to new projects. This paper will focus on the rationale behind, and implementation of the run-time executive. This executive is the core for the component-based flight software commonality and reuse process adopted at Goddard.

Wilmot, Jonathan↗

Flying the ST-5 Constellation with "Plug and Play" Autonomy Components and the GMSEC Bus

The Space Technology 5 (ST5) Project, part of NASA's New Millennium Program, will consist of a constellation of three micro-satellites. This viewgraph document presents the components that will allow it to operate in an autonomous mode. The ST-5 constellation will use the GSFC Mission Services Evolution Center (GMSEC) architecture to enable cost effective model based operations. The ST-5 mission will demonstrate several principles of self managing software components.

Shendock, Bob↗

Tapered plug foam spray apparatus

A two-component foam spray gun is readily disassembled for cleaning. It includes a body (1) with reactant (12, 14) and purge gas (16) inlet ports. A moldable valve packing (32) inside the body has a tapered conical interior surface (142), and apertures which match the reactant ports. A valve/tip (40) has a conical outer surface (48) which mates with the valve packing (32). The valve/tip (40) is held in place by a moldable packing washer (34), held at non-constant pressure by a screw (36, 38). The interior of the valve/tip (40) houses a removable mixing chamber (50). The mixing chamber (50) has direct flow orifices (60) and an auxiliary flow path (58, 60) which ameliorate pressure surges. The spray gun can be disassembled for cleaning without disturbing the seal, by removing the valve/tip (40) to the rear, thereby breaking it free of the conical packing. Rotation of the valve/tip (40) relative to the body (1) shuts off the reactant flow, and starts the purge gas flow.

Allen, Peter B.↗

Aquarius' Object-Oriented, Plug and Play Component-Based Flight Software

The Aquarius mission involves a combined radiometer and radar instrument in low-Earth orbit, providing monthly global maps of Sea Surface Salinity. Operating successfully in orbit since June, 2011, the spacecraft bus was furnished by the Argentine space agency, Comision Nacional de Actividades Espaciales (CONAE). The instrument, built jointly by NASA's Caltech/JPL and Goddard Space Flight Center, has been successfully producing expectation-exceeding data since it was powered on in August of 2011. In addition to the radiometer and scatterometer, the instrument contains an command & data-handling subsystem with a computer and flight software (FSW) that is responsible for managing the instrument, its operation, and its data. Aquarius' FSW is conceived and architected as a Component-based system, in which the running software consists of a set of Components, each playing a distinctive role in the subsystem, instantiated and connected together at runtime. Component architectures feature a well-defined set of interfaces between the Components, visible and analyzable at the architectural level (see [1]). As we will describe, this kind of an architecture offers significant advantages over more traditional FSW architectures, which often feature a monolithic runtime structure. Component-based software is enabled by Object-Oriented (OO) techniques and languages, the use of which again is not typical in space mission FSW. We will argue in this paper that the use of OO design methods and tools (especially the Unified Modeling Language), as well as the judicious usage of C++, are very well suited to FSW applications, and we will present Aquarius FSW, describing our methods, processes, and design, as a successful case in point.

Component Architecture↗

A Synthesis Plug-in for Steady and Unsteady Loading and Thickness Noise Auralization

This paper describes the development and architecture of a plugin for the NASA Auralization Framework that synthesizes rotor sound pressures sample by sample for simulated propagation to auralize rotorcraft flyovers. The main component of the plugin is a preprocessor that synthesizes sound pressures before propagation methods are called. Rotor blade loadings, motion, and geometry data from various tools serve as input to the plugin. Farassat formulation 1A, a solution to the Ffowcs Williams-Hawkings equation, is used for the sound pressure calculations. Use of the plugin is demonstrated with two examples of steady periodic sound synthesis, but the synthesis method and preprocessor architecture described in this paper are also applicable to unsteady periodic and aperiodic sound syntheses.

Siddhartha Krishnamurthy↗

NE-COST plug-in: Expanding ACCERT's Capabilities for Life-Cycle Cost Modeling

The Algorithm for the Capital Cost Estimation of Reactor Technologies (ACCERT) is a structured methodology and software tool designed to simplify and standardize cost estimation for nuclear reactor technologies [1]. By utilizing a relational database structure and modular cost estimation algorithms, ACCERT delivers a robust, flexible, and scalable framework for evaluating costs across various reactor types and configurations [2]. The recent integration of the NE-COST plugin further expands ACCERT’s scope by introducing detailed life-cycle cost modeling and probabilistic analysis of uncertainties. This addition enables users to evaluate costs across front-end processes such as uranium enrichment and fabrication, as well as back-end activities including waste disposal and geologic storage. Through Monte Carlo statistical cost simulations, the plugin provides probabilistic insights into cost ranges, offering critical decision-making support for stakeholders including reactor developers, policymakers, and researchers.

Zhou, Jia↗

Assessing the Impact of Large Removable Beryllium Reflector Experiments on HFIR Performance and Safety Metrics

This study investigated the effect of various removable beryllium (RB) experiment configurations on High Flux Isotope Reactor (HFIR) metrics to address increasing interest in these facilities for materials and fuels irradiation research. The RB reflector contains eight large and four small irradiation experiment facilities that offer excellent neutron flux conditions to perform fission and fusion reactor materials and fuels irradiation research. This work aims to outline acceptable RB configurations based on safety, performance, and programmatic metrics. This study assessed experiment effects on reactivity, cycle length, fission rate density distributions, and neutron flux distributions using the Shift, HFIRCON, and SCALE ORIGEN codes. Initial evaluations focused on generic experiment materials including aluminum plugs, stainless steel plugs, molybdenum plugs, and aluminum plugs with gadolinium shields. Subsequent analyses of MiniFuel experiments were performed to evaluate a heterogenous experiment, consisting of a more complex geometry and bearing several materials, and to test the correlations developed with the generic materials on a real experiment. Furthermore, the effects of neutron poison concentrations in the standard beryllium plugs were evaluated. When assuming a reference RB configuration with eight large fresh beryllium plugs, perturbed configurations with three aluminum plugs, one stainless steel plug, one molybdenum plug, one gadolinium-shielded aluminum plug, and one MiniFuel experiment resulted in a cycle length reduction of less than 1.3 days, the current threshold before requiring additional approvals. Configurations with five aluminum plugs, one stainless steel plug, one molybdenum plug, one gadolinium-shielded aluminum plug, and two MiniFuel experiments meet the 1.3 day limit if irradiated beryllium plugs are considered. Fuel element fission rate density distributions remained within safety limits, with maximum local increases under 9%. Neutron flux calculations revealed large thermal flux depressions inside and around the perturbed RB facilities, while epithermal and fast neutron fluxes increased because of reduced neutron moderation by the perturbed materials. These findings provide valuable guidance for optimizing RB configurations to balance safety and performance at HFIR.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

Parallel Eclipse Project Checkout

Parallel Eclipse Project Checkout (PEPC) is a program written to leverage parallelism and to automate the checkout process of plug-ins created in Eclipse RCP (Rich Client Platform). Eclipse plug-ins can be aggregated in a feature project. This innovation digests a feature description (xml file) and automatically checks out all of the plug-ins listed in the feature. This resolves the issue of manually checking out each plug-in required to work on the project. To minimize the amount of time necessary to checkout the plug-ins, this program makes the plug-in checkouts parallel. After parsing the feature, a request to checkout for each plug-in in the feature has been inserted. These requests are handled by a thread pool with a configurable number of threads. By checking out the plug-ins in parallel, the checkout process is streamlined before getting started on the project. For instance, projects that took 30 minutes to checkout now take less than 5 minutes. The effect is especially clear on a Mac, which has a network monitor displaying the bandwidth use. When running the client from a developer s home, the checkout process now saturates the bandwidth in order to get all the plug-ins checked out as fast as possible. For comparison, a checkout process that ranged from 8-200 Kbps from a developer s home is now able to saturate a pipe of 1.3 Mbps, resulting in significantly faster checkouts. Eclipse IDE (integrated development environment) tries to build a project as soon as it is downloaded. As part of another optimization, this innovation programmatically tells Eclipse to stop building while checkouts are happening, which dramatically reduces lock contention and enables plug-ins to continue downloading until all of them finish. Furthermore, the software re-enables automatic building, and forces Eclipse to do a clean build once it finishes checking out all of the plug-ins. This software is fully generic and does not contain any NASA-specific code. It can be applied to any Eclipse-based repository with a similar structure. It also can apply build parameters and preferences automatically at the end of the checkout.

Crockett, Thomas M.↗