Search NASA⌕ Search

SEARCH · Search NASA

Results for “Crack propagation”

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.

57 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

Chapter 19B - Antenna Radiation Patterns

Modern civil and military aircraft are equipped with a variety of communication devices, radio navigation equipment, and air traffic control systems. For all of these devices appropriate antennas must be available to transmit and receive the signals. As a result, as many as 30 antennas, and sometimes even more, are mounted around today's aircraft. For this reason, it is necessary to know the capabilities of the receiving/transmitting equipment on board. These capabilities are driven by the antenna characteristics. Therefore, coverage, shading, and beam pointing pattern data are necessary for optimum electronic coverage. The aircraft antenna has to convert the available power density of the electromagnetic field to an electric voltage at its connector. This voltage level must be sufficiently high to operate the connected equipment. The reciprocity principle states that it makes no difference if the antenna is receiving or transmitting. For the certification of the aircraft antennas it must be proven that the antennas are at least generating the minimum receiver input voltage which is required for each radio service. The prime condition is, of course, that the specified field power densities of the different radio navigation and communication services are available. An important property of a radio frequency link is the electro-magnetic field intensity at every point in space for a given output power of the antenna. As the propagation of radio frequency waves in free space is well known, the spatial distribution of the field intensity needs only be measured at one spatial sphere around the antenna. The information is usually given as distributions along the circumference of flat sections through this sphere: each of these is called an ARP. Several ARPs are usually required to describe the complete spatial antenna pattern of an antenna. In addition to mathematical modeling, measurements on sub-scale models, and static measurements on full size models or aircraft on the ground, dynamic measurements on aircraft in flight play the most important role in the aircraft antenna testing and certification. [19B-1] The shape of an ARP, for one given frequency, is determined by the shape of the antenna and the shape and material of the surface it is mounted on. As the directly transmitted waves interfere with waves reflected by the aircraft skin with its complex geometry, and the surface material parameters are only roughly known, it is not possible to predict the ARP with the required accuracy. In ground measurements the earth's surface also acts as a reflector thereby causing the ground ARP to be different from the in-flight ARP. As the in-flight ARP is the ARP we are actually interested in it becomes clear that it is necessary to conduct in-flight ARP measurements. The Flight Test Engineer must be aware of the needs of the specialists who are establishing the test program for measuring antenna patterns and radar cross sections. These tests will require special test equipment and dedicated flights to obtain the data that they require. This Section provides an introduction to the principles of determining antenna patterns and the flight techniques for determining both antenna patterns and radar cross section. Reference 19B-1 provides detailed information.

Helmut Bothe↗
NASA NTRSDate not supplied

Trajectory Engineering with Modular Patched Conics for Entry Systems and TPS (TEMPEST)

