SEARCH · Engineering Papers

Results for “Hardware/Software interfaces”

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 55 records · Page 3

All sources NASA NTRS DOE OSTI

DOE OSTI2025

Extending High-Level Synthesis with AI/ML Methods

Artificial Intelligence (AI) and Machine Learning (ML) methods provide significant opportunities of improving quality of results when performing high-level synthesis (HLS). For example, they can be used to model and predict metrics of the final design (e.g., area, considering aspects such as interconnect overhead for different device technologies), facilitating exploration when searching for the best design trade-offs. They can also enable identifying hidden correlations across the various phases of the synthesis and the various optimizations performed, identifying the most effective pipelines. Finally, in more general terms, bio-inspired heuristic algorithms can improve the design space exploration for the synthesis process in terms of time and quality of the result. This paper discusses opportunities and challenges to augment HLS with AI/ML using as example flow the SODA Synthesizer, an open-source hardware generation toolchain which includes SODA-OPT, a hardware/software partitioning and pre-optimization tool developed with the MLIR framework, and PandA-Bambu, a state-of-the art HLS tool. SODA interfaces with OpenROAD to provide a complete end-to-end toolchain.

artificial intelligence↗

NASA NTRS1987

Orbital Spacecraft Consumables Resupply System (OSCRS). Volume 4: Extended study results Part 1: Executive Summary

The objectives consisted of three major tasks. The first was to establish the definition of Space Station and Orbital Maneuvering Vehicle (OMV) user requirements and interfaces and to evaluate system requirements of a water tanker to be used at the station. The second task is to conduct trade studies of system requirements, hardware/software, and operations to evaluate the effect of automatic operation at the station or remote from the station in consonance with the OMV. The last task is to evaluate automatic refueling concepts and to evaluate the impact to Orbital Spacecraft Consumable Resupply System (OSCRS) concept/design to use expendable launch vehicles (ELV) to place the tank into orbit. Progress in each area is discussed.

Source record↗

NASA NTRS1980

Orbiter subsystem hardware/software interaction analysis. Volume 8: Forward reaction control system

The results of the orbiter hardware/software interaction analysis for the AFT reaction control system are presented. The interaction between hardware failure modes and software are examined in order to identify associated issues and risks. All orbiter subsystems and interfacing program elements which interact with the orbiter computer flight software are analyzed. The failure modes identified in the subsystem/element failure mode and effects analysis are discussed.

Becker, D. D.↗

DOE OSTI2023

Best practices for documenting a scientific Python project

Documentation is a crucial component of software development that helps users with installation and usage of the software. Documentation also helps onboard new developers to a software project with contributing guidelines and API information. The INTERSECT project is an open federated hardware/software library to facilitate the development of au- tonomous laboratories. A documentation strategy using Sphinx has been utilized to help developers contribute to source code and to help users understand the INTERSECT Python interface. Docstrings as well as reStructuredText files are used by Sphinx to automatically compile HTML and PDF files which can be hosted online as API documentation and user guides. The resulting documentation website is automatically built and deployed using GitLab runners to create Docker containers with NGINX servers. The approach discussed in this paper to automatically deploy documentation for a Python project can improve the user and developer experience for many scientific projects.

Wiggins, Gavin↗

DOE OSTI2022

