Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “interface 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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

Electro-optic architecture (EOA) for sensors and actuators in aircraft propulsion systems

Results of a study to design an optimal architecture for electro-optical sensing and control in advanced aircraft and space systems are described. The propulsion full authority digital Electronic Engine Control (EEC) was the focus for the study. The recommended architecture is an on-engine EEC which contains electro-optic interface circuits for fiber-optic sensors on the engine. Size and weight are reduced by multiplexing arrays of functionally similar sensors on a pair of optical fibers to common electro-optical interfaces. The architecture contains common, multiplex interfaces to seven sensor groups: (1) self luminous sensors; (2) high temperatures; (3) low temperatures; (4) speeds and flows; (5) vibration; (6) pressures; and (7) mechanical positions. Nine distinct fiber-optic sensor types were found to provide these sensing functions: (1) continuous wave (CW) intensity modulators; (2) time division multiplexing (TDM) digital optic codeplates; (3) time division multiplexing (TDM) analog self-referenced sensors; (4) wavelength division multiplexing (WDM) digital optic code plates; (5) wavelength division multiplexing (WDM) analog self-referenced intensity modulators; (6) analog optical spectral shifters; (7) self-luminous bodies; (8) coherent optical interferometers; and (9) remote electrical sensors. The report includes the results of a trade study including engine sensor requirements, environment, the basic sensor types, and relevant evaluation criteria. These figures of merit for the candidate interface types were calculated from the data supplied by leading manufacturers of fiber-optic sensors.

Glomb, W. L., Jr.↗
NASA NTRS2006

Stochastic Simulation Tool for Aerospace Structural Analysis

Stochastic simulation refers to incorporating the effects of design tolerances and uncertainties into the design analysis model and then determining their influence on the design. A high-level evaluation of one such stochastic simulation tool, the MSC.Robust Design tool by MSC.Software Corporation, has been conducted. This stochastic simulation tool provides structural analysts with a tool to interrogate their structural design based on their mathematical description of the design problem using finite element analysis methods. This tool leverages the analyst's prior investment in finite element model development of a particular design. The original finite element model is treated as the baseline structural analysis model for the stochastic simulations that are to be performed. A Monte Carlo approach is used by MSC.Robust Design to determine the effects of scatter in design input variables on response output parameters. The tool was not designed to provide a probabilistic assessment, but to assist engineers in understanding cause and effect. It is driven by a graphical-user interface and retains the engineer-in-the-loop strategy for design evaluation and improvement. The application problem for the evaluation is chosen to be a two-dimensional shell finite element model of a Space Shuttle wing leading-edge panel under re-entry aerodynamic loading. MSC.Robust Design adds value to the analysis effort by rapidly being able to identify design input variables whose variability causes the most influence in response output parameters.

Knight, Norman F.↗
NASA NTRS2012

Flow Analysis Tool White Paper

Faster networks are continually being built to accommodate larger data transfers. While it is intuitive to think that implementing faster networks will result in higher throughput rates, this is often not the case. There are many elements involved in data transfer, many of which are beyond the scope of the network itself. Although networks may get bigger and support faster technologies, the presence of other legacy components, such as older application software or kernel parameters, can often cause bottlenecks. Engineers must be able to identify when data flows are reaching a bottleneck that is not imposed by the network and then troubleshoot it using the tools available to them. The current best practice is to collect as much information as possible on the network traffic flows so that analysis is quick and easy. Unfortunately, no single method of collecting this information can sufficiently capture the whole endto- end picture. This becomes even more of a hurdle when large, multi-user systems are involved. In order to capture all the necessary information, multiple data sources are required. This paper presents a method for developing a flow analysis tool to effectively collect network flow data from multiple sources and provide that information to engineers in a clear, concise way for analysis. The purpose of this method is to collect enough information to quickly (and automatically) identify poorly performing flows along with the cause of the problem. The method involves the development of a set of database tables that can be populated with flow data from multiple sources, along with an easyto- use, web-based front-end interface to help network engineers access, organize, analyze, and manage all the information.

Boscia, Nichole K.↗
NASA NTRS1993

An integrated knowledge system for wind tunnel testing - Project Engineers' Intelligent Assistant

