Search NASA⌕ Search

SEARCH · Search NASA

Results for “hardware reliability”

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 685 records · Page 38

Lessons Learned from Astrobee Operations on the International Space Station

Since its launch in 2019, NASA has been operating three Astrobee free-flying robots providing an autonomous and adaptable research platform aboard the International Space Station (ISS). These robots have not only facilitated a myriad of national and international research endeavors in microgravity but have also served as a STEM outreach platform for student competitions aboard the ISS. Amidst its extensive operational tenure, spanning over five years and exceeding 1200 hours of cumulative free-flyer operation as of April 2024, the Astrobee robots have encountered software and hardware anomalies. Despite its inherent design for on-orbit repair or replacement, certain anomalies have proven to be complex, necessitating remote resolution via software and firmware updates or, in extreme cases, hardware replacements or the return of faulty units to NASA's ground facilities for repair. Such challenges underscore the delicate balance between the autonomous functionality of Astrobee and the occasional need for human intervention to maintain optimal performance. One recurring point of failure identified during Astrobee's operational lifespan has been the SD card, a critical component utilized by the different Astrobee processors and the Dock Station. The occurrence of SD card anomalies, both on orbit and within ground units, has provided invaluable insights into the improvement of Astrobee's systems and mitigation to future faults. This presentation will focus on four key areas: 1. Overview of Faults and Anomalies: A comprehensive examination of the diverse array of faults and anomalies encountered by Astrobee and its associated systems both in orbit and on the ground. From software glitches to hardware malfunctions, this section provides insights into the challenges faced during Astrobee's operational tenure. 2. Resolution Processes and Procedures: An in-depth discussion of the methodologies and procedures implemented to resolve the encountered anomalies. This includes remote troubleshooting, software patches, firmware updates, and, when necessary, the logistics involved in hardware replacements or down-massing for repair. 3. Implementation of Software Updates and Hardware Upgrades: A detailed exploration of the strategies employed to mitigate the risk of recurring anomalies through the implementation of software updates and hardware upgrades. This section highlights the iterative nature of Astrobee's development, emphasizing the continuous pursuit of robustness and reliability. 4. Lessons Learned and Future Directions: Reflecting on the insights gained from addressing anomalies, this section examines the lessons learned and outlines future directions for enhancing Astrobee's robustness and resilience. It underscores the iterative nature of space exploration and the importance of adaptability and continuous improvement in the pursuit of scientific discovery. Through a nuanced examination of Astrobee's operational challenges and the strategies employed to overcome them, this presentation sheds light on the complexities of operating autonomous robotic systems in the ISS environment. It underscores NASA's commitment to pushing the boundaries of exploration and innovation while navigating the inherent challenges of space exploration.

Astrobee↗

Lessons Learned from Astrobee Operations on the International Space Station

