SEARCH · Engineering Papers

Results for “INTERFACE”

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 1,279 records · Page 71

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Interface Shape Control using Localized Heating during Bridgman Growth

Numerical calculations were performed to assess the effect of localized radial heating on the melt-crystal interface shape during vertical Bridgman growth. System parameters examined include the ampoule, melt and crystal thermal conductivities, the magnitude and width of localized heating, and the latent heat of crystallization. Concave interface shapes, typical of semiconductor systems, could be flattened or made convex with localized heating. Although localized heating caused shallower thermal gradients ahead of the interface, the magnitude of the localized heating required for convexity was less than that which resulted in a thermal inversion ahead ofthe interface. A convex interface shape was most readily achieved with ampoules of lower thermal conductivity. The conditions under which convection in the melt must be considered were determined.

Volz, M. P.↗

NASA NTRS2008

Molecular Dynamics Simulations of Adhesion at Epoxy Interfaces

The effect of moisture on adhesives used in aerospace applications can be modeled with chemically specific techniques such as molecular dynamics simulation. In the present study, the surface energy and work of adhesion are calculated for epoxy surfaces and interfaces, respectively, by using molecular dynamics simulation. Modifications are made to current theory to calculate the work of adhesion at the epoxy-epoxy interface with and without water. Quantitative agreement with experimental values is obtained for the surface energy and work of adhesion at the interface without water. The work of adhesion agrees qualitatively with the experimental values for the interface with water: the magnitude is reduced 15% with respect to the value for the interface without water. A variation of 26% in the magnitude is observed depending on the water configuration at a concentration of 1.6 wt%. The methods and modifications to the method that are employed to obtain these values are expected to be applicable for other epoxy adhesives to determine the effects of moisture uptake on their work of adhesion.

Frankland, Sarah-Jane V.↗

NASA NTRS2009

TCP/IP Interface for the Satellite Orbit Analysis Program (SOAP)

The Transmission Control Protocol/ Internet protocol (TCP/IP) interface for the Satellite Orbit Analysis Program (SOAP) provides the means for the software to establish real-time interfaces with other software. Such interfaces can operate between two programs, either on the same computer or on different computers joined by a network. The SOAP TCP/IP module employs a client/server interface where SOAP is the server and other applications can be clients. Real-time interfaces between software offer a number of advantages over embedding all of the common functionality within a single program. One advantage is that they allow each program to divide the computation labor between processors or computers running the separate applications. Secondly, each program can be allowed to provide its own expertise domain with other programs able to use this expertise.

Carnright, Robert↗

NASA NTRS2009

XML Translator for Interface Descriptions

A computer program defines an XML schema for specifying the interface to a generic FPGA from the perspective of software that will interact with the device. This XML interface description is then translated into header files for C, Verilog, and VHDL. User interface definition input is checked via both the provided XML schema and the translator module to ensure consistency and accuracy. Currently, programming used on both sides of an interface is inconsistent. This makes it hard to find and fix errors. By using a common schema, both sides are forced to use the same structure by using the same framework and toolset. This makes for easy identification of problems, which leads to the ability to formulate a solution. The toolset contains constants that allow a programmer to use each register, and to access each field in the register. Once programming is complete, the translator is run as part of the make process, which ensures that whenever an interface is changed, all of the code that uses the header files describing it is recompiled.

Boroson, Elizabeth R.↗

NASA NTRS2009

Interface Generation and Compositional Verification in JavaPathfinder

We present a novel algorithm for interface generation of software components. Given a component, our algorithm uses learning techniques to compute a permissive interface representing legal usage of the component. Unlike our previous work, this algorithm does not require knowledge about the component s environment. Furthermore, in contrast to other related approaches, our algorithm computes permissive interfaces even in the presence of non-determinism in the component. Our algorithm is implemented in the JavaPathfinder model checking framework for UML statechart components. We have also added support for automated assume-guarantee style compositional verification in JavaPathfinder, using component interfaces. We report on the application of the presented approach to the generation of interfaces for flight software components.

Giannakopoulou, Dimitra↗

NASA NTRS2010

Adaptation of the Camera Link Interface for Flight-Instrument Applications

COTS (commercial-off-the-shelf) hard ware using an industry-standard Camera Link interface is proposed to accomplish the task of designing, building, assembling, and testing electronics for an airborne spectrometer that would be low-cost, but sustain the required data speed and volume. The focal plane electronics were designed to support that hardware standard. Analysis was done to determine how these COTS electronics could be interfaced with space-qualified camera electronics. Interfaces available for spaceflight application do not support the industry standard Camera Link interface, but with careful design, COTS EGSE (electronics ground support equipment), including camera interfaces and camera simulators, can still be used.

Randall, David P.↗

