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 505 records · Page 28
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

Engine Data Interpretation System (EDIS), phase 2

A prototype of an expert system was developed which applies qualitative constraint-based reasoning to the task of post-test analysis of data resulting from a rocket engine firing. Data anomalies are detected and corresponding faults are diagnosed. Engine behavior is reconstructed using measured data and knowledge about engine behavior. Knowledge about common faults guides but does not restrict the search for the best explanation in terms of hypothesized faults. The system contains domain knowledge about the behavior of common rocket engine components and was configured for use with the Space Shuttle Main Engine (SSME). A graphical user interface allows an expert user to intimately interact with the system during diagnosis. The system was applied to data taken during actual SSME tests where data anomalies were observed.

Cost, Thomas L.↗
NASA NTRS1993

Operability engineering in the Deep Space Network

Many operability problems exist at the three Deep Space Communications Complexes (DSCC's) of the Deep Space Network (DSN). Four years ago, the position of DSN Operability Engineer was created to provide the opportunity for someone to take a system-level approach to solving these problems. Since that time, a process has been developed for personnel and development engineers and for enforcing user interface standards in software designed for the DSCC's. Plans are for the participation of operations personnel in the product life-cycle to expand in the future.

Wilkinson, Belinda↗
NASA NTRS1994

High Temperature Calibration Furnace System user's guide

The High Temperature Calibration Furnace System (HTCFS) was developed by Summitec Corporation. It is a high precision instrument providing a constant temperature which can be used to calibrate high temperature thermocouples. Incorporating the many recent technological advances from the fields of optical fiber thermometry, material science, computer systems interfacing, and process control, the engineers at Summitec Corporation have been able to create a system that can reach a steady operating temperature of 1700 C. The precision for the system requires the measurement of temperature to be within 1 C in two hours and within 2 C in 24 hours. As documented, the experimental result shows that this system has been able to stay within .5 C in 5 hours. No other systems commercially available have been able to achieve such high temperature precision. This manual provides an overview of the system design, instructions for instrument setup, and operation procedures. Also included are a vendor list and the source codes for the custom-designed software.

Source record↗
NASA NTRS1996

A human factors analysis of EVA time requirements

Human Factors Engineering (HFE), also known as Ergonomics, is a discipline whose goal is to engineer a safer, more efficient interface between humans and machines. HFE makes use of a wide range of tools and techniques to fulfill this goal. One of these tools is known as motion and time study, a technique used to develop time standards for given tasks. A human factors motion and time study was initiated with the goal of developing a database of EVA task times and a method of utilizing the database to predict how long an ExtraVehicular Activity (EVA) should take. Initial development relied on the EVA activities performed during the STS-61 mission (Hubble repair). The first step of the analysis was to become familiar with EVAs and with the previous studies and documents produced on EVAs. After reviewing these documents, an initial set of task primitives and task time modifiers was developed. Videotaped footage of STS-61 EVAs were analyzed using these primitives and task time modifiers. Data for two entire EVA missions and portions of several others, each with two EVA astronauts, was collected for analysis. Feedback from the analysis of the data will be used to further refine the primitives and task time modifiers used. Analysis of variance techniques for categorical data will be used to determine which factors may, individually or by interactions, effect the primitive times and how much of an effect they have.

Pate, D. W.↗
NASA NTRS1997

A Human Factors Analysis of EVA Time Requirements

Human Factors Engineering (HFE) is a discipline whose goal is to engineer a safer, more efficient interface between humans and machines. HFE makes use of a wide range of tools and techniques to fulfill this goal. One of these tools is known as motion and time study, a technique used to develop time standards for given tasks. During the summer of 1995, a human factors motion and time study was initiated with the goals of developing a database of EVA task times and developing a method of utilizing the database to predict how long an EVA should take. Initial development relied on the EVA activities performed during the STS-61 (Hubble) mission. The first step of the study was to become familiar with EVA's, the previous task-time studies, and documents produced on EVA's. After reviewing these documents, an initial set of task primitives and task-time modifiers was developed. Data was collected from videotaped footage of two entire STS-61 EVA missions and portions of several others, each with two EVA astronauts. Feedback from the analysis of the data was used to further refine the primitives and modifiers used. The project was continued during the summer of 1996, during which data on human errors was also collected and analyzed. Additional data from the STS-71 mission was also collected. Analysis of variance techniques for categorical data was used to determine which factors may affect the primitive times and how much of an effect they have. Probability distributions for the various task were also generated. Further analysis of the modifiers and interactions is planned.

Pate, Dennis W.↗
NASA NTRS2007

General Mission Analysis Tool (GMAT) Acceptance Test Plan [Draft]

The information presented in this Acceptance Test Plan document shows the current status of the General Mission Analysis Tool (GMAT). GMAT is a software system developed by NASA Goddard Space Flight Center (GSFC) in collaboration with the private sector. The GMAT development team continuously performs acceptance tests in order to verify that the software continues to operate properly after updates are made. The GMAT Development team consists of NASA/GSFC Code 583 software developers, NASA/GSFC Code 595 analysts, and contractors of varying professions. GMAT was developed to provide a development approach that maintains involvement from the private sector and academia, encourages collaborative funding from multiple government agencies and the private sector, and promotes the transfer of technology from government funded research to the private sector. GMAT contains many capabilities, such as integrated formation flying modeling and MATLAB compatibility. The propagation capabilities in GMAT allow for fully coupled dynamics modeling of multiple spacecraft, in any flight regime. Other capabilities in GMAT inclucle: user definable coordinate systems, 3-D graphics in any coordinate system GMAT can calculate, 2-D plots, branch commands, solvers, optimizers, GMAT functions, planetary ephemeris sources including DE405, DE200, SLP and analytic models, script events, impulsive and finite maneuver models, and many more. GMAT runs on Windows, Mac, and Linux platforms. Both the Graphical User Interface (GUI) and the GMAT engine were built and tested on all of the mentioned platforms. GMAT was designed for intuitive use from both the GUI and with an importable script language similar to that of MATLAB.

Dove, Edwin↗
NASA NTRS2015

Use of Existing CAD Models for Radiation Shielding Analysis

The utility of a radiation exposure analysis depends not only on the accuracy of the underlying particle transport code, but also on the accuracy of the geometric representations of both the vehicle used as radiation shielding mass and the phantom representation of the human form. The current NASA/Space Radiation Analysis Group (SRAG) process to determine crew radiation exposure in a vehicle design incorporates both output from an analytic High Z and Energy Particle Transport (HZETRN) code and the properties (i.e., material thicknesses) of a previously processed drawing. This geometry pre-process can be time-consuming, and the results are less accurate than those determined using a Monte Carlo-based particle transport code. The current work aims to improve this process. Although several Monte Carlo programs (FLUKA, Geant4) are readily available, most use an internal geometry engine. The lack of an interface with the standard CAD formats used by the vehicle designers limits the ability of the user to communicate complex geometries. Translation of native CAD drawings into a format readable by these transport programs is time consuming and prone to error. The Direct Accelerated Geometry -United (DAGU) project is intended to provide an interface between the native vehicle or phantom CAD geometry and multiple particle transport codes to minimize problem setup, computing time and analysis error.

Lee, K. T.↗
DOE OSTI2021

SMART-COM – Scalable Multi-Agent Adaptive Resolution Tools for Collaborative Outage Management

The purpose of this grant was to conduct scientific research and prototype applications to support NPP outage staff in their adaptive decision-making in efficient scheduling and resource allocation while preventing violation of safety technical specifications. The project contributed to scientific knowledge and engineering methods in (1) user interface design, (2) scheduling optimization and risk estimation, and (2) natural language processing that would benefit the nuclear power plants in minimizing schedule overruns and even unexpected shutdowns. The research team conducted site visits at a test reactor facility and an operating nuclear power plant to gather necessary information and inputs for research and development of a software application to support NPP staff in executing their outages. The final software application consisted of three modules. First, the natural language processing module supports interactive processing of technical documentation to build a database for outage staff to query non-permissible actions on system components. This module can alleviate outage staff from reviewing extensive documentation and minimize violation of technical specifications, especially in time-sensitive situations. Second, the schedule optimization module schedules outage activities and compute risk indices that outperform existing software and current practice. This module can reduce completion time of an outage that typically have too many activities for human to optimize based on current practice that does not apply the latest operations research. Finally, the visualization module presents progress and risk information of the overall outage and individual activities, as well as enabling access to the natural language processing and schedule optimization modules. This module can provide outage staff with situation awareness that are necessary to make risk-informed decisions in response to unexpected events during the execution of an outage.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1986

Solenoid-Simulation Circuit

Electrical properties of solenoids imitated for tests of control circuits. Simulation circuit imitates voltage and current responses of two engine-controlling solenoids. Used in tests of programs of digital engine-control circuits, also provides electronic interface with circuits imitating electrical properties of pressure sensors and linear variable-differential transformers. Produces voltages, currents, delays, and discrete turnon and turnoff signals representing operation of solenoid in engine-control relay. Many such circuits used simulating overall engine circuitry.

Simon, R. A.↗
NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗
NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗
NASA NTRS2019

MBSE for the Gateway Program

The Gateway Program and many of its module developers are using Magic Draw to coordinate functions, requirements, and interfaces between the various elements that make up the Gateway Platform. This also extends to the visiting vehicles (Human Lander System, Logistics Module, and Orion). The Propulsion and Power Element (PPE) is using Magic Draw to coordinate the design activities at NASA GRC (Glenn Research Center) and the contractor. This discussion will provide an overview of the MBSE (Model-Based Systems Engineering) efforts and how we are interfacing the various MBSE models into a single integrated model.

Systems Engineering↗
NASA NTRS1981

Space shuttle main engine controller

A technical description of the space shuttle main engine controller, which provides engine checkout prior to launch, engine control and monitoring during launch, and engine safety and monitoring in orbit, is presented. Each of the major controller subassemblies, the central processing unit, the computer interface electronics, the input electronics, the output electronics, and the power supplies are described and discussed in detail along with engine and orbiter interfaces and operational requirements. The controller represents a unique application of digital concepts, techniques, and technology in monitoring, managing, and controlling a high performance rocket engine propulsion system. The operational requirements placed on the controller, the extremely harsh operating environment to which it is exposed, and the reliability demanded, result in the most complex and rugged digital system ever designed, fabricated, and flown.

Mattox, R. M.↗
NASA NTRS1982

Conceptual design and cost analysis of hydraulic output unit for 15 kW free-piston Stirling engine

A long-life hydraulic converter with unique features was conceptually designed to interface with a specified 15 kW(e) free-piston Stirling engine in a solar thermal dish application. Hydraulic fluid at 34.5 MPa (5000 psi) is produced to drive a conventional hydraulic motor and rotary alternator. Efficiency of the low-maintenance converter design was calculated at 93.5% for a counterbalanced version and 97.0% without the counterbalance feature. If the converter were coupled to a Stirling engine with design parameters more typcial of high-technology Stirling engines, counterbalanced converter efficiency could be increased to 99.6%. Dynamic computer simulation studies were conducted to evaluate performance and system sensitivities. Production costs of the complete Stirling hydraulic/electric power system were evaluated at $6506 which compared with $8746 for an alternative Stirling engine/linear alternator system.

White, M. A.↗
DOE OSTI2020

Interface learning of multiphysics and multiscale systems

Complex natural or engineered systems comprise multiple characteristic scales, multiple spatiotemporal domains, and even multiple physical closure laws. To address such challenges, we introduce an interface learning paradigm and put forth a data-driven closure approach based on memory embedding to provide physically correct boundary conditions at the interface. To enable the interface learning for hyperbolic systems by considering the domain of influence and wave structures into account, we put forth the concept of upwind learning toward a physics-informed domain decomposition. The promise of the proposed approach is shown for a set of canonical illustrative problems. Here, we highlight that high-performance computing environments can benefit from this methodology to reduce communication costs among processing units in emerging machine-learning-ready heterogeneous platforms toward exascale era.

42 ENGINEERING↗
NASA NTRS2011

CropEx Web-Based Agricultural Monitoring and Decision Support

CropEx is a Web-based agricultural Decision Support System (DSS) that monitors changes in crop health over time. It is designed to be used by a wide range of both public and private organizations, including individual producers and regional government offices with a vested interest in tracking vegetation health. The database and data management system automatically retrieve and ingest data for the area of interest. Another stores results of the processing and supports the DSS. The processing engine will allow server-side analysis of imagery with support for image sub-setting and a set of core raster operations for image classification, creation of vegetation indices, and change detection. The system includes the Web-based (CropEx) interface, data ingestion system, server-side processing engine, and a database processing engine. It contains a Web-based interface that has multi-tiered security profiles for multiple users. The interface provides the ability to identify areas of interest to specific users, user profiles, and methods of processing and data types for selected or created areas of interest. A compilation of programs is used to ingest available data into the system, classify that data, profile that data for quality, and make data available for the processing engine immediately upon the data s availability to the system (near real time). The processing engine consists of methods and algorithms used to process the data in a real-time fashion without copying, storing, or moving the raw data. The engine makes results available to the database processing engine for storage and further manipulation. The database processing engine ingests data from the image processing engine, distills those results into numerical indices, and stores each index for an area of interest. This process happens each time new data is ingested and processed for the area of interest, and upon subsequent database entries, the database processing engine qualifies each value for each area of interest and conducts a logical processing of results indicating when and where thresholds are exceeded. Reports are provided at regular, operator-determined intervals that include variances from thresholds and links to view raw data for verification, if necessary. The technology and method of development allow the code base to easily be modified for varied use in the real-time and near-real-time processing environments. In addition, the final product will be demonstrated as a means for rapid draft assessment of imagery.

Harvey. Craig↗
DOE OSTI2023

ZPAL v.1.0.0

SAND2024-01003O ZPAL is a Python software development kit designed for use by network automation engineers. It is an application programming interface (API) wrapper that is compatible with ZPE System's Nodegrid API. ZPE produces networking equipment. ZPAL simplifies connections to the ZPE Nodegrid API and makes configuration changes on the associated networking equipment. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Hill, Roscoe↗
DOE OSTI2021

Optimization Plugin Library

The Optimization Plugin library ("op") is a lightweight general optimization solver interface. The primary purpose of op is to simplify the process of integrating different optimization solvers (serial or parallel) with scalable parallel physics engines. By design it has several features that help make this a reality. The core abstraction interface was developed to encompass a large class of optimization problems in an optimizer-agnostic way. This enables us to describe the optimization problem once and then use a variety of supported "op" optimizers with ideally no code-changes. The abstraction interface is made up of lightweight wrappers that make it easy to integrate with existing simulation codes. This makes integration less intrusive and should minimize changes to existing physics codes. The "op" interface includes an assortment of utility methods that help specify parallel communication patterns as well as methods to convert from optimization-specific interfaces to the more general "op" interface. Lastly a dynamic library linking interface is provided to allow for use of proprietary optimization engines without explicit reference in the source code, along with standard shared library interfaces for opensource engines.

Jekel, CharlesF↗