Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “hardware”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Pre-Hardware Optimization of Spacecraft Image Processing Software Algorithms and Hardware Implementation

Spacecraft telemetry rates have steadily increased over the last decade presenting a problem for real-time processing by ground facilities. This paper proposes a solution to a related problem for the Geostationary Operational Environmental Spacecraft (GOES-8) image processing application. Although large super-computer facilities are the obvious heritage solution, they are very costly, making it imperative to seek a feasible alternative engineering solution at a fraction of the cost. The solution is based on a Personal Computer (PC) platform and synergy of optimized software algorithms and re-configurable computing hardware technologies, such as Field Programmable Gate Arrays (FPGA) and Digital Signal Processing (DSP). It has been shown in [1] and [2] that this configuration can provide superior inexpensive performance for a chosen application on the ground station or on-board a spacecraft. However, since this technology is still maturing, intensive pre-hardware steps are necessary to achieve the benefits of hardware implementation. This paper describes these steps for the GOES-8 application, a software project developed using Interactive Data Language (IDL) (Trademark of Research Systems, Inc.) on a Workstation/UNIX platform. The solution involves converting the application to a PC/Windows/RC platform, selected mainly by the availability of low cost, adaptable high-speed RC hardware. In order for the hybrid system to run, the IDL software was modified to account for platform differences. It was interesting to examine the gains and losses in performance on the new platform, as well as unexpected observations before implementing hardware. After substantial pre-hardware optimization steps, the necessity of hardware implementation for bottleneck code in the PC environment became evident and solvable beginning with the methodology described in [1], [2], and implementing a novel methodology for this specific application [6]. The PC-RC interface bandwidth problem for the class of applications with moderate input-output data rates but large intermediate multi-thread data streams has been addressed and mitigated. This opens a new class of satellite image processing applications for bottleneck problems solution using RC technologies. The issue of a science algorithm level of abstraction necessary for RC hardware implementation is also described. Selected Matlab functions already implemented in hardware were investigated for their direct applicability to the GOES-8 application with the intent to create a library of Matlab and IDL RC functions for ongoing work. A complete class of spacecraft image processing applications using embedded re-configurable computing technology to meet real-time requirements, including performance results and comparison with the existing system, is described in this paper.

Kizhner, Semion↗
NASA NTRS1989

Space biology initiative program definition review. Trade study 5: Modification of existing hardware (COTS) versus new hardware build cost analysis

The JSC Life Sciences Project Division has been directly supporting NASA Headquarters, Life Sciences Division, in the preparation of data from JSC and ARC to assist in defining the Space Biology Initiative (SBI). GE Government Services and Horizon Aerospace have provided contract support for the development and integration of review data, reports, presentations, and detailed supporting data. An SBI Definition (Non-Advocate) Review at NASA Headquarters, Code B, has been scheduled for the June-July 1989 time period. In a previous NASA Headquarters review, NASA determined that additional supporting data would be beneficial to determine the potential advantages in modifying commercial off-the-shelf (COTS) hardware for some SBI hardware items. In order to meet the demands of program implementation planning with the definition review in late spring of 1989, the definition trade study analysis must be adjusted in scope and schedule to be complete for the SBI Definition (Non-Advocate) Review. The relative costs of modifying existing commercial off-the-shelf (COTS) hardware is compared to fabricating new hardware. An historical basis for new build versus modifying COTS to meet current NMI specifications for manned space flight hardware is surveyed and identified. Selected SBI hardware are identified as potential candidates for off-the-shelf modification and statistical estimates on the relative cost of modifying COTS versus new build are provided.

Jackson, L. Neal↗
NASA NTRS2005

MSAP Hardware Verification: Testing Multi-Mission System Architecture Platform Hardware Using Simulation and Bench Test Equipment