NASA NTRS2010

NASA Docking System (NDS) Interface Definitions Document (IDD)

The NASA Docking System (NDS) mating system supports low approach velocity docking and provides a modular and reconfigurable standard interface, supporting crewed and autonomous vehicles during mating and assembly operations. The NDS is NASA's implementation for the emerging International Docking System Standard (IDSS) using low impact docking technology. All NDS configurations can mate with the configuration specified in the IDSS Interface Definition Document (IDD) released September 21, 2010. The NDS evolved from the Low Impact Docking System (LIDS). The acronym international Low Impact Docking System (iLIDS) is also used to describe this system. NDS and iLIDS may be used interchangeability. Some of the heritage documentation and implementations (e.g., software command names) used on NDS will continue to use the LIDS acronym. The NDS IDD defines the interface characteristics and performance capability of the NDS, including uses ranging from crewed to autonomous space vehicles and from low earth orbit to deep space exploration. The responsibility for developing space vehicles and for making them technically and operationally compatible with the NDS rests with the vehicle providers. Host vehicle examples include crewed/uncrewed spacecraft, space station modules, elements, etc. Within this document, any docking space vehicle will be referred to as the host vehicle. This document defines the NDS-to-NDS interfaces, as well as the NDS-to-host vehicle interfaces and performance capability.

Source record↗

NASA NTRS2011

Interfaces - Weak Links, Yet Great Opportunities

Inadequate turbomachine interface design can rapidly degrade system performance, yet provide great opportunity for improvements. Engineered coatings of seals and bearing interfaces are major issues in the operational life of power systems. Coatings, films, and combined use of both metals and ceramics play a major role in maintaining component life. Interface coatings, like lubricants, are sacrificial for the benefit of the component. Bearing and sealing surfaces are routinely protected by tribologically paired coatings such as silicon diamond like coatings (SiDLC) in combination with an oil lubricated wave bearing that prolongs bearing operational life. Likewise, of several methods used or researched for detecting interface failures, dopants within coatings show failures in functionally graded ceramic coatings. The Bozzolo-Ferrante-Smith (BFS) materials models and quantum mechanical tools, employed in interface design, are discussed.

Hendricks, Robert C.↗

NASA NTRS2006

Gesture-Controlled Interfaces for Self-Service Machines

Gesture-controlled interfaces are software- driven systems that facilitate device control by translating visual hand and body signals into commands. Such interfaces could be especially attractive for controlling self-service machines (SSMs) for example, public information kiosks, ticket dispensers, gasoline pumps, and automated teller machines (see figure). A gesture-controlled interface would include a vision subsystem comprising one or more charge-coupled-device video cameras (at least two would be needed to acquire three-dimensional images of gestures). The output of the vision system would be processed by a pure software gesture-recognition subsystem. Then a translator subsystem would convert a sequence of recognized gestures into commands for the SSM to be controlled; these could include, for example, a command to display requested information, change control settings, or actuate a ticket- or cash-dispensing mechanism. Depending on the design and operational requirements of the SSM to be controlled, the gesture-controlled interface could be designed to respond to specific static gestures, dynamic gestures, or both. Static and dynamic gestures can include stationary or moving hand signals, arm poses or motions, and/or whole-body postures or motions. Static gestures would be recognized on the basis of their shapes; dynamic gestures would be recognized on the basis of both their shapes and their motions. Because dynamic gestures include temporal as well as spatial content, this gesture- controlled interface can extract more information from dynamic than it can from static gestures.

Cohen, Charles J.↗

NASA NTRS2014

Strain Gage Load Calibration of the Wing Interface Fittings for the Adaptive Compliant Trailing Edge Flap Flight Test

This is the presentation to follow conference paper of the same name. The adaptive compliant trailing edge (ACTE) flap experiment safety of flight requires that the flap to wing interface loads be sensed and monitored in real time to ensure that the wing structural load limits are not exceeded. This paper discusses the strain gage load calibration testing and load equation derivation methodology for the ACTE interface fittings. Both the left and right wing flap interfaces will be monitored and each contains four uniquely designed and instrumented flap interface fittings. The interface hardware design and instrumentation layout are discussed. Twenty one applied test load cases were developed using the predicted in-flight loads for the ACTE experiment.

strain gage calibration↗

NASA NTRS2014

Dust Tolerant Commodity Transfer Interface Mechanisms for Planetary Surfaces