Since its launch in 2019, NASA has been operating three Astrobee free-flying robots providing an autonomous and adaptable research platform aboard the International Space Station (ISS). These robots have not only facilitated a myriad of national and international research endeavors in microgravity but have also served as a STEM outreach platform for student competitions aboard the ISS. Amidst its extensive operational tenure, spanning over five years and exceeding 1200 hours of cumulative free-flyer operation as of April 2024, the Astrobee robots have encountered software and hardware anomalies. Despite its inherent design for on-orbit repair or replacement, certain anomalies have proven to be complex, necessitating remote resolution via software and firmware updates or, in extreme cases, hardware replacements or the return of faulty units to NASA's ground facilities for repair. Such challenges underscore the delicate balance between the autonomous functionality of Astrobee and the occasional need for human intervention to maintain optimal performance. One recurring point of failure identified during Astrobee's operational lifespan has been the SD card, a critical component utilized by the different Astrobee processors and the Dock Station. The occurrence of SD card anomalies, both on orbit and within ground units, has provided invaluable insights into the improvement of Astrobee's systems and mitigation to future faults. This presentation will focus on four key areas: 1. Overview of Faults and Anomalies: A comprehensive examination of the diverse array of faults and anomalies encountered by Astrobee and its associated systems both in orbit and on the ground. From software glitches to hardware malfunctions, this section provides insights into the challenges faced during Astrobee's operational tenure. 2. Resolution Processes and Procedures: An in-depth discussion of the methodologies and procedures implemented to resolve the encountered anomalies. This includes remote troubleshooting, software patches, firmware updates, and, when necessary, the logistics involved in hardware replacements or down-massing for repair. 3. Implementation of Software Updates and Hardware Upgrades: A detailed exploration of the strategies employed to mitigate the risk of recurring anomalies through the implementation of software updates and hardware upgrades. This section highlights the iterative nature of Astrobee's development, emphasizing the continuous pursuit of robustness and reliability. 4. Lessons Learned and Future Directions: Reflecting on the insights gained from addressing anomalies, this section examines the lessons learned and outlines future directions for enhancing Astrobee's robustness and resilience. It underscores the iterative nature of space exploration and the importance of adaptability and continuous improvement in the pursuit of scientific discovery. Through a nuanced examination of Astrobee's operational challenges and the strategies employed to overcome them, this presentation sheds light on the complexities of operating autonomous robotic systems in the ISS environment. It underscores NASA's commitment to pushing the boundaries of exploration and innovation while navigating the inherent challenges of space exploration.

Astrobee↗

Dynamic Time-Variant Connection Management for PGAS Models on InfiniBand

InfiniBand (IB) has established itself as a promising network infrastructure for high-end cluster computing systems as evidenced by its usage in the Top500 supercomputers today. While the IB standard describes multiple communication models (including reliable-connection (RC), and unreliable datagram (UD)), most of its promising features such as remote direct memory access (RDMA), hardware atomics and network fault tolerance are only available for the RC model which requires connections between communicating process pairs. In the past, several researchers have proposed on-demand connection management techniques that establish connections when there is a need to communicate, and not before. While such techniques work well for algorithms and applications that only communicate with a small set of processes in their life-time, there exists a broad set of applications that do not follow this trend. For example, applications that perform dynamic load balancing and adaptive work stealing have a small set of communicating neighbors at any given time, but over time the total number of neighbors can be very high; in some cases, equal to the entire system size. In this paper, we present a dynamic time-variant connection management approach that establishes connections on-demand like previous approaches, but further intelligently tears down some of the unused connections as well. While connection tear-down itself is relevant for any programming model, different models have different complexities. In this paper, we study the Global Arrays (GA) PGAS model for two reasons: (1) the simple one-sided communication primitives provided by GA and other PGAS models ensure that connection requests are always initiated by the origin process without explicit synchronization with the target process---this makes connection tear-down simpler to handle; and (2) GA supports several applications that demonstrate this behavior making it an obvious first target for the proposed enhancements. We evaluate our proposed approach using several micro-benchmarks as well as the NWChem computational chemistry application on more than 6000 processes, and show that our approach can significantly reduce the memory requirements of the communication library while maintaining its performance. To the best of our knowledge, this is the first design, implementation and evaluation of connection tear-down protocols over InfiniBand.

99 GENERAL AND MISCELLANEOUS↗

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

Bootstrapping Multi-Agent Unmanned Aerial Vehicle (UAV) System Integration Using Ground-Based Assets: Lessons Learned

