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.
Dick Young introduces Dr. Jack Kaye, Program Scientist for NASA, Brewster Shaw, Deputy Program Manager Space Shuttle, and Robert Sieck, Kennedy Space Center (KSC) Launch Director in a press conference regarding the failed launch attempt of the Discovery Orbiter. The hardware problem causing the failure is discussed, and questions from the press are answered.
Rainfinity, a company resulting from the commercialization of Reliable Array of Independent Nodes (RAIN), produces the product, Rainwall. Rainwall runs a cluster of computer workstations, creating a distributed Internet gateway. When Rainwall detects a failure in software or hardware, traffic is shifted to a healthy gateway without interruptions to Internet service. It more evenly distributes workload across servers, providing less down time.
This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.
Extrusion of a polytetrafluoroethylene (PTFE) pilot seal located in the Space Shuttle Orbiter Primary Reaction Control Subsystem (PRCS) thruster fuel valve has been implicated in 68 ground and on-orbit fuel valve failures. A rash of six extrusion-related in-flight anomalies over a six-mission span from December 2001 to October 2002 led to heightened activity at various NASA centers, and the formation of a multidisciplinary team to solve the problem. Empirical and theoretical approaches were used. For example, thermomechanical analysis (TMA) and exposure tests showed that some extrusion is produced by thermal cycling; however, a review of thruster service histories did not reveal a strong link between thermal cycling and extrusion. Calculations showed that the amount of observed extrusion often exceeded the amount allowed by thermally-induced stress relief. Failure analysis of failed hardware also revealed the presence of fuel-oxidizer reaction product (FORP) inside the fuel valve pilot seal cavity, and differential scanning calorimetry (DSC) showed that the FORP was intimately associated with the pilot seal material. Component-level exposure tests showed that FORP of similar composition could be produced by adjacent oxidizer valve leakage in the absence of thruster firing. Specific gravity data showed that extruded fuel valve pilot seals were less dense than new pilot seals or oxidizer valve pilot seals, indicating permanent modification of the PTFE occurred during service. It is concluded that some thermally-induced extrusion is unavoidable; however, oxidizer leakage-induced extrusion is mostly avoidable and can be mitigated. Several engineering level mitigation strategies are discussed.
Following the Colombia accident, the Extravehicular Mobility Units (EMU) onboard ISS were unused for several months. Upon startup, the units experienced a failure in the coolant system. This failure resulted in the loss of Extravehicular Activity (EVA) capability from the US segment of ISS. With limited on-orbit evidence, a team of chemists, engineers, metallurgists, and microbiologists were able to identify the cause of the failure and develop recovery hardware and procedures. As a result of this work, the ISS crew regained the capability to perform EVAs from the US segment of the ISS.
For the Hyper-X/X-43A program, the development of a comprehensive validation test plan played an integral part in the success of the mission. The goal was to demonstrate hypersonic propulsion technologies by flight testing an airframe-integrated scramjet engine. Preparation for flight involved both verification and validation testing. By definition, verification is the process of assuring that the product meets design requirements; whereas validation is the process of assuring that the design meets mission requirements for the intended environment. This report presents an overview of the program with emphasis on the validation efforts. It includes topics such as hardware-in-the-loop, failure modes and effects, aircraft-in-the-loop, plugs-out, power characterization, antenna pattern, integration, combined systems, captive carry, and flight testing. Where applicable, test results are also discussed. The report provides a brief description of the flight systems onboard the X-43A research vehicle and an introduction to the ground support equipment required to execute the validation plan. The intent is to provide validation concepts that are applicable to current, follow-on, and next generation vehicles that share the hybrid spacecraft and aircraft characteristics of the Hyper-X vehicle.
It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.
It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.
It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.
Nondestructive evaluation (NDE) methods examine material integrity without impairing its usefulness. The NDE team at NASA Marshall Space Flight Center (MSFC) in Huntsville, Alabama is responsible for applying existing methods to new hardware designs and material systems, probability of detection studies to quantify detection capabilities, overseeing NDE requirements for flight hardware, inspecting development articles and flight hardware, engineering support for failure investigations, and investigating emerging NDE methods. NASA MSFC has been on the cutting edge of developing new NDE techniques, first for the space shuttle, then for composite structures, and most recently for additive manufacturing (AM). Standard in-house inspection capabilities include eddy current, magnetic particle, liquid penetrant, ultrasonic, and radiographic testing (including computed tomography). Other advanced inspection capabilities include infrared flash thermography, shearography, acoustic emission, and microwave/millimeter wave testing. Some recent research studies include AM probability of detection testing, investigating in-situ process monitoring methods for AM, and correlating the NDE response of true fatigue cracks with artificial notches.
Diagnostic systems are important for many aerospace systems, which are severely limited in available power, like cubesats or UAVs. Therefore, traditional diagnostics systems cannot be used due to their substantial footprint and constraints. In this paper, we present our very low power diagnostic tool SPIKE-DX to monitor critical systems with constrained computational and energy resources. This is made possible through spiking neural networks (SNNs), which are executable within optimized simulation environments and further implemented on on cutting-edge neuromorphic hardware. Based upon FMEA (Failure Mode and Effect Analysis) framework, Diagnostic Bayesian Networks (DBNs) can be constructed that provide powerful means for diagnostic reasoning. In this paper, we describe such DBNs and a method to automatically translate the DBN into highly structured networks of spiking neurons for execution in SPIKE-DX.
A reliable nondestructive evaluation (NDE) technique provides minimum 90% probability of detection (POD) with 95% confidence for detection of cracklike flaws of a specific size. This requirement comes from fracture control. Fracture control is a risk assessment and control approach for preventing structural failure of fracture critical hardware during its service life. One of the approaches of fracture control is damage tolerance safe life analysis, which assumes that NDE reliably detectable size flaw may exist in the hardware post nondestructive evaluation. Analysis and/or testing are performed to verify that the hardware will not fail during its service life despite existence of such a flaw. NDE methods are conventionally qualified by probability of detection (POD) demonstration testing to ensure reliable flaw detection. Here, a novel and alternative to POD flaw detection reliability approach that uses contrast-to-noise ratio (CNR) is given. The approach uses CNR sensitivity function (SF) and CNR. CNR SF is the minimum CNR needed for reliable flaw detection as a function of certain flaw indication characteristics. Primary difference between POD approaches and CNR flaw detection reliability approach is resolution of flaw detection system. POD approach does not account for the resolution of the system, while CNR approach accounts for the flaw detection resolution. Resolution is determined from the modulation transfer function (MTF) of the flaw detection system. CNR flaw detection reliability approach emphasizes quantitative assessment of “how well each flaw indication is detected”. Therefore, CNR approach is helpful in reducing number of flaws in the sample used in NDE procedure qualification, resulting in cost and time savings. CNR approach is also a case of multi-hit flaw detection analysis which has better flaw detectability size than conventional single-hit flaw detectability. Thus, CNR approach, where applicable, may be superior to conventional POD approach. The paper is an overview of development of CNR modeling, CNR SF modeling and measurement by the author. The paper gives key references to currently used NDE procedure POD qualification approaches including those specific to CNR and CNR SF development in multi-hit flaw detection in NDE. The paper covers core topics in nondestructive evaluation engineering.
A significant problem associated with fault tolerant computer system design is how to insure that there are no embedded software errors, so that an avionics computer system meets the required reliability level. To accomplish this, it is necessary to associate a 'probability of failure' with the operational flight program. It would be more correct to say that the probability of excitation of existing latent design errors within the program is required. In this sense, latent software errors are like latent hardware faults, and techniques that were previously used to measure the probability of failure of hardware due to fault latency can be used to measure the probability of failure of the software. A methodology was developed and applied to a flight control program that was known to operate in a well defined environment. The results indicated that the technique could be used to provide a final validation of the software to a specified reliability level and to evaluate the role of flight test in software validation.
The design, development, and operation of long duration spaceflight hardware has become an evolutionary process in which meticulous attention to details and lessons learned from previous experiences play a critical role. Invaluable to this process is the ability to retrieve and examine spaceflight hardware that has experienced a premature failure. While these situations are rare and unfortunate, the failure investigation and recovery from the event serve a valuable purpose in advancing future space mechanism development. Such a scenario began on July 31, 2010 with the premature failure of an ammonia pump on the external active thermal control system of the International Space Station. The ground-based inspections of the returned pump and ensuing failure investigation revealed five potential bearing forces that were un-accounted for in the design phase and qualification testing of the pump. These forces could combine in a number of random orientations to overload the pump bearings leading to solid-surface contact, wear, and premature failure. The recovery plan identified one of these five forces as being related to the square of the operating speed of the pump and this fact was used to recover design life through a change in flight rules for the operation of the pump module. Through the course of the failure investigation, recovery, and follow-on assessment of pump wear life, design guidance has been developed to improve the life of future mechanically pumped thermal control systems for both human and robotic exploration missions.
An Engineering-of-Failure approach to designing and executing an accelerated product qualification test was performed to support a risk assessment of a work-around necessitated by an on-orbit failure of another piece of hardware on the Mars Global Surveyor spacecraft.
This task specified developing the hardware and software necessary to implement the System for Anomaly and Failure Detection (SAFD) algorithm, developed under Technology Test Bed (TTB) Task 21, on the TTB engine stand. This effort involved building two units; one unit to be installed in the Block II Space Shuttle Main Engine (SSME) Hardware Simulation Lab (HSL) at Marshall Space Flight Center (MSFC), and one unit to be installed at the TTB engine stand. Rocketdyne personnel from the HSL performed the task. The SAFD algorithm was developed as an improvement over the current redline system used in the Space Shuttle Main Engine Controller (SSMEC). Simulation tests and execution against previous hot fire tests demonstrated that the SAFD algorithm can detect engine failure as much as tens of seconds before the redline system recognized the failure. Although the current algorithm only operates during steady state conditions (engine not throttling), work is underway to expand the algorithm to work during transient condition.
In the history of humankind, every space adventure, great or small, has begun on the ground. While this seems to be stating the obvious, mission and flight hardware designers who have overlooked this fact have paid a high price, either in loss or damage to the hardware pre-launch, or in mission failure or reduction. Designers may risk not only their flight hardware, but they may also risk their lives, their co-workers lives and even the general public by not heeding safety on the ground. Their eyes may be on the stars but their feet are on the ground! This discussion applies to all forms of flight hardware from the largest rockets to the smallest spare parts.
The results of the Independent Orbiter Assessment (IOA) of the Failure Modes and Effects Analysis (FMEA) and Critical Items List (CIL) are presented. The IOA effort performed an independent analysis of the Extravehicular Mobility Unit (EMU) hardware and system, generating draft failure modes criticalities and potential critical items. To preserve independence, this analysis was accomplished without reliance upon the results contained within the NASA FMEA/CIL documentation. The IOA results were than compared to the most recent proposed Post 51-L NASA FMEA/CIL baseline. A resolution of each discrepancy from the comparison was provided through additional analysis as required. This report documents the results of that comparison for the Orbiter EMU hardware.