The Project Engineers' Intelligent Assistant (PEIA) is an integrated knowledge system developed using artificial intelligence technology, including hypertext, expert systems, and dynamic user interfaces. This system integrates documents, engineering codes, databases, and knowledge from domain experts into an enriched hypermedia environment and was designed to assist project engineers in planning and conducting wind tunnel tests. PEIA is a modular system which consists of an intelligent user-interface, seven modules and an integrated tool facility. Hypermedia technology is discussed and the seven PEIA modules are described. System maintenance and updating is very easy due to the modular structure and the integrated tool facility provides user access to commercial software shells for documentation, reporting, or database updating. PEIA is expected to provide project engineers with technical information, increase efficiency and productivity, and provide a realistic tool for personnel training.

Lo, Ching F.↗
NASA NTRS2016

Launch Vehicle Selection and the Implementation of the Soil Moisture Active Passive Mission

Soil Moisture Active Passive (SMAP) is a NASA-developed Earth science satellite currently mapping the soil moisture content and freeze/thaw state of Earth's land mass from a 685km, near-polar, sun-synchronous orbit. It was launched on January 31, 2015 from Vandenberg AFB upon a Delta II 7320 launch vehicle. Due to external considerations, SMAP's launch vehicle selection remained an open item until Project Critical Design Review (CDR). Thus, certain key aspects of the spacecraft design had to accommodate a diverse range of candidate launch vehicle environments, performance envelopes, interfaces and operational scenarios. Engineering challenges stemmed from two distinct scenarios: decisions that had to be made prior to launch vehicle selection to accommodate all possible outcomes, and post-selection changes constrained by schedule and the existing spacecraft configuration. The effects of the timing of launch vehicle selection reached virtually every aspect of the Observatory's design and development. Physical environments, mass allocations, material selections, propulsion system performance, dynamic response, launch phase and mission planning, overall size and configuration, and of course all interfaces to the launch vehicle were heavily dependent on this outcome. This paper will discuss the resolution of these technical challenges.

Sherman, Sarah↗
NASA NTRS1994

HiRel: Hybrid Automated Reliability Predictor (HARP) integrated reliability tool system, (version 7.0). Volume 3: HARP Graphics Oriented (GO) input user's guide

The Hybrid Automated Reliability Predictor (HARP) integrated Reliability (HiRel) tool system for reliability/availability prediction offers a toolbox of integrated reliability/availability programs that can be used to customize the user's application in a workstation or nonworkstation environment. HiRel consists of interactive graphical input/output programs and four reliability/availability modeling engines that provide analytical and simulative solutions to a wide host of highly reliable fault-tolerant system architectures and is also applicable to electronic systems in general. The tool system was designed at the outset to be compatible with most computing platforms and operating systems, and some programs have been beta tested within the aerospace community for over 8 years. This document is a user's guide for the HiRel graphical preprocessor Graphics Oriented (GO) program. GO is a graphical user interface for the HARP engine that enables the drawing of reliability/availability models on a monitor. A mouse is used to select fault tree gates or Markov graphical symbols from a menu for drawing.

Bavuso, Salvatore J.↗
NASA NTRS1983

Integrating computer programs for engineering analysis and design

The design of a third-generation system for integrating computer programs for engineering and design has been developed for the Aerospace Vehicle Interactive Design (AVID) system. This system consists of an engineering data management system, program interface software, a user interface, and a geometry system. A relational information system (ARIS) was developed specifically for the computer-aided engineering system. It is used for a repository of design data that are communicated between analysis programs, for a dictionary that describes these design data, for a directory that describes the analysis programs, and for other system functions. A method is described for interfacing independent analysis programs into a loosely-coupled design system. This method emphasizes an interactive extension of analysis techniques and manipulation of design data. Also, integrity mechanisms exist to maintain database correctness for multidisciplinary design tasks by an individual or a team of specialists. Finally, a prototype user interface program has been developed to aid in system utilization.

Wilhite, A. W.↗
NASA NTRS2012

The Namibia Early Flood Warning System, A CEOS Pilot Project