The highly dynamic nature of UAVs imposes significant challenges when conducting initial testing ranging from safety risks posed by high-capacity lithium batteries and spinning propellers to rigorous timing demands on controllers and the consequences of failures mid-air. Flight testing of a single vehicle is time and labor intensive due to these challenges and more, and the complexity increases exponentially with the number of vehicles. While simulations and hardware-in-the-loop bench testing can provide adequate environments for preliminary validation, differences in system deployment architecture, software interfaces, and hardware infrastructure between simulation and a fleet of real UAVs create a sizable gap that must be navigated carefully during system integration. In support of the Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability (ATTRACTOR) project, which had the goal of establishing a basis of certification of trust and trustworthiness in multi-agent autonomous systems, this gap was tackled from two directions. First, a novel mixed-reality simulation environment was engineered to blur the transition from simulation to flight hardware. Second, a fleet of Unmanned Surface Vehicles (USVs) was developed as a test and evaluation platform that more closely represented the final aerial fleet while eliminating many of the risks associated with air vehicles. This paper delves into the second element, analyzing the efficacy of the USV platform in performing system integration testing for the UAV system. In this paper we present the USV fleet and its role in reducing the aforementioned gaps in deployment architecture, software interfaces, and hardware infrastructure when moving from simulation to flight. An overview of the hardware and software onboard the vehicles will be provided along with supporting infrastructure. The system integration process will be documented including results in supporting both the overarching design reference mission (DRM) of ATTRACTOR and individual research efforts conducted during the project. Finally, we will discuss some of the practical lessons learned regarding the testing, deployment, and operation of multi-agent autonomous systems.

Matthew P Vaughan↗

Embedded Volttron Specification - Benchmarking Small Footprint Compute Devices for Volttron

An embedded system is a small footprint computing unit that typically serves a specific purpose closely associated with measurements and control of hardware devices. These units are designed for reasonable durability and operations in a wide range of operating conditions. Some embedded systems support real-time operations and can demonstrate high levels of reliability. Many have failsafe mechanisms built to handle graceful shutdown of the device in exception conditions. The available memory, processing power, and network connectivity of these devices are limited due to the nature of their specific-purpose design and intended application. Industry practice is to carefully design the software for the available hardware capability to suit desired deployment needs. Volttron is an open source agent development and deployment platform designed to enable researchers to interact with devices and appliances without having to write drivers themselves. Hosting Volttron on small footprint embeddable devices enables its demonstration for embedded use. This report details the steps required and the experience in setting up and running Volttron applications on three small footprint devices: the Intel Next Unit of Computing (NUC), the Raspberry Pi 2, and the BeagleBone Black. In addition, the report also details preliminary investigation of the execution performance of Volttron on these devices.

97 MATHEMATICS AND COMPUTING↗

Review of Design Elements within Power Infrastructure Cyber–Physical Test Beds as Threat Analysis Environments

Cyber–physical systems (CPSs) are an integral part of modern society; thus, enhancing these systems’ reliability and resilience is paramount. Cyber–physical testbeds (CPTs) are a safe way to test and explore the interplay between the cyber and physical domains and to cost-effectively enhance the reliability and resilience of CPSs. Here a review of CPT elements, broken down into physical components (simulators, emulators, and physical hardware), soft components (communication protocols, network timing protocols), and user interfaces (visualization-dashboard design considerations) is presented. Various methods used to validate CPS performance are reviewed and evaluated for potential applications in CPT performance validation. Last, initial simulated results for a CPT design, based on the IEEE 33 bus system, are presented, along with a brief discussion on how model-based testing and fault–injection-based testing (using scaling and ramp-type attacks) may be used to help validate CPT performance.

14 SOLAR ENERGY↗

Viking Lander reliability program

The Viking Lander reliability program is reviewed with attention given to the development of the reliability program requirements, reliability program management, documents evaluation, failure modes evaluation, production variation control, failure reporting and correction, and the parts program. Lander hardware failures which have occurred during the mission are listed.

Pilny, M. J.↗

Space shuttles: A pyrotechnic overview

Pyrotechnic components specified in Shuttle system designs to accomplish varied tasks during all mission phases are described. The function of these pyrotechnics in the operation of the space shuttle vehicle is discussed. Designs are presented for pyrotechnics with innovative features of those meeting unique shuttle requirements for safety and reliability. A rationale for the qualification and certification of these devices is developed. Maintenance of this qualified system in production hardware is explained through a description of shuttle flight certification review process.

Graves, T. J.↗

Supersonic combustion performance of hydrogen/hydrocarbon mixtures as determined by a nonintrusive temperature monitor