The Multi-Mission System Architecture Platform (MSAP) project aims to develop a system of hardware and software that will provide the core functionality necessary in many JPL missions and can be tailored to accommodate mission-specific requirements. The MSAP flight hardware is being developed in the Verilog hardware description language, allowing developers to simulate their design before releasing it to a field programmable gate array (FPGA). FPGAs can be updated in a matter of minutes, drastically reducing the time and expense required to produce traditional application-specific integrated circuits. Bench test equipment connected to the FPGAs can then probe and run Tcl scripts on the hardware. The Verilog and Tcl code can be reused or modified with each design. These steps are effective in confirming that the design operates according specifications.

Crossin, Kent R.↗
NASA NTRS1995

Analysis of systems hardware flown on LDEF: New findings and comparison to other retrieved spacecraft hardware

The Long Duration Exposure Facility (LDEF) was retrieved in 1990 after spending 69 months in low-earth-orbit (LEO). A wide variety of mechanical, electrical, thermal, and optical systems, subsystems, and components were flown on LDEF. The Systems Special Investigation Group (Systems SIG) was formed by NASA to investigate the effects of the 69 month exposure on systems related hardware and to coordinate and collate all systems analysis of LDEF hardware. This report is the Systems SIG final report which updates earlier findings and compares LDEF systems findings to results from other retrieved spacecraft hardware such as Hubble Space Telescope. Also included are sections titled (1) Effects of Long Duration Space Exposure on Optical Scatter, (2) Contamination Survey of LDEF, and (3) Degradation of Optical Materials in Space.

Dursch, Harry↗
DOE OSTI2026

Use of Power Hardware-in-the-Loop and Controller Hardware-in-the-Loop to De-Risk the Use Of Grid-Forming Fuel Cell Inverters in Microgrids

Microgrids continue to proliferate, particularly those that rely on inverter-based resources as the microgrid's voltage and frequency leader. Hardware-in-the-loop simulations can de-risk microgrid deployments, and therefore we need power-hardware-in-the-loop (PHIL) interfaces for grid-forming (GFM) inverters to enable simulations of seamless transitions between islanded and grid-connected operation. Such interfaces are particularly challenging when the inverters need to switch modes, i.e., between grid-following (GFL) and GFM as the microgrid transitions between grid-connected and islanded operation. This presentation shows the use of PHIL interfaces for such microgrids and the preliminary experimental results.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2025

OPET Hardware (Open PV Electrical Tool Hardware) [SWR-25-42]

OPET (Open-source Photovoltaic Electrical Tool) is used for performance measurements of solar photovoltaic (PV) devices in the field under natural sunlight or in the lab under artificial light. Its primary use is in research and development of solar cells and modules, specifically in reliability and durability research of PV devices. Some features and functions include: -IV curve measurements with linear or cosine distributed measurement points -PV device active loading at open circuit voltage (Voc), short circuit current (Isc) and maximum power point (Pmp) -Bias power supply to overcome series resistance in contact wires for Isc measurements and loading -PV voltage input in five ranges from 1V to 100V -PV current input ranges -Low current version, six current ranges from 1.1mA to 340mA -High current version, six current ranges from 50mA to 15A -IO ports for I2C and SPI temperature sensor Arduino extension boards -Integrated fan control This repository contains everything relating to the hardware of the OPET device. If you are looking for the firmware or software repositories, links are below: https://github.com/NREL/opet-firmware https://github.com/NREL/opet-control