Over the past year few years, an international collaboration has developed a pilot project under the auspices of Committee on Earth Observation Satellite (CEOS) Disasters team. The overall team consists of civilian satellite agencies. For this pilot effort, the development team consists of NASA, Canadian Space Agency, Univ. of Maryland, Univ. of Colorado, Univ. of Oklahoma, Ukraine Space Research Institute and Joint Research Center(JRC) for European Commission. This development team collaborates with regional , national and international agencies to deliver end-to-end disaster coverage. In particular, the team in collaborating on this effort with the Namibia Department of Hydrology to begin in Namibia . However, the ultimate goal is to expand the functionality to provide early warning over the South Africa region. The initial collaboration was initiated by United Nations Office of Outer Space Affairs and CEOS Working Group for Information Systems and Services (WGISS). The initial driver was to demonstrate international interoperability using various space agency sensors and models along with regional in-situ ground sensors. In 2010, the team created a preliminary semi-manual system to demonstrate moving and combining key data streams and delivering the data to the Namibia Department of Hydrology during their flood season which typically is January through April. In this pilot, a variety of moderate resolution and high resolution satellite flood imagery was rapidly delivered and used in conjunction with flood predictive models in Namibia. This was collected in conjunction with ground measurements and was used to examine how to create a customized flood early warning system. During the first year, the team made use of SensorWeb technology to gather various sensor data which was used to monitor flood waves traveling down basins originating in Angola, but eventually flooding villages in Namibia. The team made use of standardized interfaces such as those articulated under the Open Cloud Consortium (OGC) Sensor Web Enablement (SWE) set of web services was good [1][2]. However, it was discovered that in order to make a system like this functional, there were many performance issues. Data sets were large and located in a variety of location behind firewalls and had to be accessed across open networks, so security was an issue. Furthermore, the network access acted as bottleneck to transfer map products to where they are needed. Finally, during disasters, many users and computer processes act in parallel and thus it was very easy to overload the single string of computers stitched together in a virtual system that was initially developed. To address some of these performance issues, the team partnered with the Open Cloud Consortium (OCC) who supplied a Computation Cloud located at the University of Illinois at Chicago and some manpower to administer this Cloud. The Flood SensorWeb [3] system was interfaced to the Cloud to provide a high performance user interface and product development engine. Figure 1 shows the functional diagram of the Flood SensorWeb. Figure 2 shows some of the functionality of the Computation Cloud that was integrated. A significant portion of the original system was ported to the Cloud and during the past year, technical issues were resolved which included web access to the Cloud, security over the open Internet, beginning experiments on how to handle surge capacity by using the virtual machines in the cloud in parallel, using tiling techniques to render large data sets as layers on map, interfaces to allow user to customize the data processing/product chain and other performance enhancing techniques. The conclusion reached from the effort and this presentation is that defining the interoperability standards in a small fraction of the work. For example, once open web service standards were defined, many users could not make use of the standards due to security restrictions. Furthermore, once an interoperable sysm is functional, then a surge of users can render a system unusable, especially in the disaster domain.

Mandl, Daniel↗
NASA NTRS1994

Axial and centrifugal pump meanline performance analysis

A meanline pump flow modeling method has been developed to provide a fast capability for modeling pumps of cryogenic rocket engines. Based on this method, a meanline pump flow code (PUMPA) has been written that can predict the performance of pumps at off-design operating conditions, given the loss of the diffusion system at the design point. The design point rotor efficiency is obtained from empirically derived correlations of loss to rotor specific speed. The rapid input setup and computer run time for the meanline pump flow code makes it an effective analysis and conceptual design tool. The map generation capabilities of the PUMPA code provide the information needed for interfacing with a rocket engine system modeling code.

Veres, Joseph P.↗
NASA NTRS2000

Mean Line Pump Flow Model in Rocket Engine System Simulation

A mean line pump flow modeling method has been developed to provide a fast capability for modeling turbopumps of rocket engines. Based on this method, a mean line pump flow code PUMPA has been written that can predict the performance of pumps at off-design operating conditions, given the loss of the diffusion system at the design point. The pump code can model axial flow inducers, mixed-flow and centrifugal pumps. The code can model multistage pumps in series. The code features rapid input setup and computer run time, and is an effective analysis and conceptual design tool. The map generation capability of the code provides the map information needed for interfacing with a rocket engine system modeling code. The off-design and multistage modeling capabilities of the code permit parametric design space exploration of candidate pump configurations and provide pump performance data for engine system evaluation. The PUMPA code has been integrated with the Numerical Propulsion System Simulation (NPSS) code and an expander rocket engine system has been simulated. The mean line pump flow code runs as an integral part of the NPSS rocket engine system simulation and provides key pump performance information directly to the system model at all operating conditions.

Veres, Joseph P.↗
NASA NTRS1974

MSFC engineering support to Skylab operations

Major engineering support provided during the Skylab mission from the Marshall Space Flight Center and its contractors to the Mission Control Center at Houston was essential to Skylab success. The need for this type of support was anticipated during premission preparations due to the complexity and first-flight nature of the Skylab, but the requirements were greatly magnified by the problems encountered early in the mission. The MFSC engineering support organization and its interface to the Mission Control Center is described. The importance of close cooperation between the operating and engineering organizations in this type of mission is discussed. Illustrations are given from more than 1800 systems analysis actions worked out during the nine-month Skylab mission by more than 600 support engineers.