INTERSECT Architecture Specification: Use Case Design Patterns (V.0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the federated microservice architecture specification. This document represents the science use case design pattern catalog of the INTERSECT Open Architecture Specification.

42 ENGINEERING↗

DOE OSTI2022

INTERSECT Architecture Specification: Microservice Architecture (V.0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2023

INTERSECT Architecture Specification: Microservice Architecture (V.0.9)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1987

Real-time analysis of telemetry data

This paper descibes a knowledge-based system for performing real-time monitoring and analysis of telemetry data from the NASA Hubble Space Telescope (HST). In order to handle asynchronous inputs and perform in real time the system consists of three or more separate processes, which run concurrently and communicate via a message passing scheme. The data management process gathers, compresses, and scales the incoming telemetry data befoe sending it to the other tasks. The inferencing process uses the incoming data to perform a real-time analysis of the state and health of the Space Telescope. The I/O process receives telemetry monitors from the data management process, updates its graphical displays in real time, and acts as the interface to the console operator. The three processes may run on the same or different computers. This system is currently under development and is being used to monitor testcases produced by the Bass Telemetry System in the Hardware/Software Integration Facility at Lockheed Missile and Space Co. in Sunnyvale, California.

Kao, Simon A.↗

NASA NTRS1986

An overview of the Land Analysis System (LAS)

An outline covering the history, development methodology, and major hardware/software components of the Land Analysis System (LAS) is presented. System support services including the Transportable Applications Executive (TAE), Catalog Manager, history files, and applications services are briefly described along with the general functional capabilities of the 224 available applications programs. Example interface menus are given and desired enhancements to the LAS system are listed.

Lu, Yun-Chi↗

NASA NTRS2009

Usability: Human Research Program - Space Human Factors and Habitability

The Usability project addresses the need for research in the area of metrics and methodologies used in hardware and software usability testing in order to define quantifiable and verifiable usability requirements. A usability test is a human-in-the-loop evaluation where a participant works through a realistic set of representative tasks using the hardware/software under investigation. The purpose of this research is to define metrics and methodologies for measuring and verifying usability in the aerospace domain in accordance with FY09 focus on errors, consistency, and mobility/maneuverability. Usability metrics must be predictive of success with the interfaces, must be easy to obtain and/or calculate, and must meet the intent of current Human Systems Integration Requirements (HSIR). Methodologies must work within the constraints of the aerospace domain, be cost and time efficient, and be able to be applied without extensive specialized training.

Sandor, Aniko↗

NASA NTRS2011

Computational Electromagnetics (CEM) Laboratory: Simulation Planning Guide

The simulation process, milestones and inputs are unknowns to first-time users of the CEM Laboratory. The Simulation Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their engineering personnel in simulation planning and execution. Material covered includes a roadmap of the simulation process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, facility interfaces, and inputs necessary to define scope, cost, and schedule are included as an appendix to the guide.

Khayat, Michael A.↗

NASA NTRS2011

Systems Engineering Simulator (SES) Simulator Planning Guide

The simulation process, milestones and inputs are unknowns to first-time users of the SES. The Simulator Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their engineering personnel in simulation planning and execution. Material covered includes a roadmap of the simulation process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, facility interfaces, and inputs necessary to define scope, cost, and schedule are included as an appendix to the guide.

McFarlane, Michael↗

NASA NTRS2012

Communication Systems Simulation Laboratory (CSSL): Simulation Planning Guide

The simulation process, milestones and inputs are unknowns to first-time users of the CSSL. The Simulation Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their engineering personnel in simulation planning and execution. Material covered includes a roadmap of the simulation process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, facility interfaces, and inputs necessary to define scope, cost, and schedule are included as an appendix to the guide.

Schlesinger, Adam↗

DOE OSTI2022

INTERSECT Architecture Specification: System-of-systems Architecture (Version 0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected ScienceEcosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The architecture project is divided into three focus areas: design patterns; SoS architecture; and microservices architecture. The design patterns area focuses on describing science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions interms of control, work and data flow. The SoS architecture area focuses on an open architecture specification for the federated ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. The microservices architecture describes blueprints for loosely coupled microservices, standardized interfaces, and multi-programming language support. This document is the SoS Architecture specification only, and captures the system of systems architecture design for the INTERSECT Initiative and its components. It is intended to provide a deep analysis and specification of how the INTERSECT platform will be designed, and to link the scientific needs identified across disciplines with the technical needs involved in the support, development, and evolution of a science ecosystem. PLEASE NOTE: This is a working document and reflects current discussions and design activity among the authors. There may be inconsistencies within the document as different parts evolve at a different pace. We invite comments and thoughts from the public on this and following working drafts. The first finished version of this document is scheduled for release in September 2023.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2011

Atmospheric Reentry Materials and Structures Evaluation Facility (ARMSEF). User Test Planning Guide

Test process, milestones and inputs are unknowns to first-time users of the ARMSEF. The User Test Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their test engineering personnel in test planning and execution. Material covered includes a roadmap of the test process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, test article interfaces, and inputs necessary to define test scope, cost, and schedule are included as an appendix to the guide.

Source record↗

NASA NTRS2011

Structures Test Laboratory (STL). User Test Planning Guide

Test process, milestones and inputs are unknowns to first-time users of the STL. The User Test Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their test engineering personnel in test planning and execution. Material covered includes a roadmap of the test process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, test article interfaces, and inputs necessary to define test scope, cost, and schedule are included as an appendix to the guide.

Zipay, John J.↗

NASA NTRS2011

Radiant Heat Test Facility (RHTF): User Test Planning Guide

Test process, milestones and inputs are unknowns to first-time users of the RHTF. The User Test Planning Guide aids in establishing expectations for both NASA and non- NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their test engineering personnel in test planning and execution. Material covered includes a roadmap of the test process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, test article interfaces, and inputs necessary to define test scope, cost, and schedule are included as an appendix to the guide.

DelPapa, Steven↗

NASA NTRS2011

Antenna Test Facility (ATF): User Test Planning Guide

Test process, milestones and inputs are unknowns to first-time users of the ATF. The User Test Planning Guide aids in establishing expectations for both NASA and non-NASA facility customers. The potential audience for this guide includes both internal and commercial spaceflight hardware/software developers. It is intended to assist their test engineering personnel in test planning and execution. Material covered includes a roadmap of the test process, roles and responsibilities of facility and user, major milestones, facility capabilities, and inputs required by the facility. Samples of deliverables, test article interfaces, and inputs necessary to define test scope, cost, and schedule are included as an appendix to the guide.

Lin, Greg↗