SEARCH · Engineering Papers
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.
The U.S. National Quantum Initiative places quantum computer scaling in the same category as Moore's law. While the technical basis of semiconductor scale up is well known, the equivalent principle for quantum computers is still being developed here. Let's explore these new ideas.
Abstract not provided.
Will quantum computation become an important milestone in human progress? Here, passionate advocates and equally passionate skeptics abound. IEEE already provides useful, neutral forums for state-of-the-art science and engineering knowledge as well as practical benchmarks for quantum computation evaluation. But could the organization do more?
Quantum computers are creating buzz from Silicon Valley to the halls of Congress. But the hardware has only been prototyped at small scale. Could applying the engineering processes used to scale up semiconductors also accelerate quantum computer development?
Virtual Machine Language (VML) is an award-winning advanced procedural sequencing language in use on NASA deep-space missions since 1997, and was used for the successful entry, descent, and landing (EDL) of the Phoenix spacecraft onto the surface of Mars. Phoenix EDL utilized a state-oriented operations architecture which executed within the constraints of the existing VML 2.0 flight capability, compatible with the linear "land or die" nature of the mission. The intricacies of Phoenix EDL included the planned discarding of portions of the vehicle, the complex communications management for relay through on-orbit assets, the presence of temporally indeterminate physical events, and the need to rapidly catch up four days of sequencing should a reboot of the spacecraft flight computer occur shortly before atmospheric entry. These formidable operational challenges led to new techniques for packaging and coordinating reusable sequences called blocks using one-way synchronization via VML sequencing global variable events. The coordinated blocks acted as an ensemble to land the spacecraft, while individually managing various elements in as simple a fashion as possible. This paper outlines prototype VML 2.1 flight capabilities that have evolved from the one-way synchronization techniques in order to implement even more ambitious autonomous mission capabilities. Target missions for these new capabilities include autonomous touch-and-go sampling of cometary and asteroidal bodies, lunar landing of robotic missions, and ultimately landing of crewed lunar vehicles. Close proximity guidance, navigation, and control operations, on-orbit rendezvous, and descent and landing events featured in these missions require elaborate abort capability, manifesting highly non-linear scenarios that are so complex as to overtax traditional sequencing, or even the sort of one-way coordinated sequencing used during EDL. Foreseeing advanced command and control needs for small body and lunar landing guidance, navigation and control scenarios, work began three years ago on substantial upgrades to VML that are now being exercised in scenarios for lunar landing and comet/asteroid rendezvous. The advanced state-based approach includes coordinated state transition machines with distributed decision-making logic. These state machines are not merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. Combined with the JPL's AutoNav software used on Deep Space 1 and Deep Impact, the system allows spacecraft to autonomously navigate to an unmapped surface, soft-contact, and either land or ascend. The state machine architecture enabled by VML 2.1 has successfully performed sampling missions and lunar descent missions in a simulated environment, and is progressing toward flight capability. The authors are also investigating using the VML 2.1 flight director architecture to perform autonomous activities like rendezvous with a passive hypothetical Mars sample return capsule. The approach being pursued is similar to the touch-and-go sampling state machines, with the added complications associated with the search for, physical capture of, and securing of a separate spacecraft. Complications include optically finding and tracking the Orbiting Sample Capsule (OSC), keeping the OSC illuminated, making orbital adjustments, and physically capturing the OSC. Other applications could include autonomous science collection and fault compensation.
Above the Atlantic Ocean, off the coast of Brazil, there is a dip in the Earth s surrounding magnetic field called the South Atlantic Anomaly. Here, space radiation can reach into Earth s upper atmosphere to interfere with the functioning of satellites, aircraft, and even the International Space Station. "The South Atlantic Anomaly is a hot spot of radiation that the space station goes through at a certain point in orbit," Miria Finckenor, a physicist at Marshall Space Flight Center, describes, "If there s going to be a problem with the electronics, 90 percent of that time, it is going to be in that spot." Space radiation can cause physical damage to microchips and can actually change the software commands in computers. When high-energy particles penetrate a satellite or other spacecraft, the electrical components can absorb the energy and temporarily switch off. If the energy is high enough, it can cause the device to enter a hung state, which can only be addressed by restarting the system. When space radiation affects the operational status of microprocessors, the occurrence is called single event functional interrupt (SEFI). SEFI happens not only to the computers onboard spacecraft in Earth orbit, but to the computers on spacecraft throughout the solar system. "One of the Mars rovers had this problem in the radiation environment and was rebooting itself several times a day. On one occasion, it rebooted 40 times in one day," Finckenor says. "It s hard to obtain any data when you have to constantly reboot and start over."
As we move into the exascale era, the power and energy footprints of high-performance computing (HPC) systems have grown significantly larger. Due to the harsh power and thermal conditions the system, components are exposed to extreme operating conditions. Operation of such modern HPC systems requires deep insights into long term system behavior to maintain its efficiency as well as its longevity. To help the HPC community to gain such insights, we provide double-bit errors using system telemetry data and logs collected from the Summit supercomputer, equipped with 27,648 Tesla V100 GPUs with 2nd-generation high-bandwidth memory (HBM2). The dataset relies on Nvidia XID records internally collected by GPU firmware at the time of failure occurrence, on the reboot-time logs of each Summit node, on node-level job scheduler records collected after each job termination, and on a 1Hz data rate from the baseboard management controllers (BMCs) of each Summit compute node using the OpenBMC event subscription protocol. Technical details can be found in the paper Oles et. al “Understanding GPU Memory Corruption at Extreme Scale: The Summit Case Study” ICS’24 (https://doi.org/10.1145/3650200.3656615).
This project aims to test, validate, and advance the technology readiness level (from TRL5 to TRL7) of a novel low-cost distributed stainless-steel/ceramic coaxial cable sensing (SSC-CCS) technology for in situ monitoring of the boiler tube temperature in existing coal-fired power plants. The novel SSC-CCS sensing technology and associated condition-based monitoring (CBM) software to be demonstrated in this project will lead to an improved understanding of the boiler tube failure mechanisms and a prognostic system to improve the overall performance, reliability, and flexibility of the nation’s coal-fired power plant fleet. A boiler tube monitoring system with distributed coaxial cable temperature sensors and a sensor acquisition system was constructed. The high-temperature coaxial cable sensor with a length of 1.3m was made by using a quartz tube (1mm inner diameter (ID) and 6mm outer diameter (OD)) to concentrically separate a 304 stainless-steel (SS) rod (1mm OD) and SS tube (7.94mm OD and 6.16mm ID). The sensor acquisition system includes a vector network analyzer (VNA), a radio frequency (RF) power amplifier, multiple switches and a USB hub. The distributed stainless-steel quartz coaxial cable sensor (SSQ-CCS) had a linear response to temperature with a resolution uncertainty of σ = 0.77℃. To withstand the harsh conditions of 3,300 steam pressures and 800℃ high temperatures, the sensor was shielded by a protective tube made of the same material as the boiler tube. The protection tube had an OD of 1.5 inches and a thickness of 0.25 inches. In the laboratory tests, the sensor showed good sensitivity and fast response. The drift was bounded between +0.33% and -0.67% during a test at 600℃ for 350 hours, indicating good stability of the sensor. A field test was conducted where four sensors were welded on four superheat tubes (SH-Ts) at a coal-fired power station over 400 days. Conventional thermocouples were welded to the superheater tubes alongside the coaxial cable sensors for the purpose of comparison. Two sensors were capable of distributed sensing, with three multiplexed sensing sections. The other two sensors were single section. During the 400-day test period, the power plant experienced startups and shutdowns. At the steady state operations, the temperature of the boiler tube is about 600℃ (1112°F). The sensors recorded the entire coal-firing processes (start-up, steady state, and shut-down) and the glitch event. A GSM modem and a Watchdog were added to the system to ensure reliable data recording. The GSM modem sent daily messages to plant managers and Clemson team to inform the status of the sensor system. If the system was not normally working, the Watchdog would reboot the system automatically. The new coaxial cable based distributed sensing technology has been proven to be successful in both laboratory and field tests. A comprehensive four-stage multi-physics computational framework has been developed to assist the design, optimization, installation, and operation of SSQ-CCS. With the consideration of various operation conditions, we predict the distributions of flue gas temperatures within coal-fired boilers, the temperature correlation between the boiler tube and SSQ-CCS, and the safety of SSQ-CCS. A conditional-based monitoring system is implemented as well. The computational framework developed in this work can guide the future operation of coal-fired plants and other power plants for the safety prediction of boiler operations.
Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in mission or safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes a set of 55 historic aerospace software error incidents from 1962 to 2023 to determine trends of how and where automation is most likely to fail, behaving unexpectedly. A distinction between software producing unexpected (erroneous) output versus no output (failsilent) is introduced. Of the historical incidents analyzed, 85% were from software producing wrong output rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and not reliable to recover from silent failures. Error origin was within the code/logic itself in 58% of cases, 16% from configurable data, 15% from unexpected sensor input, and 11% from command/operator input. A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing requirements, and 16% of incidents were subjectively deemed “unknown-unknowns”. No incidents were found to be the result of programming language, compiler, tool, or operating system; and only sixteen percent (16%) of all incidents were considered errors traditional computer science/programming in nature. These findings indicate that for fault tolerance, erroneous automation behavior must be a primary consideration especially at critical moments, and reboot recoverability may not be viable. Special care should be taken to validate configurable data and commands prior to use. “Test-like-you-fly”, including hardware-in-the-loop combined with robust off-nominal testing should be used to uncover missing logic arising from unanticipated situations not covered by requirements alone. This study uniquely focuses on manifestations of unexpected flight software behavior, independent of ultimate root cause. We characterize software error behavior and origin to improve software design, test, and operations for resilience to the most common manifestations, and provide a rich dataset for further study.
Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes historic aerospace software errors to determine trends of how and where automation is most likely to fail. A distinction between software producing wrong (erroneous) output versus no output (fail-silent) is introduced. Of the historical incidents analyzed, 87% were from software acting unexpectedly rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and only partially effective for silent software. Errors were traced back to the software logic itself in 62% of cases, 13% within configurable data, and 25% introduced through input. Thirty percent (30%) of unexpected software behavior was caused by the absence of software and 20% was due to “unknown-unknowns”. These findings indicate that to achieve fault tolerance in safety-critical systems, backup strategies must be employed to detect and respond to erroneous software behavior beyond only fail-silent cases, and robust off-nominal testing should be performed to uncover unanticipated situations.