A simple and reliable OH absorption technique was developed and applied to measure path integrated temperature and OH number density in scramjet combustor hardware. The first series of measurements was made in premixed combustion products at the exit of a Mach 2 nozzle mounted on a hydrogen fueled vitiated heater. The second series of tests was conducted during supersonic combustion evaluation of hydrogen/hydrocarbon fuel mixtures. These measurements were made near the exit of a 48-inch long diverging supersonic combustor. The OH number density measurements indicated that both the nozzle and the combustor flow were not in equilibrium.

Northam, G. Burton↗

Evaluate the application of modal test and analysis processes to structural fault detection in MSFC-STS project elements

The Space Transportation System (STS) is a very complex and expensive flight system which is intended to carry payloads into low Earth orbit and return. A catastrophic failure of the STS (such as experienced in the 51-L incident) results in the loss of both human life as well as very expensive hardware. One impact of this incident was to reaffirm the need to do everything possible to insure the integrity and reliability of the STS is sufficient to produce a safe flight. One means of achieving this goal is to expand the number of inspection technologies available for use on the STS. The purpose was to begin to evaluate the possible use of assessing the structural integrity of STS components for which Marshall Space Flight Center (MSFC) has responsibility. This entailed reviewing the available literature and determining a low-level experimental program which could be performed by MSFC and would help establish the feasibility of using this technology for structural fault detection.

Springer, William T.↗

The Saturn V F-1 engine revisited

This paper describes how the Saturn V F-1 engine could be resurrected for potential use in a new heavy lift launch vehicle (HLLV). Performance, history, and reliability of the F-1 will be discussed and a 1990s F-1 engine configuration presented. The status of residual hardware, production capability, test-stand availability, and a general program plan to accomplish this restart will be presented. Similarities between restarting the F-1 program and restarting the Atlas and Delta engine programs will be discussed.

Shelton, B. W.↗

Versatile dynamic isotope power systems for the exploration of space

Dynamic, isotope-heated power systems are needed to carry out the exploration of space and are major elements identified by NASA for the Space Exploration Initiative (SEI). The Dynamic Isotope Power System (DIPS) Demonstration Program is aimed at establishing the advanced technology as well as the system designs and hardware for the SEI and other exploratory missions. Several conceptual designs of DIPS systems have been developed to provide compact, reliable, and long-lived power systems.

Johnson, Richard A.↗

Evaluation of the Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Array

The current implementation of the Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Arrays (TRIGA) is equipped with CFDP protocol and CCSDS Telemetry and Telecommand framing schemes to replace the CPU intensive software counterpart implementation for reliable deep space communication. We present the hardware/software co-design methodology used to accomplish high data rate throughput. The hardware CFDP protocol stack implementation is then compared against the two recent flight implementations. The results from our experiments show that TRIGA offers more than 3 orders of magnitude throughput improvement with less than one-tenth of the power consumption.

protocol processing hardware↗

Comparison of Knee and Ankle Dynamometry between NASA's X1 Exoskeleton and Biodex System 4