McDanold, Byron [National Renewable Energy Laborat↗
NASA NTRS2002

Pre-Hardware Optimization of Spacecraft Image Processing Algorithms and Hardware Implementation

Spacecraft telemetry rates and telemetry product complexity have steadily increased over the last decade presenting a problem for real-time processing by ground facilities. This paper proposes a solution to a related problem for the Geostationary Operational Environmental Spacecraft (GOES-8) image data processing and color picture generation application. Although large super-computer facilities are the obvious heritage solution, they are very costly, making it imperative to seek a feasible alternative engineering solution at a fraction of the cost. The proposed solution is based on a Personal Computer (PC) platform and synergy of optimized software algorithms, and reconfigurable computing hardware (RC) technologies, such as Field Programmable Gate Arrays (FPGA) and Digital Signal Processors (DSP). It has been shown that this approach can provide superior inexpensive performance for a chosen application on the ground station or on-board a spacecraft.

Kizhner, Semion↗
NASA NTRS2000

Materials Science Research Hardware for Application on the International Space Station: an Overview of Typical Hardware Requirements and Features

NASA's Marshall Space Flight Center (MSFC) is the lead center for Materials Science Microgravity Research. The Materials Science Research Facility (MSRF) is a key development effort underway at MSFC. The MSRF will be the primary facility for microgravity materials science research on board the International Space Station (ISS) and will implement the NASA Materials Science Microgravity Research Program. It will operate in the U.S. Laboratory Module and support U. S. Microgravity Materials Science Investigations. This facility is being designed to maintain the momentum of the U.S. role in microgravity materials science and support NASA's Human Exploration and Development of Space (HEDS) Enterprise goals and objectives for Materials Science. The MSRF as currently envisioned will consist of three Materials Science Research Racks (MSRR), which will be deployed to the International Space Station (ISS) in phases, Each rack is being designed to accommodate various Experiment Modules, which comprise processing facilities for peer selected Materials Science experiments. Phased deployment will enable early opportunities for the U.S. and International Partners, and support the timely incorporation of technology updates to the Experiment Modules and sensor devices.

Schaefer, D. A.↗
NASA NTRS2003

Artificial Neural Network with Hardware Training and Hardware Refresh

A neural network circuit is provided having a plurality of circuits capable of charge storage. Also provided is a plurality of circuits each coupled to at least one of the plurality of charge storage circuits and constructed to generate an output in accordance with a neuron transfer function. Each of a plurality of circuits is coupled to one of the plurality of neuron transfer function circuits and constructed to generate a derivative of the output. A weight update circuit updates the charge storage circuits based upon output from the plurality of transfer function circuits and output from the plurality of derivative circuits. In preferred embodiments, separate training and validation networks share the same set of charge storage circuits and may operate concurrently. The validation network has a separate transfer function circuits each being coupled to the charge storage circuits so as to replicate the training network s coupling of the plurality of charge storage to the plurality of transfer function circuits. The plurality of transfer function circuits may be constructed each having a transconductance amplifier providing differential currents combined to provide an output in accordance with a transfer function. The derivative circuits may have a circuit constructed to generate a biased differential currents combined so as to provide the derivative of the transfer function.

Tuan A Duong↗
NASA NTRS2000

Hardware Development Process for Human Research Facility Applications

The simple goal of the Human Research Facility (HRF) is to conduct human research experiments on the International Space Station (ISS) astronauts during long-duration missions. This is accomplished by providing integration and operation of the necessary hardware and software capabilities. A typical hardware development flow consists of five stages: functional inputs and requirements definition, market research, design life cycle through hardware delivery, crew training, and mission support. The purpose of this presentation is to guide the audience through the early hardware development process: requirement definition through selecting a development path. Specific HRF equipment is used to illustrate the hardware development paths. The source of hardware requirements is the science community and HRF program. The HRF Science Working Group, consisting of SCientists from various medical disciplines, defined a basic set of equipment with functional requirements. This established the performance requirements of the hardware. HRF program requirements focus on making the hardware safe and operational in a space environment. This includes structural, thermal, human factors, and material requirements. Science and HRF program requirements are defined in a hardware requirements document which includes verification methods. Once the hardware is fabricated, requirements are verified by inspection, test, analysis, or demonstration. All data is compiled and reviewed to certify the hardware for flight. Obviously, the basis for all hardware development activities is requirement definition. Full and complete requirement definition is ideal prior to initiating the hardware development. However, this is generally not the case, but the hardware team typically has functional inputs as a guide. The first step is for engineers to conduct market research based on the functional inputs provided by scientists. CommerCially available products are evaluated against the science requirements as well as modifications needed to meet program requirements. Options are consolidated and the hardware development team reaches a hardware development decision point. Within budget and schedule constraints, the team must decide whether or not to complete the hardware as an in-house, subcontract with vendor, or commercial-off-the-shelf (COTS) development. An in-house development indicates NASA personnel or a contractor builds the hardware at a NASA site. A subcontract development is completed off-site by a commercial company. A COTS item is a vendor product available by ordering a specific part number. The team evaluates the pros and cons of each development path. For example, in-bouse developments utilize existing corporate knowledge regarding bow to build equipment for use in space. However, technical expertise would be required to fully understand the medical equipment capabilities, such as for an ultrasound system. It may require additional time and funding to gain the expertise that commercially exists. The major benefit of subcontracting a hardware development is the product is delivered as an end-item and commercial expertise is utilized. On the other hand, NASA has limited control over schedule delays. The final option of COTS or modified COTS equipment is a compromise between in-house and subcontracts. A vendor product may exist that meets all functional requirements but req uires in-house modifications for successful operation in a space environment. The HRF utilizes equipment developed using all of the paths described: inhouse, subcontract, and modified COTS.

Bauer, Liz↗
NASA NTRS2004

The Art of Space Flight Exercise Hardware: Design and Implementation

The design of space flight exercise hardware depends on experience with crew health maintenance in a microgravity environment, history in development of flight-quality exercise hardware, and a foundation for certifying proper project management and design methodology. Developed over the past 40 years, the expertise in designing exercise countermeasures hardware at the Johnson Space Center stems from these three aspects of design. The medical community has steadily pursued an understanding of physiological changes in humans in a weightless environment and methods of counteracting negative effects on the cardiovascular and musculoskeletal system. The effects of weightlessness extend to the pulmonary and neurovestibular system as well with conditions ranging from motion sickness to loss of bone density. Results have shown losses in water weight and muscle mass in antigravity muscle groups. With the support of university-based research groups and partner space agencies, NASA has identified exercise to be the primary countermeasure for long-duration space flight. The history of exercise hardware began during the Apollo Era and leads directly to the present hardware on the International Space Station. Under the classifications of aerobic and resistive exercise, there is a clear line of development from the early devices to the countermeasures hardware used today. In support of all engineering projects, the engineering directorate has created a structured framework for project management. Engineers have identified standards and "best practices" to promote efficient and elegant design of space exercise hardware. The quality of space exercise hardware depends on how well hardware requirements are justified by exercise performance guidelines and crew health indicators. When considering the microgravity environment of the device, designers must consider performance of hardware separately from the combined human-in-hardware system. Astronauts are the caretakers of the hardware while it is deployed and conduct all sanitization, calibration, and maintenance for the devices. Thus, hardware designs must account for these issues with a goal of minimizing crew time on orbit required to complete these tasks. In the future, humans will venture to Mars and exercise countermeasures will play a critical role in allowing us to continue in our spirit of exploration. NASA will benefit from further experimentation on Earth, through the International Space Station, and with advanced biomechanical models to quantify how each device counteracts specific symptoms of weightlessness. With the continued support of international space agencies and the academic research community, we will usher the next frontier in human space exploration.

Beyene, Nahom M.↗
DOE OSTI2025

Even Higher-Level Synthesis: An Exploration of AI Hardware Accelerators using HLS4ML

With the rise of artificial intelligence, the popularization of deep learning, and a constantly evolving industry, the demand for flexible and efficient tools has never been greater. As algorithms grow more complex, their runtime and energy consumption increase exponentially. Customized hardware accelerators, long used for specific mathematical operations, remain essential for managing modern applications' computational and power demands. Hardware accelerators can speed up complex computations by orders of magnitude, but their manual design and verification processes are often challenging and time-consuming. High-Level Synthesis (HLS) provides a solution by transforming high-level algorithm descriptions, typically written in C++ or SystemC, into synthesizable RTL suitable for hardware implementation. This approach reduces development time for RTL engineers while offering flexibility beyond what traditional handwritten RTL can provide. We extended this capability to the machine-learning domain with the open-source framework hls4ml, which allows neural networks trained in Python frameworks like Tensorflow or PyTorch to be synthesized into efficient hardware representations for the traditional FPGA and ASIC flows. This breakthrough addresses the growing need for reduced design turnaround and easy verification of ML hardware accelerators with low latency and power efficiency constraints. During this tutorial, we will demonstrate how Python complements HLS by simplifying the ML design process, bridging the gap between software and hardware development. Attendees will explore how we translate neural networks modeled in Python into fixed-point C++ models suitable for HLS workflows. We will dive into strategies like Value-Range Analysis and Quantization-Aware Training, which optimize these designs for deployment and evaluate their accuracy, power consumption, and energy efficiency. To exemplify these concepts, experts from Fermilab will share their experiences applying this technology to high-energy physics experiments, where real-time, low-latency processing is critical. Over the years, Fermilab engineers have demonstrated how deep neural networks, optimized for hardware using hls4ml, can meet the stringent requirements of trigger systems at the CERN Large Hadron Collider. These systems rely on rapid decision-making to process immense data volumes while retaining only the most relevant events for further analysis. The application of hls4ml has also been extended to innovative technologies like smart pixel arrays. These smart pixels integrate ML inference capabilities directly into sensor devices, enabling localized data processing at the pixel level. This approach drastically reduces the need to transmit raw data to external processing units, significantly decreasing power consumption and latency. By embedding neural networks within the pixel architecture, the smart pixels can identify and prioritize relevant data in real time, providing a highly efficient solution for edge computing in scenarios such as particle detectors and imaging systems. Fermilab's work highlights the potential of hardware-accelerated ML in scenarios where both speed and power efficiency are mission-critical. Through this tutorial, attendees will gain valuable insights into the challenges and solutions of deploying ML in hardware. Understanding how HLS and hls4ml streamline the development of neural network-based hardware accelerators is fundamental for the industry's future. Participants will learn how these technologies are shaping the future of AI and scientific computing.

Di Guglielmo, Giuseppe [Fermilab]↗
NASA NTRS1999

Hardware

The full complement of EDOMP investigations called for a broad spectrum of flight hardware ranging from commercial items, modified for spaceflight, to custom designed hardware made to meet the unique requirements of testing in the space environment. In addition, baseline data collection before and after spaceflight required numerous items of ground-based hardware. Two basic categories of ground-based hardware were used in EDOMP testing before and after flight: (1) hardware used for medical baseline testing and analysis, and (2) flight-like hardware used both for astronaut training and medical testing. To ensure post-landing data collection, hardware was required at both the Kennedy Space Center (KSC) and the Dryden Flight Research Center (DFRC) landing sites. Items that were very large or sensitive to the rigors of shipping were housed permanently at the landing site test facilities. Therefore, multiple sets of hardware were required to adequately support the prime and backup landing sites plus the Johnson Space Center (JSC) laboratories. Development of flight hardware was a major element of the EDOMP. The challenges included obtaining or developing equipment that met the following criteria: (1) compact (small size and light weight), (2) battery-operated or requiring minimal spacecraft power, (3) sturdy enough to survive the rigors of spaceflight, (4) quiet enough to pass acoustics limitations, (5) shielded and filtered adequately to assure electromagnetic compatibility with spacecraft systems, (6) user-friendly in a microgravity environment, and (7) accurate and efficient operation to meet medical investigative requirements.

Source record↗
NASA NTRS1992

A novel visual hardware behavioral language

Most hardware behavioral languages just use texts to describe the behavior of the desired hardware design. This is inconvenient for VLSI designers who enjoy using the schematic approach. The proposed visual hardware behavioral language has the ability to graphically express design information using visual parallel models (blocks), visual sequential models (processes) and visual data flow graphs (which consist of primitive operational icons, control icons, and Data and Synchro links). Thus, the proposed visual hardware behavioral language can not only specify hardware concurrent and sequential functionality, but can also visually expose parallelism, sequentiality, and disjointness (mutually exclusive operations) for the hardware designers. That would make the hardware designers capture the design ideas easily and explicitly using this visual hardware behavioral language.

Li, Xueqin↗
NASA NTRS1998

Electronic processing and control system with programmable hardware

A computer system with reprogrammable hardware allowing dynamically allocating hardware resources for different functions and adaptability for different processors and different operating platforms. All hardware resources are physically partitioned into system-user hardware and application-user hardware depending on the specific operation requirements. A reprogrammable interface preferably interconnects the system-user hardware and application-user hardware.

Alkalaj, Leon↗
NASA NTRS2005

A Common Approach for the Certifying of International Space Station (ISS) Basic Hardware for Ground Safety

In order to support the International Space Station, as well as any future long term human missions, vast amounts of logistical-type hardware is required to be processed through the various launch sites. This category consists of such hardware as spare parts, replacement items, and upgraded hardware. The category also includes samples for experiments and consumables. One attribute that all these items have is they are generally non-hazardous, at least to ground personnel. Even though the items are non-hazardous, launch site ground safety has a responsibility for the protection of personnel, the flight hardware, and launch site resources. In order to fulfill this responsibility, the safety organization must have knowledge of the hardware and its operations. Conversely, the hardware providers are entitled to a process that is commensurate with the hazard. Additionally, a common system should be in place that is flexible enough to account for the requirements at all launch sites, so that, the hardware provider need only complete one process for ground safety regardless of the launch site.

Kirkpatrick, Paul D.↗
DOE OSTI2025

Quantum Simulation of Molecular Dynamics Processes─A Benchmark Study Using a Classical Simulator and Present-Day Quantum Hardware

Here, we explore how the fundamental problems in quantum molecular dynamics can be modeled using classical simulators (emulators) of quantum computers and the actual quantum hardware available to us today. The list of problems we tackle includes propagation of a free wave packet, vibration of a harmonic oscillator, and tunneling through a barrier. Each of these problems starts with the initial wave packet setup. Although Qiskit provides a general method for initializing wave functions, in most cases it generates deep quantum circuits. While these circuits perform well on noiseless simulators, they suffer from excessive noise on quantum hardware. To overcome this issue, we designed a shallower quantum circuit for preparing a Gaussian-like initial wave packet, which improves the performance of real hardware. Next, quantum circuits are implemented to apply the kinetic and potential energy operators for the evolution of a wave function over time. The results of our modeling on classical emulators of quantum hardware agree perfectly with the results obtained using the traditional (classical) methods. This serves as a benchmark and demonstrates that the quantum algorithms and Qiskit codes we developed are accurate. However, the results obtained on the actual quantum hardware available today, such as IBM’s superconducting qubits and IonQ’s trapped ions, indicate large discrepancies due to hardware limitations. This work highlights both the potential and challenges of using quantum computers to solve fundamental quantum molecular dynamics problems.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
NASA NTRS1989

Space biology initiative program definition review. Trade study 2: Prototype utilization in the development of space biology hardware

The objective was to define the factors which space flight hardware developers and planners should consider when determining: (1) the number of hardware units required to support program; (2) design level of the units; and (3) most efficient means of utilization of the units. The analysis considered technology risk, maintainability, reliability, and safety design requirements for achieving the delivery of highest quality flight hardware. Relative cost impacts of the utilization of prototyping were identified. The development of Space Biology Initiative research hardware will involve intertwined hardware/software activities. Experience has shown that software development can be an expensive portion of a system design program. While software prototyping could imply the development of a significantly different end item, an operational system prototype must be considered to be a combination of software and hardware. Hundreds of factors were identified that could be considered in determining the quantity and types of prototypes that should be constructed. In developing the decision models, these factors were combined and reduced by approximately ten-to-one in order to develop a manageable structure based on the major determining factors. The Baseline SBI hardware list of Appendix D was examined and reviewed in detail; however, from the facts available it was impossible to identify the exact types and quantities of prototypes required for each of these items. Although the factors that must be considered could be enumerated for each of these pieces of equipment, the exact status and state of development of the equipment is variable and uncertain at this time.

Jackson, L. Neal↗