Brief Presenter Biography (35 word limit): Bohdan Wesely is an Aerospace Engineer in the Entry Systems and Technology Division at Ames. He has worked on a variety of projects for NASA including integrated TPS (thermal protection system) flight hardware deliveries and testing services for commercial partners. Introduction: TEMPEST is a new trajectory analysis framework that is designed to fill the gap between dedicated flight mechanics tools and aerothermal and TPS sizing tools. The project started as an SJSU master’s thesis and has since evolved into a general conceptual design tool capable of studying a wide variety of entry problems. Development is ongoing in the Entry Systems and Technology Division at NASA ARC. Why TEMPEST: Space missions involving entry into a planetary atmosphere involve a series of unique requirements across multiple disciplines. Whether it is traditional entry descent and landing (EDL), or aerocapture, the vehicle must navigate to its target landing location or orbit state, and the TPS must protect the payload during entry. The design process typically involves iterative handoffs between various flight mechanics, flow solver, and material response level tools. During the early conceptual phase, a wide variety of feasible trajectories are simulated in a Monte Carlo scenario which broadly satisfy the mission or landing requirements. Next, computational fluid dynamics (CFD), direct simulation Monte Carlo (DSMC), and other flow solver analyses are performed at various key trajectory points to generate an aero-database, heating and TPS design requirements also emerge at this stage. At this point, with updated aerodynamics from the various flow solvers, trajectories can be re-run, this in turn can change the required freestream conditions for the CFD tools, and as a project progresses, these analyses converge, and uncertainty is reduced. However, there is always a “hand-off” occurring between two inherently coupled phenomena. Analysis Description: One of the goals with TEMPEST is to use a variety of first principles estimation methods coupled with an atmosphere model to predict vehicle aerothermodynamics across the entire flight regime while propagating a 3 or 6 degree of freedom (DoF) trajectory. Aerodynamics methods include modified Newtonian, Maxwell and Cercignani- Lampis-Lord (CLL) for continuum, transitional, and free molecular flow regimes. Aerothermodynamics include boundary layer and reference enthalpy methods, and Mutation++ for non-equilibrium chemistry modeling. TEMPEST is also capable of stitching multiple trajectory segments together to study mission scenarios like multi-pass aerocapture and aero-gravity assists. Most of the program is implemented in MATLAB using modern system objects, it relies on several C++ shared libraries for supporting tools like Gmsh, the Global Reference Atmospheric Model (GRAM), and Mutation++. The various first principles aerothermal estimation methods are discretized across either a structured axisymmetric panel mesh or an unstructured tri-mesh generated from an open-source tool such as Gmsh, this allows solutions on the same mesh to be compared across tools such as CB-Aero. CFD Coupling. A physics-aware, gaussian process CFD anchoring scheme is proposed to adjust the various first principles methods as a CFD database is populated. One goal for this anchoring module is to inform the project where CFD should be run. Full knowledge of the entire trajectory, atmosphere, and aerothermodynamics allows for easier identification of high sensitivity areas and uncertainty quantification. While the first principles effects are well known and proven accurate in existing tools such as CB- Aero and Cart3D, a physics aware CFD anchoring scheme increases tool credibility across a project lifecycle. Material Response Modeling. Correct TPS sizing is critical for optimizing mass for science payloads and ensuring mission success. The process typically involves a thermal analysis along the trajectory with surface heating environments as a boundary condition. Several design constraints are maximum bondline temperature and maximum recession with various margining techniques. The material response tool FIAT, developed out of NASA Ames, is currently being integrated into the TEMPEST environment. TPS recession, shape change, mass loss, and mass property alteration are all factors that can perturb an entry trajectory. For missions like Mars 2020, recession was minimal and was safely handled separately as a post process. For missions such as Jupiter Galileo with a high TPS mass fraction or asteroid entries, recession plays a major role. The proposed fully coupled scheme is to use an epoch-based approach where the trajectory integration is halted after a recession threshold, the energy balance and FIAT are solved at each panel, the mesh, aerodynamics, and mass properties are updated, and the trajectory continues. Several computational tradeoffs have been made during the development of TEMPEST to limit the cost of a single trajectory and preserve its utility as a conceptual, rapid iteration tool. Conclusion: Development of TEMPEST is ongoing and the project is still in its infancy. This talk aims to showcase its unique capabilities to support future NASA entry systems missions.

Bohdan O Wesely↗
NASA NTRS2010

Ares I-X Ground Diagnostic Prototype