Pre- and post-flight dynamometry is performed on International Space Station crewmembers to characterize microgravity-induced strength changes. Strength is not assessed in flight due to hardware limitations and there is poor understanding of the time course of in-flight changes. PURPOSE: To assess the reliability of a prototype dynamometer, the X1 Exoskeleton (EXO) and its agreement with a Biodex System 4 (BIO). METHODS: Eight subjects (4 M/4 F) completed 2 counterbalanced testing sessions of knee extension/flexion (KE/KF), 1 with BIO and 1 with EXO, with repeated measures within each session in normal gravity. Test-retest reliability (test 1 and 2) and device agreement (BIO vs. EXO) were evaluated. Later, to assess device agreement for ankle plantarflexion (PF), 10 subjects (4 M/6 F) completed 3 test conditions (BIO, EXO, and BIOEXO); BIOEXO was a hybrid condition comprised of the Biodex dynamometer motor and the X1 footplate and ankle frame. Ankle comparisons were: BIO vs. BIOEXO (footplate differences), BIOEXO vs. EXO (motor differences), and BIO vs. EXO (all differences). Reliability for KE/KF was determined by intraclass correlation (ICC). Device agreement was assessed with: 1) repeated measures ANOVA, 2) a measure of concordance (rho), and 3) average difference. RESULTS: ICCs for KE/KF were 0.99 for BIO and 0.96 to 0.99 for EXO. Agreement was high for KE (concordance: 0.86 to 0.95; average differences: -7 to +9 Nm) and low to moderate for KF (concordance: 0.64 to 0.78; average differences: -4 to -29 Nm, P<0.05). BIO vs. BIOEXO PF concordance ranged from 0.89 to 0.92 and mean differences ranged from -9 to +3 Nm (BIO < BIOEXO). BIOEXO vs. EXO PF concordance ranged from 0.73 to 0.80 while mean differences were -18 to -36 Nm (BIOEXO < EXO, P<0.05). PF concordance for BIO vs. EXO was slightly lower (0.61 to 0.84) and mean differences were greater (-27 to -33 Nm; BIO < EXO, P<0.05). CONCLUSION: BIO and EXO were similarly reliable for KE and KF. KE measures produced high agreement between devices; KF did not. For ankle PF, torque differences due to the two footplates were small. However, the X1 motor reports greater torques than the Biodex motor during PF. This first prototype provides proof of concept for a reliable, robotic-based exoskeleton to perform portable dynamometry for large muscle groups of the lower body.

English, K. L.↗

Introduction to ISS Crew Displays

The International Space Station (ISS) began payload operations in earnest in 2000 with the arrival of the Expedition 1. To date, ISS has offered Principal Investigators (PIs) a reliable platform for microgravity research, having hosted thousands of onboard science experiments. Most of this research is supported by experiment hardware and software and many include a crew‐operated Graphical User Interface (GUI). The purpose of this article is to share information with PIs and Payload Developer (PD) teams about the processes, standards, and guidelines applicable to crew GUI design that must be complied with when planning payload software. The goal is not to enumerate all of the ISS display standards, but rather to highlight design guidelines and the ISS Program milestones for verification and approval of onboard crew displays.

Graphical User Interface↗

A Compact Electron-Proton Spectrometer for Moon / Mars Surface Space Weather Monitoring and Crew Protection (CEPS)

Small mass/low-power sensors are needed for autonomous Moon/Mars surface ops that provide alerts to impending adverse space weather conditions. In order to use current operational forecasting tools, a sensor capable of measuring both high-energy electrons and protons is needed. By combining high-TRL Timepix technology with a CdTe layer, this project leverages known technology to fill a critical gap for surface operations. Typical space weather sensors are at least an order of magnitude higher in mass than is expected from Timepix-based devices and are deployed on robotic assets away from human crews. High fidelity measurements at the crew location and subsequent ability are needed to provide warnings to crews to shelter with a device that can easily be carried on the Lunar and Martian surfaces.​ The aim of this project is the development of compact, low power space weather sensors for crew protection based on the combination of AES flight heritage Timepix hardware with novel CdTe (Cadmium Telluride) sensors. CdTe technology has only recently matured to a point where it can be reliably used with Timepix detectors. These detectors will be able to measure electron spectra in an energy range relevant to the RELEASE model, which is used operationally by NASA to provide crew early warning of Solar Energetic Particle Events as well as protons in the energy ranges relevant to human health allowing for event ‘nowcasting’ and total event crew dose prediction. Compared to existing solutions these detectors will be compact enough to travel with crew, providing a significant advantage to space environment situation awareness. Project results indicate that CdTe-based Timepix sensors respond well to energetic electrons, and particle tracks are sufficiently distinct to be able to measure in a mixed radiation field. Thermal testing results point to a needed design modification to mitigate high temperatures the detector will see in space. Radiation susceptibility testing was conducted to assess the radiation hardness of the CdTe-Timepix assembly. Overall, the assembly continued to operate up to 100 kRad of gamma-ray exposure. The system calibration did show drift over time but recovered once exposure was complete.

Dan James Fry↗