SEARCH · Engineering Papers

Results for “hardware and software”

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 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2003

System and Software Reliability (C103)

Within the last decade better reliability models (hardware. software, system) than those currently used have been theorized and developed but not implemented in practice. Previous research on software reliability has shown that while some existing software reliability models are practical, they are no accurate enough. New paradigms of development (e.g. OO) have appeared and associated reliability models have been proposed posed but not investigated. Hardware models have been extensively investigated but not integrated into a system framework. System reliability modeling is the weakest of the three. NASA engineers need better methods and tools to demonstrate that the products meet NASA requirements for reliability measurement. For the new models for the software component of the last decade, there is a great need to bring them into a form that they can be used on software intensive systems. The Statistical Modeling and Estimation of Reliability Functions for Systems (SMERFS'3) tool is an existing vehicle that may be used to incorporate these new modeling advances. Adapting some existing software reliability modeling changes to accommodate major changes in software development technology may also show substantial improvement in prediction accuracy. With some additional research, the next step is to identify and investigate system reliability. System reliability models could then be incorporated in a tool such as SMERFS'3. This tool with better models would greatly add value in assess in GSFC projects.

Wallace, Dolores↗

NASA NTRS1976

Atmospheric, Magnetospheric and Plasmas in Space (AMPS) spacelab payload definition study; volume 4: Part 2, Labcraft payload general specification

The Labcraft Payload General Specification (LPGS) amplifies those general requirements in the Labcraft Program Specification (LPS) to ensure that all hardware, software, and STS elements will successfully function as an integrated system to accomplish the objectives of the first Labcraft mission. Contract End Item Specifications (CEIS) and Procurement Drawings (PDs) prepared and implemented for all deliverable hardware and software elements are discussed.

Keeley, J. T.↗

NASA NTRS1984

Software control and system configuration management: A systems-wide approach

A comprehensive software control and system configuration management process for flight-crucial digital control systems of advanced aircraft has been developed and refined to insure efficient flight system development and safe flight operations. Because of the highly complex interactions among the hardware, software, and system elements of state-of-the-art digital flight control system designs, a systems-wide approach to configuration control and management has been used. Specific procedures are implemented to govern discrepancy reporting and reconciliation, software and hardware change control, systems verification and validation testing, and formal documentation requirements. An active and knowledgeable configuration control board reviews and approves all flight system configuration modifications and revalidation tests. This flexible process has proved effective during the development and flight testing of several research aircraft and remotely piloted research vehicles with digital flight control systems that ranged from relatively simple to highly complex, integrated mechanizations.

Petersen, K. L.↗

NASA NTRS1983

Software control and system configuration management - A process that works

Petersen, K. L.↗

NASA NTRS2015

Intelligent Hardware-Enabled Sensor and Software Safety and Health Management for Autonomous UAS

Unmanned Aerial Systems (UAS) can only be deployed if they can effectively complete their mission and respond to failures and uncertain environmental conditions while maintaining safety with respect to other aircraft as well as humans and property on the ground. We propose to design a real-time, onboard system health management (SHM) capability to continuously monitor essential system components such as sensors, software, and hardware systems for detection and diagnosis of failures and violations of safety or performance rules during the ight of a UAS. Our approach to SHM is three-pronged, providing: (1) real-time monitoring of sensor and software signals; (2) signal analysis, preprocessing, and advanced on-the- y temporal and Bayesian probabilistic fault diagnosis; (3) an unobtrusive, lightweight, read-only, low-power hardware realization using Field Programmable Gate Arrays (FPGAs) in order to avoid overburdening limited computing resources or costly re-certi cation of ight software due to instrumentation. No currently available SHM capabilities (or combinations of currently existing SHM capabilities) come anywhere close to satisfying these three criteria yet NASA will require such intelligent, hardwareenabled sensor and software safety and health management for introducing autonomous UAS into the National Airspace System (NAS). We propose a novel approach of creating modular building blocks for combining responsive runtime monitoring of temporal logic system safety requirements with model-based diagnosis and Bayesian network-based probabilistic analysis. Our proposed research program includes both developing this novel approach and demonstrating its capabilities using the NASA Swift UAS as a demonstration platform.

Robotics↗

NASA NTRS1981

Space Shuttle Dynamic Integrated Tests - Concept and results for STS-1

It is pointed out that ground tests, which involve end-to-end checks of various subsystems often by stimulating an input device and examining the resultant effect, do not exercise dynamically all subsystem interactions encountered during a real flight. The development and implementation of the Dynamic Integrated Test (DIT) for the Space Transportation System, patterned on the ASIST (Avionics System Integration Self Test) concept, are examined. It is noted that the complete hardware-software data paths which are utilized in flight simply do not exist until the vehicle is assembled. The integrated test is considered necessary in order to verify the integrity of these paths, that is, to establish that proper connections have been made, that correct polarity is maintained, and that no unexpected interference is generated. As a result of four tests carried out on the Space Transportation System, hardware and software problems, both on-board the vehicle and within the launch support complex, were identified and resolved. Significant return was also realized in the training of the launch and flight crews.

Brody, S.↗

NASA NTRSDate not supplied

Human-in-the-Loop Evaluations: Process and Mockup Fidelity

Human-in-the-loop (HITL) evaluations are iterative events used during design and development to identify issues with the implementation of human systems integration. HITL evaluations involve human test subjects who are user-representative participants performing activities with representative hardware, software, and procedures. The paper will describe the process by which HITL evaluations can be implemented in a program or project. This will include definitions for developmental and verification HITL evaluations, levels of mockup fidelity, and certification of HITL articles. The proposed process can be tailored depending on the type of HITL evaluation being conducted. It is highly recommended that findings are timely reported and incorporated in the hardware and/or software design.

Jackelynne Silva-Martinez↗

DOE OSTI2026

DISARM: Target Electronic Device Informed Mitigation of Software Runtime Side-Channel Vulnerabilities

Program runtime/timing attacks exploit variations in a program’s execution times to extract sensitive information from the program (e.g. encryption keys, sensitive variable data, intellectual property). State-of-the-art solutions to runtime side-channel attacks attempt to balance the execution time of the sensitive code for different control flow paths to eliminate the timing leakage. However, during the mitigation process, most techniques do not consider the underlying hardware/device on which the target program is supposed to run on. This can lead to over-fixing (unnecessary extra operations), under-fixing (not solving the imbalance properly), and even failures. Here, we propose DISARM, a joint hardware-software methodology (unlike any existing solution) for mitigating runtime side-channel vulnerabilities that utilizes timing values from real embedded devices to generate targeted software fixes. We implement DISARM to support C/C++/Java source codes and validate it across 22 standard benchmarks. DISARM outperforms state-of-the-art solutions such as PENDULUM and DifFuzzaR in terms of execution time overhead, code size overhead, and correctness on five different embedded/edge devices.

Timing/runtime side-channel↗

NASA NTRS1983

Orbiter global positioning system design and Ku-band problem investigations, exhibit B, revision 1

The hardware, software, and interface between them was investigated for a low dynamics, nonhostile environment, low cost GPS receiver (GPS Z set). The set is basically a three dimensional geodetic and way point navigator with GPS time, ground speed, and ground track as possible outputs in addition to the usual GPS receiver set outputs. Each functional module comprising the GPS set is described, enumerating its functional inputs and outputs, leading to the interface between hardware and software of the set.

Lindsey, W. C.↗

NASA NTRS2013

Towards Real-time, On-board, Hardware-Supported Sensor and Software Health Management for Unmanned Aerial Systems

Unmanned aerial systems (UASs) can only be deployed if they can effectively complete their missions and respond to failures and uncertain environmental conditions while maintaining safety with respect to other aircraft as well as humans and property on the ground. In this paper, we design a real-time, on-board system health management (SHM) capability to continuously monitor sensors, software, and hardware components for detection and diagnosis of failures and violations of safety or performance rules during the flight of a UAS. Our approach to SHM is three-pronged, providing: (1) real-time monitoring of sensor and/or software signals; (2) signal analysis, preprocessing, and advanced on the- fly temporal and Bayesian probabilistic fault diagnosis; (3) an unobtrusive, lightweight, read-only, low-power realization using Field Programmable Gate Arrays (FPGAs) that avoids overburdening limited computing resources or costly re-certification of flight software due to instrumentation. Our implementation provides a novel approach of combining modular building blocks, integrating responsive runtime monitoring of temporal logic system safety requirements with model-based diagnosis and Bayesian network-based probabilistic analysis. We demonstrate this approach using actual data from the NASA Swift UAS, an experimental all-electric aircraft.

System & Software Health Management↗

NASA NTRS2015

Towards Real-Time, On-Board, Hardware-Supported Sensor and Software Health Management for Unmanned Aerial Systems

For unmanned aerial systems (UAS) to be successfully deployed and integrated within the national airspace, it is imperative that they possess the capability to effectively complete their missions without compromising the safety of other aircraft, as well as persons and property on the ground. This necessity creates a natural requirement for UAS that can respond to uncertain environmental conditions and emergent failures in real-time, with robustness and resilience close enough to those of manned systems. We introduce a system that meets this requirement with the design of a real-time onboard system health management (SHM) capability to continuously monitor sensors, software, and hardware components. This system can detect and diagnose failures and violations of safety or performance rules during the flight of a UAS. Our approach to SHM is three-pronged, providing: (1) real-time monitoring of sensor and software signals; (2) signal analysis, preprocessing, and advanced on-the-fly temporal and Bayesian probabilistic fault diagnosis; and (3) an unobtrusive, lightweight, read-only, low-power realization using Field Programmable Gate Arrays (FPGAs) that avoids overburdening limited computing resources or costly re-certification of flight software. We call this approach rt-R2U2, a name derived from its requirements. Our implementation provides a novel approach of combining modular building blocks, integrating responsive runtime monitoring of temporal logic system safety requirements with model-based diagnosis and Bayesian network-based probabilistic analysis. We demonstrate this approach using actual flight data from the NASA Swift UAS.

Unmanned Aerial System↗

NASA NTRS2006

A Case for Developing a Ground Based Replication of the Earth, Moon and Mars Spaceflight Infrastructure

When the systems are developed and in place to provide the services needed to operate en route and on the Lunar and Martian surfaces, an Earth based replication will need to be in place for the safety and protection of mission success. The replication will entail all aspects of the flight configuration end to end but will not include any closed loop systems. This would replicate the infrastructure from Lunar and Martian robots, manned surface excursions, through man and unmanned terrestrial bases, through the various types of communication systems and technologies, manned and un-manned space vehicles (large and small), to Earth based systems and control centers. An Earth based replicated infrastructure will enable checkout and test of new technologies, hardware, software updates and upgrades and procedures without putting humans and missions at risk. Analysis of events, what ifs and trouble resolution could be played out on the ground to remove as much risk as possible from any type of proposed change to flight operational systems. With adequate detail, it is possible that failures could be predicted with a high probability and action taken to eliminate failures. A major factor in any mission to the Moon and to Mars is the complexity of systems, interfaces, processes, their limitations, associated risks and the factor of the unknown including the development by many contractors and NASA centers. The need to be able to introduce new technologies over the life of the program requires an end to end test bed to analyze and evaluate these technologies and what will happen when they are introduced into the flight system. The ability to analyze system behaviors end to end under varying conditions would enhance safety e.g. fault tolerances. This analysis along with the ability to mine data from the development environment (e.g. test data), flight ops and modeling/simulations data would provide a level of information not currently available to operations and astronauts. In this paper we will analyze the beginnings of such a replication and what it could do in terms of reducing risk in the near term for development. We will analyze the Space Shuttle Main Engine (SSME) test lab which has to a large extent accomplished this replication for the SSME and has been highly successful in analyzing hardware and software problems and changes. The cost of replicating the flight system as proposed here could be very high if attempted as an afterthought. We will describe the initial steps for the development of a replication of this infrastructure starting with the communication infrastructure. The Constellation of Labs (CofL) under the Command, Control, Communication and Information (C3I) project for the NASA Exploration Initiative will provide the initial foundation upon which to base this replication. Simply put, there is very little margin for error in high latency situations e.g. en-route to/from Mars or in an autonomous process on the Lunar far side. Any thought out approach to reduce risk and increase safety needs to be accomplished end to end with the actual systems configuration.

Bradford, Robert N.↗

NASA NTRS1978

Dynamic feature analysis for Voyager at the Image Processing Laboratory

Voyager 1 and 2 were launched from Cape Kennedy to Jupiter, Saturn, and beyond on September 5, 1977 and August 20, 1977. The role of the Image Processing Laboratory is to provide the Voyager Imaging Team with the necessary support to identify atmospheric features (tiepoints) for Jupiter and Saturn data, and to analyze and display them in a suitable form. This support includes the software needed to acquire and store tiepoints, the hardware needed to interactively display images and tiepoints, and the general image processing environment necessary for decalibration and enhancement of the input images. The objective is an understanding of global circulation in the atmospheres of Jupiter and Saturn. Attention is given to the Voyager imaging subsystem, the Voyager imaging science objectives, hardware, software, display monitors, a dynamic feature study, decalibration, navigation, and data base.

Yagi, G. M.↗

DOE OSTI2026

An Integrated Framework for Memory-Centric Analysis: From Trace Collection to Co-Design

The memory wall phenomenon—where advances in processor performance significantly outpace those in memory subsystems—poses a fundamental challenge for contemporary computing systems. In memory-bound applications, memory subsystem behavior dominates performance, yet existing analysis approaches present significant limitations: detailed microarchitectural simulators require days to weeks to simulate modest workloads; hardware performance counters provide only aggregate statistics that obscure temporal and spatial access patterns; and scaled simulation approaches face challenges in capturing certain behaviors that emerge at larger scales. These limitations reflect a processor-centric design philosophy increasingly misaligned with memory-bound workloads where detailed understanding of memory access patterns, cache hierarchy interactions, and contention is critical for effective optimization. This paper presents an integrated framework for memory-centric analysis that enables effective hardware-software co-design. We describe practical trace collection techniques, including hardware-assisted processor tracing with minimal overhead and portable software-based instrumentation with statistical sampling. We present multi-perspective analysis methods that examine memory behavior from temporal, sequential, spatial, and relational viewpoints, revealing distinct optimization opportunities invisible in aggregate metrics. We detail an architectural modeling framework that uses sampled traces with temporal interpolation and confidence-based filtering to evaluate cache and memory configurations. Evaluation on representative benchmarks demonstrates that this framework achieves practical accuracy (L2 cache errors of 2.64\%, confidence-filtered L3 errors of 9.92\%, bandwidth errors of 7.33\%) while providing substantial speedup (26.8×) over cycle-accurate simulation, enabling rapid design space exploration. We demonstrate how this integrated framework enables systematic identification of both hardware optimizations (memory controller tuning, bank partitioning, NUMA configuration) and software optimizations (data layout restructuring, prefetching strategies, memory-aware scheduling). Through this comprehensive treatment of the memory-centric analysis pipeline—from trace collection through architectural modeling to co-design application—we provide researchers and practitioners with practical techniques for addressing memory bottlenecks in contemporary computing systems.

Gajaria, Dhruv Mayur↗

NASA NTRS1984

Digital data-acquisition system for measuring the free decay of acoustical standing waves in a resonant tube

A low-cost digital system based on an 8-bit Apple II microcomputer has been designed to provide on-line control, data acquisition, and evaluation of sound absorption measurements in gases. The measurements are conducted in a resonant tube, in which an acoustical standing wave is excited, the excitation removed, and the sound absorption evaluated from the free decay envelope. The free decay is initiated from the computer keyboard after the standing wave is established, and the microphone response signal is the source of the analog signal for the A/D converter. The acquisition software is written in ASSEMBLY language and the evaluation software in BASIC. This paper describes the acoustical measurement, hardware, software, and system performance and presents measurements of sound absorption in air as an example.

Meredith, R. W.↗

DOE OSTI2020

Modular autopilot design and development featuring bayesian non-parametric adaptive control

According to an embodiment, there is provided an onboard integrated computational system for an unmanned aircraft system (“Stabilis” autopilot). This is an integrated suite of hardware, software, and data-to-decisions services that are designed to meet the needs of business and research developers of UAS. Stabilis is designed to accelerate the development of any UAS platform and avionics system; it does so with hardware modularity and software adaptation. The Stabilis offers multiple technological advantages technological advantages including: Plug-and-adapt functionality; Data-to-decisions capability; and, On board parallelization capability.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1995

Decision process for effective system reuse

The speed of growth in high technology differs for software, hardware and firmware. Hardware innovations come in leaps, as opposed to the gradual improvements in software and firmware technologies. This inhibits the full utilization of the hardware advances and reduces the cost benefit ratio of high technology ventures. The Microelectronics Systems Branch has committed its resources to use the look ahead technique whereby the technology is researched in its use, current development track and its future capabilities. This knowledge is used to meet the requirements of the space program not only in the nineties but also through 2005. This paper illustrates Analytical Hierarchy Process techniques used effectively and very successfully to support projects reusing systems with predicted enhancements.

Mirchandani, Chandru↗

NASA NTRS2012

Flexible Architecture for FPGAs in Embedded Systems

Commonly, field-programmable gate arrays (FPGAs) being developed in cPCI embedded systems include the bus interface in the FPGA. This complicates the development because the interface is complicated and requires a lot of development time and FPGA resources. In addition, flight qualification requires a substantial amount of time be devoted to just this interface. Another complication of putting the cPCI interface into the FPGA being developed is that configuration information loaded into the device by the cPCI microprocessor is lost when a new bit file is loaded, requiring cumbersome operations to return the system to an operational state. Finally, SRAM-based FPGAs are typically programmed via specialized cables and software, with programming files being loaded either directly into the FPGA, or into PROM devices. This can be cumbersome when doing FPGA development in an embedded environment, and does not have an easy path to flight. Currently, FPGAs used in space applications are usually programmed via multiple space-qualified PROM devices that are physically large and require extra circuitry (typically including a separate one-time programmable FPGA) to enable them to be used for this application. This technology adds a cPCI interface device with a simple, flexible, high-performance backend interface supporting multiple backend FPGAs. It includes a mechanism for programming the FPGAs directly via the microprocessor in the embedded system, eliminating specialized hardware, software, and PROM devices and their associated circuitry. It has a direct path to flight, and no extra hardware and minimal software are required to support reprogramming in flight. The device added is currently a small FPGA, but an advantage of this technology is that the design of the device does not change, regardless of the application in which it is being used. This means that it needs to be qualified for flight only once, and is suitable for one-time programmable devices or an application specific integrated circuit (ASIC). An application programming interface (API) further reduces the development time needed to use the interface device in a system.

Clark, Duane I.↗