Automating prelaunch diagnostics for launch vehicles offers three potential benefits. First, it potentially improves safety by detecting faults that might otherwise have been missed so that they can be corrected before launch. Second, it potentially reduces launch delays by more quickly diagnosing the cause of anomalies that occur during prelaunch processing. Reducing launch delays will be critical to the success of NASA's planned future missions that require in-orbit rendezvous. Third, it potentially reduces costs by reducing both launch delays and the number of people needed to monitor the prelaunch process. NASA is currently developing the Ares I launch vehicle to bring the Orion capsule and its crew of four astronauts to low-earth orbit on their way to the moon. Ares I-X will be the first unmanned test flight of Ares I. It is scheduled to launch on October 27, 2009. The Ares I-X Ground Diagnostic Prototype is a prototype ground diagnostic system that will provide anomaly detection, fault detection, fault isolation, and diagnostics for the Ares I-X first-stage thrust vector control (TVC) and for the associated ground hydraulics while it is in the Vehicle Assembly Building (VAB) at John F. Kennedy Space Center (KSC) and on the launch pad. It will serve as a prototype for a future operational ground diagnostic system for Ares I. The prototype combines three existing diagnostic tools. The first tool, TEAMS (Testability Engineering and Maintenance System), is a model-based tool that is commercially produced by Qualtech Systems, Inc. It uses a qualitative model of failure propagation to perform fault isolation and diagnostics. We adapted an existing TEAMS model of the TVC to use for diagnostics and developed a TEAMS model of the ground hydraulics. The second tool, Spacecraft Health Inference Engine (SHINE), is a rule-based expert system developed at the NASA Jet Propulsion Laboratory. We developed SHINE rules for fault detection and mode identification. The prototype uses the outputs of SHINE as inputs to TEAMS. The third tool, the Inductive Monitoring System (IMS), is an anomaly detection tool developed at NASA Ames Research Center and is currently used to monitor the International Space Station Control Moment Gyroscopes. IMS automatically "learns" a model of historical nominal data in the form of a set of clusters and signals an alarm when new data fails to match this model. IMS offers the potential to detect faults that have not been modeled. The three tools have been integrated and deployed to Hangar AE at KSC where they interface with live data from the Ares I-X vehicle and from the ground hydraulics. The outputs of the tools are displayed on a console in Hangar AE, one of the locations from which the Ares I-X launch will be monitored. In a previous publication, we discussed how we selected the three tools based primarily on their ability to be certified for human spaceflight and described our plans for the prototype. This abstract is due October 23, 2009, and the Ares I-X launch is currently scheduled for October 27, 2009. If this abstract is accepted, then the full paper will describe how the prototype performed before the launch. It will include an analysis of the prototype's accuracy, including false-positive rates, false-negative rates, and receiver operating characteristics (ROC) curves. It will also include a description of the prototype's computational requirements, including CPU usage, main memory usage, and disk usage. If the prototype detects any faults during the prelaunch period then the paper will include a description of those faults. Similarly, if the prototype has any false alarms then the paper will describe them and will attempt to explain their causes. Also, the paper will describe the three tools and how they are used in the prototype. It will include a description of the TEAMS models of the Ares I-X first-stage TVC and associated ground hydraulics and how we adapted the TVC model for use in real-time diagnostics. It will describe the SHINE rules used for fault detection and mode identification and the software architecture that interfaces the various pieces of existing software that are part of the prototype to one another. It will describe how we selected the sensor values and commands that were used to train the IMS model and how we optimized the number of clusters in the IMS model. It will include screen shots of the graphical display that we developed in Java to display the outputs of the three tools. Because Ares I-X data was not yet available to us while we were developing the prototype, we used historical data from the Space Shuttle's Solid Rocket Booster (SRB) TVCs and the associated ground hydraulics to train IMS and to test the entire prototype. Because most of the failure modes that we modeled have never occurred in the Shuttle we inserted simulated failures into the Shuttle data. The Ares I-X first-stage TVC is very similar to the SRB TVC and we expect the data will be very similar. After the launch, we will determine how similar the data actually is and report how any differences in the data affected the diagnostic accuracy of the prototype. Finally, although we did not get the prototype certified, we designed it in a way that it could be certified and wrote a preliminary certification plan. The paper will include a brief summary of how we considered the need for certification in the design of the prototype, how we tested the prototype before deploying it to Hangar AE, and how we would propose to get it certified if it were deployed as an operational system. The paper will conclude with a description of some of the challenges we faced and some of the lessons learned in developing and deploying the prototype.

International Space Station↗