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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 685 records · Page 38

All sources NASA NTRS DOE OSTI

DOE OSTI2024

Collection And Analysis Of Telemetry For The Cyote Heuristic

CATCH CLI focuses on gathering telemetry data, storing it in the Neo4j database, querying for Mitre ATT&CK patterns, and creating STIX 2.1 reports. Key Components: Analysis Modules: Analyze data to detect attack patterns. GoSTOTS Collection Engines: Collect telemetry data. These tools can be used together or individually. Analysis modules rely on data from specific engines to identify attack patterns. Source Code Organization: Engines: CATCH/catch/cmd/collection Modules: CATCH/catch/cmd/analysis CGUI Overview CATCH Graphical User Interface (CGUI) offers a graphical shell to execute CATCH CLI, allowing easy editing of: Analysis Modules Database configurations Profiles (collection and device settings) Neo4j Overview Neo4j is a graph database using the Cypher query language, storing data in JSON. It seamlessly integrates with STIX 2.1 data for: Data Submission: CATCH Collection Engines Data Querying: Analysis Modules CATCH modifies STIX 2.1 data for Neo4j submission and reverts it back during querying. STIG Overview Structured Threat Intelligence Graph (STIG) is a tool for creating, editing, querying, analyzing, and visualizing threat intelligence using STIX 2.1 and storing data in Neo4j. Usage Tools can be run: Manually (CLI): Refer to CATCH documentation User Interface: Run ./cgui/CGUI or go run ./cgui/ Additional Information Logging System: Detailed in the config documentation Further Documentation: Available for CATCH and CGUI

