SEARCH · Engineering Papers

Results for “ENGINE TROUBLE”

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.

26 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Interview with Jay O'Callahan

Usually stories have elements of risk, trouble, challenge, adventure. These elements are universal because they're part of life. A story gets exciting when someone takes a risk. With risk there's tension and with tension there's energy, and the energy draws us into who the story. NASA's work involves great risk. Sometimes, as with Challenger and Columbia, the result is tragedy. I had a sense the astronauts were invulnerable. They were so well trained, and the engineers behind them were superb. Nothing was going to go wrong. That's one of the reasons the Challenger crew's death moved people so deeply. Christa McAuliffe was not an engineer; she was a teacher and she died, and the whole space enterprise became very human. The Challenger lifted off and in seventy-three seconds the Space Shuttle disintegrated. Seventy-three seconds. That's a day I'll remember, like the day of Kennedy's death. The danger was there, but we were lulled into thinking the space flight was routine. My firm: job would be to talk with MAS people-scientists, engineers, astronauts. I'm sure that underneath the whole NASA enterprise there is a sense of wonder. Perhaps science and myth are coming together in NASA. The myths of old were often stories about the sun, the stars, and the moon. Now with NASA, we're going out there. NASA is turning our eyes heavenward just as the ancients did.

Cohen, Don↗

NASA NTRS2020

What Can We Learn from One Billion Ground System Log Messages?

Shortage of log-based data in a ground system they have traditionally been the under achievers in a satellite ground system. This is due to several factors: Once log messages scroll out of view on the TTC event console window they are soon forgotten. Application and system log files are scattered across directories within a system, across a multitude of servers, and across one or more databases making access cumbersome. Typical tools to perform log file content searching are generally crude and typically only employed as part of trouble-shooting exercises.As we move towards satellite constellations and fleets and add even more status information, the number of messages keeps growing. One mission now estimates that they could generate 3,000,000 messages per day 1 billion per year - for the life of their mission. What to do with those 1 billion messages? That is the challenge. With the recent technological advances in the management of large data sets, text-based processing, and data analytics, there are now capabilities that we can provide to the ground system engineers and satellite operators to address what we postulate are missed opportunities. Advanced real-time log analysis can allow us to be less reactionary in favor of being more proactive. Analytics goals include the ability to: Identify root cause of unexpected events, failures or error conditions enabled by correlating disparate data. Detect security breaches attempts before they are successful. Help admins ensure IT resources continue running optimally. Identify trends and patterns that may indicate impending failures or error conditions for valuable assets before they happen. Compare satellites in a fleet or constellation in terms of number of alarms, number of command sent to them, etc.. Answer questions like "Are the operations support needs increasing over the past year?" or "Have we seen this combination of alarm conditions before?" But really, once the tools are readily available the users will start realizing what can be done with their new powers. In this presentation we will show the results of analyzing millions of actual mission operations log messages, how the results can be displayed to the user, and how new products now available as open source can be applied to the challenges of large scale time-tagged text-based mission operations messages. Flight operations team members believe that this is a powerful new option for how they assess overall system and space asset health. Technical descriptions of the design, tools, and storage will be provided. One billion messages? Bring'em on!

Orsborne, Sharon↗

NASA NTRS1991

Thermal verification testing of commercial printed-circuit boards for spaceflight

A method is discussed developed to verify commercial printed-circuit boards for a shuttle orbital flight. The Space Acceleration Measurement System Project used this method first with great success. The test sequence is based on early fault detection, desire to test the final assembly, and integration with other verification testing. A component thermal screening test is performed first to force flaws in design, workmanship, parts, processes, and materials into observable failures. Then temperature definition tests are performed that consist of infrared scanning, thermal vacuum testing, and preliminary thermal operational testing. Only the engineering unit is used for temperature definition testing, but the preliminary thermal operational testing is performed on the flight unit after the temperature range has been defined. In the sequence of testing, vibration testing is performed next, but most vibration failures cannot be detected without subsequent temperature cycling. Finally, final assembly testing is performed to simulate the shuttle flight. An abbreviated thermal screening test is performed as a check after the vibration test, and then a complete thermal operational test is performed. The final assembly test finishes up with a burn-in of 100 hours of trouble-free operation. Verification is successful when all components and final assemblies have passed each test satisfactory. This method was very successful in verifying that commercial printed-circuit boards will survive in the shuttle environment.

Foster, William M., II↗

NASA NTRS1985

Development of an Expert System for Representing Procedural Knowledge

A high level of automation is of paramount importance in most space operations. It is critical for unmanned missions and greatly increases the effectiveness of manned missions. However, although many functions can be automated by using advanced engineering techniques, others require complex reasoning, sensing, and manipulatory capabilities that go beyond this technology. Automation of fault diagnosis and malfunction handling is a case in point. The military have long been interested in this problem, and have developed automatic test equipment to aid in the maintenance of complex military hardware. These systems are all based on conventional software and engineering techniques. However, the effectiveness of such test equipment is severely limited. The equipment is inflexible and unresponsive to the skill level of the technicians using it. The diagnostic procedures cannot be matched to the exigencies of the current situation nor can they cope with reconfiguration or modification of the items under test. The diagnosis cannot be guided by useful advice from technicians and, when a fault cannot be isolated, no explanation is given as to the cause of failure. Because these systems perform a prescribed sequence of tests, they cannot utilize knowledge of a particular situation to focus attention on more likely trouble spots. Consequently, real-time performance is highly unsatisfactory. Furthermore, the cost of developing test software is substantial and time to maturation is excessive. Significant advances in artificial intelligence (AI) have recently led to the development of powerful and flexible reasoning systems, known as expert or knowledge-based systems. We have devised a powerful and theoretically sound scheme for representing and reasoning about procedural knowledge.