Kurtz, H. F., Jr.↗
NASA NTRS1995

Centrifugal and Axial Pump Design and Off-Design Performance Prediction

A meanline pump-flow modeling method has been developed to provide a fast capability for modeling pumps of cryogenic rocket engines. Based on this method, a meanline pump-flow code PUMPA was written that can predict the performance of pumps at off-design operating conditions, given the loss of the diffusion system at the design point. The design-point rotor efficiency and slip factors are obtained from empirical correlations to rotor-specific speed and geometry. The pump code can model axial, inducer, mixed-flow, and centrifugal pumps and can model multistage pumps in series. The rapid input setup and computer run time for this meanline pump flow code make it an effective analysis and conceptual design tool. The map-generation capabilities of the code provide the information needed for interfacing with a rocket engine system modeling code. The off-design and multistage modeling capabilities of PUMPA permit the user to do parametric design space exploration of candidate pump configurations and to provide head-flow maps for engine system evaluation.

Veres, Joseph P.↗
NASA NTRS2010

System and method for responding to ground and flight system malfunctions

A system for on-board anomaly resolution for a vehicle has a data repository. The data repository stores data related to different systems, subsystems, and components of the vehicle. The data stored is encoded in a tree-based structure. A query engine is coupled to the data repository. The query engine provides a user and automated interface and provides contextual query to the data repository. An inference engine is coupled to the query engine. The inference engine compares current anomaly data to contextual data stored in the data repository using inference rules. The inference engine generates a potential solution to the current anomaly by referencing the data stored in the data repository.

Fussell, Ronald M.↗
NASA NTRS2019

Mapping the User Journey: Building a User Persona and Story Repository to Improve NASA EOSDIS Application Development

Understanding the needs of the end user is vital to producing quality, usable software that solves real problems. Additionally, making sure those needs are communicated to managers, engineers, and designers at the project level is vital. On complex projects, it's important to build out resources for your team that make it easy to put yourself in the shoes of the specific user you're building for. NASA's Earth Observing System is a collection of data, applications, and a diverse user and scientific community that's trying to answer tough questions about our planet and its climate. Over the last few years, we've spoken to hundreds of users, performed many user testing sessions, and built a collection of user personas, user stories, and design assets that help guide new software and feature development within NASA EOSDIS. We've also developed methods for synthesizing this information and making it actionable for teams, and worked to foster a design first approach on new projects always starting from a core user need and working backward from interface development to software engineering. This process has allowed us to design better, more usable software and features that directly meet the needs of our user community.

Siarto, Jeff↗
NASA NTRS1993

NELS 2.0 - A general system for enterprise wide information management

NELS, the NASA Electronic Library System, is an information management tool for creating distributed repositories of documents, drawings, and code for use and reuse by the aerospace community. The NELS retrieval engine can load metadata and source files of full text objects, perform natural language queries to retrieve ranked objects, and create links to connect user interfaces. For flexibility, the NELS architecture has layered interfaces between the application program and the stored library information. The session manager provides the interface functions for development of NELS applications. The data manager is an interface between session manager and the structured data system. The center of the structured data system is the Wide Area Information Server. This system architecture provides access to information across heterogeneous platforms in a distributed environment. There are presently three user interfaces that connect to the NELS engine; an X-Windows interface, and ASCII interface and the Spatial Data Management System. This paper describes the design and operation of NELS as an information management tool and repository.

Smith, Stephanie L.↗
NASA NTRS1997

NASA X-34 Technology in Motion

The X-34 technology development program is a joint industry/government project to develop, test, and operate a small, fully-reusable hypersonic flight vehicle. The objective is to demonstrate key technologies and operating concepts applicable to future reusable launch vehicles. Integrated in the vehicle are various systems to assure successful completion of mission objectives, including the Main Propulsion System (MPS). NASA-Marshall Space Flight Center (MSFC) is responsible for developing the X-34's MPS including the design and complete build package for the propulsion system components. The X-34 will be powered by the Fastrac Engine, which is currently in design and development at NASA-MSFC. Fastrac is a single-stage main engine, which burns a mixture of liquid oxygen (LOX) and kerosene(RP-1). The interface between the MPS and Fastrac engine are critical for proper system operation and technologies applicable to future reusable launch vehicles. Deneb's IGRIP software package with the Dynamic analysis option provided a key tool for conducting studies critical to this interface as well as a mechanism to drive the design of the LOX and RP-1 feedlines. Kinematic models were created for the Fastrac Engine and the feedlines for various design concepts. Based on the kinematic simulation within Envision, design and joint limits were verified and system interference controlled. It was also critical to the program to evaluate the effect of dynamic loads visually, providing a verification tool for dynamic analysis and in some cases uncovering areas that had not been considered. Deneb's software put the X-34 technology in motion and has been a key factor in facilitating the strenuous design schedule.