Madsen, MichaelJ. [Idaho National Laboratory (INL)↗

NASA NTRSDate not supplied

Cognitive Engineering in Training: Monitoring and Pilot-Automation Coordination in Complex Environments

This paper reports our investigation of flight path monitoring in aviation. We interviewed experienced pilots to understand the knowledge and skills underlying effective monitoring and we developed an example learning environment to improve these skills. We explore how design of pilot training and learning, like the design of interfaces and of the underlying automation, benefits from cognitive engineering methods and perspective. In aviation, monitoring and managing flight path are critical activities. The influences on flight path are complex and come from the autoflight system, from control actions by the pilot, and from external factors, including weather and Air Traffic Control (ATC). Indeed, inadequate flight path monitoring is a current aviation concern as it has been implicated in accidents and incidents. Effective piloting depends on strategies for noticing, understanding, and anticipating these influences to monitor and manage flight path. Lack of such skills reduces pilots' ability to maintain safety margin and resilience. Although flightdeck automation is intended to aid pilot understanding and prediction, the Fight Management Systems (FMS) can mislead as well as aid the pilot's understanding and projection of what will happen. In dynamic conditions, FMS predictions may be based on old or incomplete information. Understanding such vulnerabilities is an important part of pilot-autoflight coordination. The learning environment we developed is designed to help pilots proactively monitor and manage flight path. We consider how a broad cognitive engineering approach might inform the "what" and "how" of learning in dynamic work domains.

pilot-monitoring↗

NASA NTRS1994

Re-Engineering the Multimission Command System at the Jet Propulsion Laboratory

This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use in JPL's Advanced Multimission Operations System.The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

re-engineering↗

NASA NTRS2009

Engine Gimbal Requirements for Ground Testing of J-2X

Based on the Apollo-era J-2 that powered the second and third stages of the Saturn V, the current J-2X is the liquid hydrogen and oxygen high-altitude rocket engine in development for both the Ares I Upper Stage and Ares V Earth Departure Stage. During my summer 2009 internship, J-2X was at a stage in its design maturity where verification testing needed to be considered for the benefit of adequate test facility preparation. My task was to focus on gimbal requirements and gimbal related hot-fire test plans. Facility capabilities were also of interest, specifically for hot-fire testing slated to occur at test stands A-1, A-2, and A-3 at Stennis Space Center(SSC) in Bay St. Louis, Mississippi. Gimbal requirements and stage interface conditions were investigated by applying a top-to-bottom systems engineering approach, which involved system level requirements, engine level requirements from both government and engine contractor perspectives, component level requirements, and the J-2X to Upper Stage and Earth Departure Stage interface control documents. Previous hydrogen and oxygen liquid rocket engine gimbal verification methods were researched for a glimpse at lessons learned. Discussion among the J-2X community affected by gimballing was organized to obtain input relative to proper verification of their respective component. Implementing suggestions such as gimbal pattern, angulated dwell time, altitude testing options, power level, and feed line orientation, I was able to match tests to test stands in the A Complex at SSC. Potential test capability gaps and risks were identified and pursued. The culmination of all these efforts was to coordinate with SSC to define additional facility requirements for both the A-3 altitude test stand that is currently under construction and the A-1 sea level test stand which is being renovated

Kovalcik, Julia↗

NASA NTRS2010

GLobal Integrated Design Environment (GLIDE): A Concurrent Engineering Application

The GLobal Integrated Design Environment (GLIDE) is a client-server software application purpose-built to mitigate issues associated with real time data sharing in concurrent engineering environments and to facilitate discipline-to-discipline interaction between multiple engineers and researchers. GLIDE is implemented in multiple programming languages utilizing standardized web protocols to enable secure parameter data sharing between engineers and researchers across the Internet in closed and/or widely distributed working environments. A well defined, HyperText Transfer Protocol (HTTP) based Application Programming Interface (API) to the GLIDE client/server environment enables users to interact with GLIDE, and each other, within common and familiar tools. One such common tool, Microsoft Excel (Microsoft Corporation), paired with its add-in API for GLIDE, is discussed in this paper. The top-level examples given demonstrate how this interface improves the efficiency of the design process of a concurrent engineering study while reducing potential errors associated with manually sharing information between study participants.

McGuire, Melissa L.↗

DOE OSTI2025

Tuning Interface Electronic Properties via Chiral Two‐Dimensional Metal‐Organic Frameworks

Control over structural symmetries in nanomaterials offers a powerful approach to engineer electronic properties. For instance, breaking of mirror symmetries in two-dimensional (2D) materials with a hexagonal lattice can lead to nontrivial electronic topologies and correlated-electron phenomena. Yet, the impact of structural chirality on the electronic properties of 2D materials and interfaces remains underexplored. Here, how chiral phases of a 2D metal-organic framework (MOF) with a hexagonal lattice—consisting of hexaazatriphenylene molecules coordinated to Cu atoms—scatter, confine, and perturb the Shockley surface state (SS) electrons of an underlying Ag(111) substrate is investigated. Via low-temperature scanning tunneling microscopy and spectroscopy, noncontact atomic force microscopy, and numerical calculations based on an electronic plane-wave expansion method, modifications of the Ag(111) SS band structure are shown and quantified, including gap openings and lifts of band degeneracies, driven exclusively by the structural chirality of the 2D MOF phases. These findings highlight how structural symmetries, in particular chirality, affect electronic states at material interfaces, expanding on the toolkit for designing 2D materials with tailored electronic properties.

band structure engineering↗

NASA NTRS2000

Structural Modeling Using "Scanning and Mapping" Technique

Supported by NASA Glenn Center, we are in the process developing a structural damage diagnostic and monitoring system for rocket engines, which consists of five modules: Structural Modeling, Measurement Data Pre-Processor, Structural System Identification, Damage Detection Criterion, and Computer Visualization. The function of the system is to detect damage as it is incurred by the engine structures. The scientific principle to identify damage is to utilize the changes in the vibrational properties between the pre-damaged and post-damaged structures. The vibrational properties of the pre-damaged structure can be obtained based on an analytic computer model of the structure. Thus, as the first stage of the whole research plan, we currently focus on the first module - Structural Modeling. Three computer software packages are selected, and will be integrated for this purpose. They are PhotoModeler-Pro, AutoCAD-R14, and MSC/NASTRAN. AutoCAD is the most popular PC-CAD system currently available in the market. For our purpose, it plays like an interface to generate structural models of any particular engine parts or assembly, which is then passed to MSC/NASTRAN for extracting structural dynamic properties. Although AutoCAD is a powerful structural modeling tool, the complexity of engine components requires a further improvement in structural modeling techniques. We are working on a so-called "scanning and mapping" technique, which is a relatively new technique. The basic idea is to producing a full and accurate 3D structural model by tracing on multiple overlapping photographs taken from different angles. There is no need to input point positions, angles, distances or axes. Photographs can be taken by any types of cameras with different lenses. With the integration of such a modeling technique, the capability of structural modeling will be enhanced. The prototypes of any complex structural components will be produced by PhotoModeler first based on existing similar components, then passed to AutoCAD for modification and correction of any discrepancies seen in the Photomodeler version of the 3Dmodel. These three software packages are fully compatible. The DXF file can be used to transfer drawings among those packages. To begin this entire process, we are using a small replica of an actual engine blade as a test object. This paper introduces the accomplishment of our recent work.

Amos, Courtney L.↗

NASA NTRS1982

Stirling Laboratory Research Engine: Preprototype configuration report

The concept of a simple Stirling research engine that could be used by industrial, university, and government laboratories was studied. The conceptual and final designs, hardware fabrication and the experimental validation of a preprototype stirling laboratory research engine (SLRE) were completed. Also completed was a task to identify the potential markets for research engines of this type. An analytical effort was conducted to provide a stirling cycle computer model. The versatile engine is a horizontally opposed, two piston, single acting stirling engine with a split crankshaft drive mechanism; special instrumentation is installed at all component interfaces. Results of a thermodynamic energy balance for the system are reported. Also included are the engine performance results obtained over a range of speeds, working pressures, phase angles and gas temperatures. The potential for a stirling research engine to support the laboratory requirements of educators and researchers was demonstrated.

Hoehn, F. W.↗

NASA NTRS1985

COSMIC/NASTRAN-PATRAN Interface

A three dimensional solid modeling and finite element pre and postprocessing program, PATRAN, uses the latest interactive computer graphics technology, provides a visual means to define a finite element model and its environment, and reviews its resultant model behavior. The capabilities provided by the PATRAN-COSMIC/NASTRAN interface are discussed. While the translator capabilities give some indication of the interface quality between the two programs, there are other attributes to be considered. The ideal interface would be a user transparent union of the two programs so that the engineer could move from one program to the other fluently and naturally. Hence, a valid assessment of the interface completeness must consider how close the current capabilities are to the idealized case. An example problem is presented to demonstrate how COSMIC/NASTRAN and PATRAN can be used together to meet the requirements of an actual engineering application.

Libby, D. H.↗

DOE OSTI2022

Resonant anomalous X-ray reflectivity for revealing ion distributions near electrodes

Energy storage devices–batteries, for example–consist of an electrolyte sandwiched between two charged electrodes through which current can pass. The metal ion organization at the electrode–electrolyte interface, commonly referred to as the electric double layer, determines the efficiency and stability of the device. There are two major challenges with experimentally characterizing the metal ion distribution at the interface.

42 ENGINEERING↗

NASA NTRS2005

Introduction to Flight Test Engineering [Introduction Aux Techniques Des Essais En Vol]

Flight test is at the core of what organizations must do in order to validate the operation and systems on an aircraft. While the AGARDograph series 300 and 160 series deal with aspects of this testing, this volume pulls it all together as an introduction to the process required to do effective flight test engineering. This volume was originally published in 1995. Its utility has been proven in that many flight test organizations and universities have requested copies for their engineers and students. It was felt that re-issuing it in a new format designed for electronic publication would be valuable to the community. This second printing changes none of the text, but rather reformats it. All the original references to AGARD (instead of RTO) are left in place so that none of the flavor of the original publication is lost. This is the Introductory Volume to the Flight Test Techniques Series. It is a general introduction to the various activities and aspects of Flight Test Engineering that must be considered when planning, conducting, and reporting a flight test program. Its main intent is to provide a broad overview to the novice engineer or to other people who have a need to interface with specialists within the flight test community. The first two Sections provide some insight into the question of why flight test and give a short history of flight test engineering. Sections 3 through 10 deal with the preparation for flight testing. They provide guidance on the preliminary factors that must be considered; the composition of the test team; the logistic support requirements; the instrumentation and data processing requirements; the flight test plan; the associated preliminary ground tests; and last, but by no means least, discuss safety aspects. Sections 11 through 27 describe the various types of flight tests that are usually conducted during the development and certification of a new or modified aircraft type. Each Section offers a brief introduction to the topic under consideration, and the nature and the objectives of the tests to be conducted. It lists the test instrumentation (and, where appropriate, other test equipment and facilities) required, describes the test maneuvers to be executed, and indicates the way in which the test data is selected, analyzed, and presented. The various activities that should take place between test flights are presented next. Items that are covered are: who to debrief; what type of reports to send where: types of data analysis required for next flight; review of test data to make a comparison to predicted data and some courses of action if there is not good agreement; and comments on selecting the next test flight. The activities that must take place upon completion of the test program are presented. The types of reports and briefings that should take place and a discussion of some of the uses of the flight test data are covered. A brief forecast is presented of where present trends may be leading.

Test facilities↗

NASA NTRSDate not supplied

The Death of Airmanship: The Urgent Need to Understand Pilot Skills and Knowledge

Aviation awards a special name—airmanship—for the quality of being highly competent in foundational piloting skills, which seem to comprise primarily judgment, decision making, stick-and-rudder skills, and a bit of intuition. The term, which has a mystical quality, has historically resisted analysis; airmanship is acquired solely through experience. The graying of the Boomers and the extreme turbulence of the last few years in commercial aviation have led to a significant loss of those pilots who started out in simpler, round-dial airplanes and made a tortured transition to glass. Those pilots were comfortable disengaging the autopilot at any time, and more importantly, they continued to stay mentally engaged with flight and systems management even as automation continued to encroach on traditional pilot roles. As an industry, we need to prepare for the loss of these pilots by understanding the elements of airmanship and finding a way to replace the competency. The goal is to eliminate “airmanship” by understanding it...by demystifying it. Human factors/cognitive engineering offers tools and methods to develop a system interface that supports skilled performance from the human/technology team. In this presentation, I will talk about my efforts to understand the elements of skilled performance so that they can be trained, or supported by the interface in a seamless manner Specific topics will include the limits of SOP, monitoring for flight path management, alerting non-normals, and autoflight/mode confusion.

pilot skills↗

NASA NTRSDate not supplied

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗

NASA NTRS2023

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be easily expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗

NASA NTRS2014

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a Simulink(R) library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

numerical simulation↗

NASA NTRS2015

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a SimulinkR library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

propulsion simulation↗

NASA NTRS2002

High-Temperature Gas Sensor Array (Electronic Nose) Demonstrated

The ability to measure emissions from aeronautic engines and in commercial applications such as automotive emission control and chemical process monitoring is a necessary first step if one is going to actively control those emissions. One single sensor will not give all the information necessary to determine the chemical composition of a high-temperature, harsh environment. Rather, an array of gas sensor arrays--in effect, a high-temperature electronic "nose"--is necessary to characterize the chemical constituents of a diverse, high-temperature environment, such as an emissions stream. The signals produced by this nose could be analyzed to determine the constituents of the emission stream. Although commercial electronic noses for near-room temperature applications exist, they often depend significantly on lower temperature materials or only one sensor type. A separate development effort necessary for a high-temperature electronic nose is being undertaken by the NASA Glenn Research Center, Case Western Reserve University, Ohio State University, and Makel Engineering, Inc. The sensors are specially designed for hightemperature environments. A first-generation high-temperature electronic nose has been demonstrated on a modified automotive engine. This nose sensor array was composed of sensors designed for hightemperature environments fabricated using microelectromechanical-systems- (MEMS-) based technology. The array included a tin-oxide-based sensor doped for nitrogen oxide (NOx) sensitivity, a SiC-based hydrocarbon (CxHy) sensor, and an oxygen sensor (O2). These sensors operate on different principles--resistor, diode, and electrochemical cell, respectively--and each sensor has very different responses to the individual gases in the environment. A picture showing the sensor head for the array is shown in the photograph on the left and the sensors installed in the engine are shown in the photograph on the right. Electronics are interfaced with the sensors for temperature control and signal conditioning, and packaging designed for high temperatures is necessary for the array to survive the engine environment.

Hunter, Gary W.↗

NASA NTRSDate not supplied

Presenting Model-Based Systems Engineering Information to Non-Modelers

NASA’s Human Research Program’s (HRP) Exploration Medical Capability (ExMC) Element adopted Systems Engineering (SE) principles and Model Based Systems Engineering (MBSE) tools to capture the system functions, system architecture, requirements, interfaces, and clinical capabilities for a future exploration medical system. There are many different stakeholders who may use the information in the model: systems engineers, requirement engineers, clinicians (doctors, nurses, and pharmacists), scientists, and program managers. Many of these individuals do not have access to MBSE modeling toolsor have never used these tools. Many of these individuals (clinicians, scientists, even program managers)may have no experience with SE in general let alone interpreting a systems model. The challenge faced by ExMC was how to present the content in the model to non-modelers in a way they could understand with limited to no training in MBSE or the Systems Modeling Language (SysML) without using the modeling tool. Therefore, from the model, ExMC created an HTML report that is accessible to anyone with a browser. When creating the HTML report, the ExMC SE team talked to stakeholders and received their feedback on what content they wanted and how to display this content. Factoring in feedback, the report arranges the content in a way that not only directs readers through the SE process taken to derive the requirements, but also helps them to understand the fundamental steps in an SE approach. The report includes links to source information (i.e., NASA documentation that describes levels of care) and other SE deliverables (e.g., Concept of Operations). These links were provided to aid in the understanding of how the team created this content through a methodical SE approach. This paper outlines the process used to develop the model, the data chosen to share with stakeholders, many of the model elements used in the report, the review process stakeholders followed, the comments received from the stakeholders, and the lessons ExMC learned through producing this HTML report.

Jeff Cohen↗