Regolith is present on most planetary surfaces such as Earth's moon, Mars, and Asteroids. If human crews and robotic machinery are to operate on these regolith covered surfaces, they must face the consequences of interacting with regolith fines which consist of particles below 100 microns in diameter down to as small as submicron scale particles. Such fine dust will intrude into mechanisms and interfaces causing a variety of problems such as contamination of clean fluid lines, jamming of mechanisms and damaging connector seals and couplings. Since multiple elements must be assembled in space for system level functionality, it will be inevitable that interfaces will be necessary for structural connections, and to pass commodities such as cryogenic liquid propellants, purge and buffer gases, water, breathing air, pressurizing gases, heat exchange fluids, power and data. When fine regolith dust is present in the environment it can be lofted into interfaces where it can compromise the utility of the interface by preventing the connections from being successfully mated, or by inducing fluid leaks or degradation of power and data transmission. A dust tolerant, hand held "quick-disconnect" cryogenic fluids connector housing has been developed at NASA KSC which can be used by astronaut crews to connect flex lines that will transfer propellants and other useful fluids to the end user. In addition, a dust tolerant, automated, cryogenic fluid, multiple connector, power and data interface mechanism prototype has been developed, fabricated and demonstrated by NASA at Kennedy Space Center (KSC). The design and operation of these prototypes are explained and discussed.

Dust Tolerant↗

NASA NTRS2016

System and Method for Providing a Climate Data Analytic Services Application Programming Interface Distribution Package

A system, method and computer-readable storage devices for providing a climate data analytic services application programming interface distribution package. The example system can provide various components. The system provides a climate data analytic services application programming interface library that enables software applications running on a client device to invoke the capabilities of a climate data analytic service. The system provides a command-line interface that provides a means of interacting with a climate data analytic service by issuing commands directly to the system's server interface. The system provides sample programs that call on the capabilities of the application programming interface library and can be used as templates for the construction of new client applications. The system can also provide test utilities, build utilities, service integration utilities, and documentation.

Schnase, John L.↗

NASA NTRS2016

International Docking Standard (IDSS) Interface Definition Document (IDD) : Revision - E

This International Docking System Standard (IDSS) Interface Definition Document (IDD) is the result of a collaboration by the International Space Station membership to establish a standard docking interface to enable on-orbit crew rescue operations and joint collaborative endeavors utilizing different spacecraft. This IDSS IDD details the physical geometric mating interface and design loads requirements. The physical geometric interface requirements must be strictly followed to ensure physical spacecraft mating compatibility. This includes both defined components and areas that are void of components. The IDD also identifies common design parameters as identified in section 3.0, e.g., docking initial conditions and vehicle mass properties. This information represents a recommended set of design values enveloping a broad set of design reference missions and conditions, which if accommodated in the docking system design, increases the probability of successful docking between different spacecraft. This IDD does not address operational procedures or off-nominal situations, nor does it dictate implementation or design features behind the mating interface. It is the responsibility of the spacecraft developer to perform all hardware verification and validation, and to perform final docking analyses to ensure the needed docking performance and to develop the final certification loads for their application. While there are many other critical requirements needed in the development of a docking system such as fault tolerance, reliability, and environments (e.g. vibration, etc.), it is not the intent of the IDSS IDD to mandate all of these requirements; these requirements must be addressed as part of the specific developer's unique program, spacecraft and mission needs. This approach allows designers the flexibility to design and build docking mechanisms to their unique program needs and requirements. The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions.The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions. The purpose of the IDSS IDD is to provide basic common design parameters to allow developers to independently design compatible docking systems. The IDSS is intended for uses ranging from crewed to autonomous space vehicles, and from Low Earth Orbit (LEO) to deep-space exploration missions.

docking↗

NASA NTRS2015

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗

NASA NTRS2019

Inserting New Technologies into Human-Computer Interfaces for Future Lunar and Mars Missions

Plans call for human cislunar operations and lunar surface access, to prepare for eventual Mars missions. NASA will also develop new opportunities in lunar orbit that provide the foundation and act as a gateway for human exploration deeper into the solar system. Current human spaceflight is complex and requires as many as fifty people to support the International Space Station (ISS) Mission Control Center (MCC) in Houston, Texas. These flight controllers in the front and back rooms of the MCC, serve as an extra pair of eyes overseeing the numerous station systems. Deep space missions - to the moon, Mars, and beyond - will be more complex and place challenging mission constraints on the crew. As the round-trip communication delays increase in deep space exploration, more on-board systems autonomy and functionality will be needed to maintain and control the vehicle. These mission constraints will change the Earth-based ground control approach and will demand efficient and effective human-computer interfaces (HCI) to control a highly complex vehicle or habitat system. All of this necessitates a different approach to designing and developing spacecraft and habitats. In the beginning of new human spaceflight programs, focus is typically on launch vehicle and uncrewed spacecraft design and development. The reasoning behind this focus to enable flight testing of an integrated launch vehicle and spacecraft system to ensure it will be safe enough to allow humans on board. This is an essential process for new spacecraft, however, the practical effect is a lack of funding for the spacecraft’s human interfaces development. It can be many years before the human interface development begins, putting it late in the spacecraft lifecycle, when almost all other spacecraft systems and subsystems are already in place. This forces the usage of existing and proven technologies for the HCI interfaces. We posit that putting the human first in a spacecraft design process will yield a more effective spacecraft for exploration and long duration missions. NASA Human Research Program (HRP) has identified inadequate HCI as a risk for future missions. New tools and procedures to aid the crew in operating a complex spacecraft will be required. This paper discusses ongoing activities in the development of the next generation HCI components and systems, and a new approach toward human interfaces for spacecraft.