Beech, Geoffrey↗
NASA NTRS2022

Mission Planning for Trident: Discovery proposal to Neptune’s moon, Triton

Trident was one of the four Discovery-class Step-1 mission proposals selected by NASA in 2020 for further development and study; however, in 2021, the Step-2 proposal was not down-selected to transition into the next phase of mission development, i.e., a mission for flight.Neptune’s largest moon, Triton, was the primary focus of study for Trident. Triton’s physical and orbital characteristics make it a unique planetary target for scientific exploration, providing opportunities for investigations in a wide variety of scientific fields, including geomorphological, atmospheric, geophysical, magnetospheric, and ionospheric studies. The science objectives of the Trident mission encompassed an in-depth interior-to-exterior set of objectives, focused on multiple outstanding questions resulting from the 1989 encounter of Voyager 2, and subsequent analysis.Ball Aerospace Corp. was tasked with building the Trident spacecraft, with JPL responsible for providing Engineering Support (Mission Design & Navigation, Mission Planning, Flight Operations, Ground Data Systems, Systems Engineering) and leading Project Management. The observatory would carry a wide-ranging suite of scientific instruments onboard, including an Infrared Spectrometer (IRS) and Narrow Angle Camera (NAC) to be provided by Ball Aerospace Corp., a Wide Angle Camera (WAC) from JPL, a Magnetometer from UCLA, a contributed Plasma Science Suite from IRF (Sweden), and a contributed Radio Science instrument from ASI (Italy). All of these instruments would be used to collect unique datasets during the Triton encounter. Trident would have taken advantage of an ~13-yr, nearly-ballistic trajectory to Triton, utilizing a timely Jupiter Gravity Assist, to execute a 10-day long encounter in the Neptunian system. Launch was planned for October 2025, with Triton arrival scheduled for December 2038. The timeline for this mission would have been sub-divided into seven major phases: Launch, Commissioning, Inner Planet Cruise, Outer Planet Cruise, Approach, Encounter, and Science Data Return. Multiple planetary flybys were planned to be performed during the cruise, including three Earth flybys and one Venus flyby in the Inner Planet Cruise phase, and one Jupiter flyby in the Outer Planet Cruise phase. Along with conventional (Range and Doppler) tracking data, Delta-DOR and Optical Navigation data were also to be acquired to assist with spacecraft navigation during the Approach and Encounter phases. A 3 meter X-Band High Gain Antenna would allow playback of all science data at 1 kbps within 1 year after the Triton Encounter. The Mission Planning element on Trident encompassed and informed multiple aspects of this proposal, ranging from science observation planning during the Triton Encounter phase, to generation of activity timelines for all mission phases; performing ground coverage analysis for science observations to be acquired by all instruments and tracing them to science requirements; evaluation of spacecraft resources including data volume stored onboard, power/energy consumption, telecom (commanding/telemetry) requirements, and overall, working at the interface of science and engineering teams on the mission. All of these functions that were performed by the Mission Planning team on this proposal are discussed in this paper.

Prockter, Louise↗
NASA NTRS1974

Space processing applications payload equipment study. Volume 2B: Payload interface analysis (power/thermal/electromagnetic compatibility)

As a part of the task of performing preliminary engineering analysis of modular payload subelement/host vehicle interfaces, a subsystem interface analysis was performed to establish the integrity of the modular approach to the equipment design and integration. Salient areas that were selected for analysis were power and power conditioning, heat rejection and electromagnetic capability (EMC). The equipment and load profiles for twelve representative experiments were identified. Two of the twelve experiments were chosen as being representative of the group and have been described in greater detail to illustrate the evaluations used in the analysis. The shuttle orbiter will provide electrical power from its three fuel cells in support of the orbiter and the Spacelab operations. One of the three shuttle orbiter fuel cells will be dedicated to the Spacelab electrical power requirements during normal shuttle operation. This power supplies the Spacelab subsystems and the excess will be available to the payload. The current Spacelab sybsystem requirements result in a payload allocation of 4.0 to 4.8 kW average (24 hour/day) and 9.0 kW peak for 15 minutes.

Hammel, R. L.↗