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.
An explosive failure of a ground support equipment decontamination unit tank occurred during the postflight deactivation of the oxidizer (nitrogen tetroxide) portion of the Apollo 16 command module reaction control system. A discussion of the significant aspects of the incident and conclusions are included.
This paper describes the prelaunch and post-launch reliability functions which contributed to the success of the Mariner 9 spacecraft. Examples are included to illustrate how each reliability activity was a vital part of each phase of the project. Prelaunch reliability functions included: (1) establishing, negotiating, and monitoring system and subsystem requirements, (2) participating in spacecraft system and subsystem design/hardware reviews, (3) monitoring preparation of failure mode effects and criticality analyses (FMECA), (4) establishing and managing a problem failure reporting (PFR) system for the spacecraft and its support equipment, (5) monitoring electronic parts activities, and (6) participating in spacecraft reviews. Particular emphasis is placed on mission operations reliability assurance activities, which included: (1) spacecraft problem/failure reporting, (2) managing an integrating failure reporting system which covered all mission operations activities, (3) real-time analysis of spacecraft anomalies, and (4) risk assessment.
Failure analysis of tape recorder-producer mechanism - mathematical model for functional design specifications
Failure characteristics analysis of majority voting mechanical feedback servoactuator for Saturn-IV B
Failure analysis and degradation mechanism for orbiting solar cell arrays of applications technology satellites
Evaluation of anion impurities effects on mechanical failure of polycrystalline ceramic materials
A technology program was conducted to identify and verify the optimum valve and actuation system concept for the Space Shuttle Orbit Maneuvering System engine. Of major importance to the valve and actuation system selection was the ten-year, 100-mission, 10,000-cycle life requirement, while maintaining high reliability, low leakage, and low weight. Valve and actuation system concepts were comparatively evaluated against past valve failure reports and potential failure modes due to the shuttle mission profile to aid in the selection of the most optimum concept for design, manufacture and verification testing. Two valve concepts were considered during the preliminary design stage; i.e., the moving seat and lifting ball. Two actuation systems were manufactured and tested. Test results demonstrate the viability of a lifting ball concept as well as the applicability of an ac motor actuation system to best meet the requirements of the shuttle mission.
Postflight analysis data on Nimbus 1 solar array drive motor failure
The-Genesis mission to collect solar-wind samples and return them to Earth for detailed analysis proceeded successfully for 3.5 years. During reentry on September 8, 2004, a failure in the entry, descent and landing sequence resulted in a crash landing of the Genesis sample return capsule. This document describes the findings of the avionics sub-team that supported the accident investigation of the JPL Failure Review Board.
On January 7, 2001, the Genesis spacecraft lifted off from Cape Canaveral. Its mission was to collect solar wind samples and return those samples to Earth for detailed analysis by scientists. The mission proceeded successfully for three-and-a-half years. On September 8, 2004, the spacecraft approached Earth, pointed the Sample Return Capsule (SRC) at its entry target, and then fired pyros that jettisoned the SRC. The SRC carried the valuable samples collected over the prior 29 months. The SRC also contained the requisite hardware (mechanisms, parachutes, and electronics) to manage the process of entry, descent, and landing (EDL). After entering Earth’s atmosphere, the SRC was expected to open a drogue parachute. This should have been followed by a pyro event to release the drogue chute, and then by a pyro event to deploy the main parachute at an approximate elevation of 6.7 kilometers. As the SRC descended to the Utah landing site, helicopters were in position to capture the SRC before the capsule touched down. On September 8, 2004, observers of the SRC’s triumphant return became concerned as the NASA announcer fell silent, and then became even more alarmed as they watched the spacecraft tumble as it streaked across the sky. Long-distance cameras clearly showed that the drogue parachute had not deployed properly.
Reference lists are provided to acceptance data for each of the major subsystems of the thematic mapper. Configuration reports, lists and copies of all failure reports, and requests for deviation/waiver are included.
To achieve NASA’s Artemis program mission objectives a high level of autonomy and ubiquitous autonomy throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and concepts of operations for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, concepts of operations, and interface control documents, in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module(i.e. ECLSS).A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM)to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design –GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1)to implement autonomy at the VSM, MSM, and SM levels;(2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1)Orion as visiting vehicle registers with VSM;(2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) standalone demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.
To achieve NASA’s Artemis program mission objectives a high level of autonomy that is ubiquitous throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and Concepts of Operations (ConOps) for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, ConOps, and interface control documents (ICDs), in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module (i.e. ECLSS). A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM) to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design – GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1) to implement autonomy at the VSM, MSM, and SM levels; (2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with the VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1) Orion as visiting vehicle registers with VSM; (2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.
During development and operation of the Space Shuttle Main Engine (SSME), 27 ground test failures of sufficient severity to be termed 'major incident' have occurred. Resourecs including NASA Failure Investigation Board reports, contractor failure reports, originally recorded data, along with engineering notes, data bases, and presentations connected with the failures were available for compilation into the engine failure review presented in this paper. Most SSME failures were a result of design deficiencies stemming from inadequate definition of dynamic loads. High cycle fatigue was the most frequent mechanism leading to failure. Eighteen of the 27 failures occurred during constant power level operation. Formal board reports were not available for all failures. Therefore, the failure history presented in this paper is not complete or of uniform quality.
During the shuttle era NASA utilized a failure reporting system called the Problem Reporting and Corrective Action (PRACA) it purpose was to identify and track system non-conformance. The PRACA system over the years evolved from a relatively nominal way to identify system problems to a very complex tracking and report generating data base. The PRACA system became the primary method to categorize any and all anomalies from corrosion to catastrophic failure. The systems documented in the PRACA system range from flight hardware to ground or facility support equipment. While the PRACA system is complex, it does possess all the failure modes, times of occurrence, length of system delay, parts repaired or replaced, and corrective action performed. The difficulty is mining the data then to utilize that data in order to estimate component, Line Replaceable Unit (LRU), and system reliability analysis metrics. In this paper, we identify a methodology to categorize qualitative data from the ground system PRACA data base for common ground or facility support equipment. Then utilizing a heuristic developed for review of the PRACA data determine what reports identify a credible failure. These data are the used to determine inter-arrival times to perform an estimation of a metric for repairable component-or LRU reliability. This analysis is used to determine failure modes of the equipment, determine the probability of the component failure mode, and support various quantitative differing techniques for performing repairable system analysis. The result is that an effective and concise estimate of components used in manned space flight operations. The advantage is the components or LRU's are evaluated in the same environment and condition that occurs during the launch process.
This paper summarizes an effort by Gates Aerospace Batteries (GAB) and the Reliability Analysis Center (RAC) to analyze survivability data for both General Electric and GAB NiCd cells utilized in various spacecraft. For simplicity sake, all mission environments are described as either low Earth orbital (LEO) or geosynchronous Earth orbit (GEO). 'Extreme value statistical methods' are applied to this database because of the longevity of the numerous missions while encountering relatively few failures. Every attempt was made to include all known instances of cell-induced-failures of the battery and to exclude battery-induced-failures of the cell. While this distinction may be somewhat limited due to availability of in-flight data, we have accepted the learned opinion of the specific customer contacts to ensure integrity of the common databases. This paper advances the preliminary analysis reported upon at the 1991 NASA Battery Workshop. That prior analysis was concerned with an estimated 278 million cell-hours of operation encompassing 183 satellites. The paper also cited 'no reported failures to date.' This analysis reports on 428 million cell hours of operation emcompassing 212 satellites. This analysis also reports on seven 'cell-induced-failures.'
Failure reports for flight model-1 of the thematic mapper are summarized showing the symptom and cause of failure as well as the corrective action taken. Each report is keyed to the major subsystem against which the failure occurred. Requests for deviation/waiver are listed by number, description, and current status. Copies of engineering proposals are included.
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.