Salazar, George A.↗

NASA NTRS2014

UAS Measured Response: The Effect of GCS Control Mode Interfaces on Pilot Ability to Comply with ATC Clearances

This presentation summarizes the background and primary findings from a study on UAS (Unmanned Aerial Systems) pilots' ability to get 'in-the-loop' when responding to air traffic controller clearances around traffic and weather. Pilots controlled a simulated UAS using three different control mode interfaces: a waypoint-to-waypoint interface, an auto-pilot interface (which allowed heading and altitude holds), and a manual stick-and-throttle interface. Pilots' response times were compared across the three conditions, with the waypoint-to-waypoint interface resulting in the slowest pilot performance in several of the metrics. Conclusions from these findings and limitations of the study are discussed.

Measured Response↗

NASA NTRS2023

Molecular Dynamics Simulations of Austenite-Martensite Interfaces in NiTi Shape Memory Alloys

The unique properties of shape memory alloys (SMAs) arise from a reversible martensitic transformation. The nucleation and migration of austenite-martensite interfaces are the key to understanding the SMA properties. Molecular dynamics (MD) simulations can provide important atomic-scale information about these aspects of the transformation, but their time scales prevent the interface formation under near-equilibrium conditions relevant to experiment. We present a new MD methodology which allows for the natural formation of energetically preferred austenite-martensite interfaces under near-equilibrium conditions. Our simulation demonstrates that the interfaces in NiTi are semi-coherent, composed of a series of terrace planes and structural disconnections, and they migrate rapidly through single crystals with only a small thermodynamic driving force. In bi-crystals and polycrystals, the migration of these same interfaces is significantly impeded by grain boundaries and stored elastic energy. This behavior can result in SMA hysteresis via several mechanisms associated with nucleation and non-elastic strain accommodation.

Gabriel Plummer↗

NASA NTRS2022

Europa Clipper Payload Verification and Validation: Avionics-Instrument Interface Test Campaign

NASA's Europa Clipper mission will investigate Jupiter's icy moon Europa using a payload suite consisting of nine instruments to address a range of scientific objectives concerning Europa's habitability. As the project proceeds past its Critical Design Review, confidence is being built in the system's ability to achieve mission objectives through the implementation of a rigorous payload verification and validation (V&V) program. As part of this payload V&V program, instrument box-level testing was performed by the payload team to verify select instrument-avionics interface requirements. This testing was performed at JPL using the avionics testbed's Bulk Data Storage Emulator (BDSEM) with visiting instrument Test Models. This paper summarizes the Data Link test campaign involving roughly four days of functional testing per instrument, including planning, testing methods, types of issues found, and the requirement closure process. Detail is also provided on the development, deployment, and validation of a standardized analysis tool used in data reviews. This testing verified requirements related to commanding rates, loss of link, packet format, clock counters, loopback test capability, and SpaceWire jitter and skew margins. Additional risk reduction testing of basic commanding, counter behavior, science data collection and transfer, and interface swapping was also performed. Because the BDSEM venue was not originally designed to be a run for record venue, the process of characterizing venue fidelity and establishing suitability for requirement closure using data collected in this venue will also be addressed.In order to close requirements, an extensible tool was developed to post-process instrument command and telemetry data from their original binary to a human-readable format and give visibility to errors detected within the data, such as packets with Cyclic Redundancy Check errors. This tool, called payload-packet-parser, is a Python 3.9 command line tool built using a variety of open-source Python libraries. Payload-packet-parser was designed to support parsing command and telemetry packets for all Europa Clipper instruments and additional analysis tools were developed for verification of specific information interface requirements. This test campaign, including post-processing using a single parsing and verification toolset, allowed for early interface testing, alleviating testing burdens on instrument teams and buying down risk on the instrument-avionics interface by finding hardware and software issues and idiosyncrasies prior to integration with system test venues. Over twenty issues were discovered across the payload, resulting in software updates and instrument rework well in advance of any system impacts. This paper concludes with an assessment of benefits and costs of this type of testing and lessons learned.

Montanez, Leticia↗