Georgeff, Michael P.↗

NASA NTRS2006

The X-43 Fin Actuation System Problem - Reliability in Shades of Gray

Following the loss of the first X-43 during launch, the mishap investigation board indicated the Fin Actuator System (FAS) needed to have a larger torque margin. To supply this added torque, a second actuator was added. The consequences of what seemed to be a simple modification would trouble the X-43 program. Because of the second actuator, a new computer board was required. This proved to be subject to electronic noise. This resulted in the actuator latch up in ground tests of the FAS for the second launch. Such a latch up would cause the Pegasus booster to fail, as the FAS was a single string system. The problem was corrected and the second flight was successful. The same modifications were added to the FAS for flight three. When the FAS underwent ground tests, it also latched up. The failure indicated that each computer board had a different tolerance to electronic noise. The problem with the FAS was corrected. Subsequently, another failure occurred, raising questions about the design, and the probability of failure for the X-43 Mach 10 flight. This was not simply a technical issue, but illuminated the difficulties facing both managers and engineers in assessing risk, design requirements, and probabilities in cutting edge aerospace projects.

Peebles, Curtis↗

NASA NTRS1946

Altitude-Wind-Tunnel Investigation of Oil-System Performance of XR-4360-8 Engine in XTB2D-1 Airplane

An investigation was conducted in the Cleveland altitude wind tunnel to determine the aerodynamic characteristics and the oil delivery critical altitude of the oil-cooler installation of an XTB2D-1 airplane. The investigation was made with the propeller removed end with the engine operating at 1800 brake horsepower, an altitude of 15,000 feet (except for tests of oil-delivery critical altitude), oil-cooler flap deflections from -20 degrees to 20 degrees and inclinations of the thrust axis of 0 degrees, 1.5 degrees, and 6 degrees. At an inclination of the thrust axis of 0 degrees and with the propeller operating, the total-pressure recovery coefficient at the face of the oil cooler varied from 0.84 to 1.10 depending on the flap deflection. With the propeller removed, the best pressure recovery at the face of the oil cooler was obtained at an inclination of the thrust axis of 1.5 degrees. Air-flow separation occurred on the inner surface of the upper lip of the oil-cooler duct inlet at an inclination of the thrust axis of 0 degrees and on the inner surface of the lower lip at 6 degrees. Static pressure coefficients over the duct lips were sufficiently low that no trouble from compressibility would be encountered in level flight. The oil-delivery critical altitude at cruising power (2230 rpm, 1675 bhp) was approximately 18,500 feet for the oil system tested.

Conrad, E. William↗

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 NTRSDate not supplied

Application of OpenFOAM to Plume Impingement in Space Environments

After 30 years of continuous human presence in low-earth orbit, NASA is returning to the moon and eventually will go to Mars. Travelling beyond low earth orbit requires NASA to learn how humans can live in Deep Space environments – beyond the protection of Earth’s magnetosphere and at distances from Earth that prevent a quick return in case of trouble. To this end, NASA is constructing the Lunar Gateway, an ISS-like space station to be put in orbit around the moon to act as a home base for Lunar exploration for NASA astronauts. The Gateway Lunar outpost will be built incrementally, via modules which will arrive at separate times and dock to the existing structure. The incremental addition of Gateway modules, and the docking of visiting vehicles, is achieved via a sequence of firings from the approaching body’s onboard reaction control system (RCS) thrusters to achieve the required approach trajectory. The typical hypergolic chemical RCS thrusters work by firing hot gases to produce adverse thrust and the needed change in velocity to safely finish the docking process. The exhaust gas from the RCS thrusters form plumes that expand into the vacuum of space and can impinge onto the outer surfaces of the Lunar Gateway, causing unwanted forces and moments, heat loads, sediment deposition, and in extreme cases, even surface erosion - all mechanisms that can damage the Lunar Gateway and must be minimized. Both permanent and visiting modules will have this RCS thruster exhaust impingement problem. This research aims to establish existing OpenFOAM solvers as a methodology for improving simulation techniques of rocket exhaust plume impingement in space environments. The flow structure of a plume in a space environment is complex; a plume that originates from a hypergolic chemical RCS thruster and expands into a vacuum will experience several regimes of rarefication. This range includes the continuum flow in the rocket nozzle through the fully rarefied free molecular flow further from the nozzle. The flow physics is different at these two extremes, and as such, the simulation approach for plumes is generally divided into a traditional computational fluid dynamics (CFD) simulation in and near the nozzle which is coupled to a subsequent direct simulation Monte Carlo (DSMC) simulation. At this time, the scope of this research is developing, verifying, and validating a method using existing solvers in the OpenFOAM framework for performing coupled CFD/DSMC calculations to determine the extent of plume impingement loading on generic space structures. This presentation will detail code-to-code comparisons between the hyStrath dsmcFoam+ solver, developed using OpenFOAM and available as open-source, and NASA’s in-house DSMC Analysis Code (DAC). Comparisons to several open-source publication findings using DAC [3,4] are presented, and advantages of using an OpenFOAM based solver are also discussed. The presentation concludes with a discussion of future work, and a plan for coupling the dsmcFoam+ solver with CFD simulations of chemical rocket engines for unified coupled plume simulation.

DSMC↗