Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Agile Development”

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.

277 records · Page 16

NASA-UVA Light Aerospace Alloy and Structures Technology Program (LA2ST)

This report documents the progress achieved over the past 6 to 12 months on four graduate student projects conducted within the NASA-UVA Light Aerospace Alloy and Structures Technology Program. These studies were aimed specifically at light metallic alloy issues relevant to the High Speed Civil Transport. Research on Hydrogen-Enhanced Fracture of High-Strength Titanium Alloy Sheet refined successfully the high resolution R-curve method necessary to characterize initiation and growth fracture toughnesses. For solution treated and aged Low Cost Beta without hydrogen precharging, fracture is by ductile transgranular processes at 25 C, but standardized initiation toughnesses are somewhat low and crack extension is resolved at still lower K-levels. This fracture resistance is degraded substantially, by between 700 and 1000 wppm of dissolved hydrogen, and a fracture mode change is affected. The surface oxide on P-titanium alloys hinders hydrogen uptake and complicates the electrochemical introduction of low hydrogen concentrations that are critical to applications of these alloys. Ti-15-3 sheet was obtained for study during the next reporting period. Research on Mechanisms of deformation and Fracture in High-Strength Titanium Alloys is examining the microstructure and fatigue resistance of very thin sheet. Aging experiments on 0. 14 mm thick (0.0055 inch) foil show microstructural agility that may be used to enhance fatigue performance. Fatigue testing of Ti-15-3 sheet has begun. The effects of various thermo-mechanical processing regimens on mechanical properties will be examined and deformation modes identified. Research on the Effect of Texture and Precipitates on Mechanical Property Anisotropy of Al-Cu-Mg-X and Al-Cu alloys demonstrated that models predict a minor influence of stress-induced alignment of Phi, caused by the application of a tensile stress during aging, on the yield stress anisotropy of both modified AA2519 and a model Al-Cu binary alloy. This project is no longer included in the NASA-UVA LAST program. Research on the Creep Behavior and Microstructural stability of Al-Cu-Mg-Ag and Al-Cu-Li-Mg-Ag showed that the creep resistance of three candidate aluminum alloys (C415, C416 and ML377) was much superior compared to that of the current Concorde alloy, AA2618. Creep induced change in precipitates at grain boundaries was observed in the alloy which exhibits the highest creep strain of the three examined. The other two alloys developed no detectable microstructural changes at grain boundaries under the creep conditions tested.

Gangloff, Richard P.↗

High-Performance Satellite/Terrestrial-Network Gateway

A gateway has been developed to enable digital communication between (1) the high-rate receiving equipment at NASA's White Sands complex and (2) a standard terrestrial digital communication network at data rates up to 622 Mb/s. The design of this gateway can also be adapted for use in commercial Earth/satellite and digital communication networks, and in terrestrial digital communication networks that include wireless subnetworks. Gateway as used here signifies an electronic circuit that serves as an interface between two electronic communication networks so that a computer (or other terminal) on one network can communicate with a terminal on the other network. The connection between this gateway and the high-rate receiving equipment is made via a synchronous serial data interface at the emitter-coupled-logic (ECL) level. The connection between this gateway and a standard asynchronous transfer mode (ATM) terrestrial communication network is made via a standard user network interface with a synchronous optical network (SONET) connector. The gateway contains circuitry that performs the conversion between the ECL and SONET interfaces. The data rate of the SONET interface can be either 155.52 or 622.08 Mb/s. The gateway derives its clock signal from a satellite modem in the high-rate receiving equipment and, hence, is agile in the sense that it adapts to the data rate of the serial interface.

Beering, David R.↗

VCO PLL Frequency Synthesizers for Spacecraft Transponders

Two documents discuss a breadboard version of advanced transponders that, when fully developed, would be installed on future spacecraft to fly in deep space. These transponders will be required to be capable of operation on any deepspace- communications uplink frequency channel between 7,145 and 7,235 MHz, and any downlink frequency channel between 8,400 and 8,500 MHz. The document focuses on the design and operation of frequency synthesizers for the receiver and transmitter. Heretofore, frequency synthesizers in deep-space transponders have been based on dielectric resonator oscillators (DROs), which do not have the wide tuning bandwidth necessary to tune over all channels in the uplink or downlink frequency bands. To satisfy the requirement for tuning bandwidth, the present frequency synthesizers are based on voltage-controlled-oscillator (VCO) phase-locked loops (PLLs) implemented by use of monolithic microwave integrated circuits (MMICs) implemented using inGaP heterojunction bipolar transistor (HBT) technology. MMIC VCO PLL frequency synthesizers similar to the present ones have been used in commercial and military applications but, until now, have exhibited too much phase noise for use in deep-space transponders. The present frequency synthesizers contain advanced MMIC VCOs, which use HBT technology and have lower levels of flicker (1/f) phase noise. When these MMIC VCOs are used with high-speed MMIC frequency dividers, it becomes possible to obtain the required combination of frequency agility and low phase noise.

Smith, Scott↗

SERENE: Saturn Enceladus Return Explorer with Nuclear Electric Propulsion

A ‘quick’ Enceladus sample return mission concept was developed based on the scientist recommendations at the recent ‘Accelerating Space Science with Nuclear Technology Workshop’. The Nuclear Electric Propulsion spacecraft assumed a follow-on 40 kWe nuclear reactor using the demonstrated 40 kWe Fission Surface Power system, expected in the early 2030s. The NEP vehicle also utilized a set of NEXT-C ion thrusters as well as planned Artemis commercial launchers. By launching the 40 kW NEP vehicle on a Starship and adding the propellants of 15 tankers, the 27t probe could be sent on a direct trajectory to Saturn (no Earth or Jupiter flybys) where NEP was used for Saturn capture, spiral down, spiral up and return to the Earth. A small lander obtained the surface Enceladus sample. Using the 40 kW NEP provided a round-trip time of only 16.5 years. A second option was more attractive from a science perspective whereby the NEP vehicle would deliver a large, 6t chemical lander to low Enceladus orbit where it would grab and return a sample to Earth (similar to the recent Orbilander design but in reverse). After deploying the lander, the NEP vehicle would stay in Saturn space performing a moon tour by orbiting four more moons and mapping the large moon of Titan. This option took slightly longer (18.5 yrs) due to the chemical return leg limitations. Both options demonstrated the agility, payload capability, and sample return goals the workshop recommended. An all-chemical option with two stages was roughly analyzed but took 21.5 yrs and required a Jupiter gravity assist.

Nuclear Electric Propulsion↗

Jitter Controller Software

Sinusoidal jitter is produced by simply modulating a clock frequency sinusoidally with a given frequency and amplitude. But this can be expressed as phase jitter, frequency jitter, or cycle-to-cycle jitter, rms or peak, absolute units, or normalized to the base clock frequency. Jitter using other waveforms requires calculating and downloading these waveforms to an arbitrary waveform generator, and helping the user manage relationships among phase jitter crest factor, frequency jitter crest factor, and cycle-to-cycle jitter (CCJ) crest factor. Software was developed for managing these relationships, automatically configuring the generator, and saving test results documentation. Tighter management of clock jitter and jitter sensitivity is required by new codes that further extend the already high performance of space communication links, completely correcting symbol error rates higher than 10 percent, and therefore typically requiring demodulation and symbol synchronization hardware to operating at signal-to-noise ratios of less than one. To accomplish this, greater demands are also made on transmitter performance, and measurement techniques are needed to confirm performance. It was discovered early that sinusoidal jitter can be stepped on a grid such that one can connect points by constant phase jitter, constant frequency jitter, or constant cycle-cycle jitter. The tool automates adherence to a grid while also allowing adjustments off-grid. Also, the jitter can be set by the user on any dimension and the others are calculated. The calculations are all recorded, allowing the data to be rapidly plotted or re-plotted against different interpretations just by changing pointers to columns. A key advantage is taking data on a carefully controlled grid, which allowed a single data set to be post-analyzed many different ways. Another innovation was building a software tool to provide very tight coupling between the generator and the recorded data product, and the operator's worksheet. Together, these allowed the operator to sweep the jitter stimulus quickly along any of three dimensions and focus on the response of the system under test (response was jitter transfer ratio, or performance degradation to the symbol or codeword error rate). Additionally, managing multi-tone and noise waveforms automated a tedious manual process, and provided almost instantaneous decision- making control over test flow. The code was written in LabVIEW, and calls Agilent instrument drivers to write to the generator hardware.

Lansdowne, Chatwin↗

Experiences with Testing the Largest Ground System NASA Has Ever Built

In the 1980s, the National Aeronautics and Space Administration (NASA) embarked upon a major Earth-focused program called Mission to Planet Earth. The Goddard Space Flight Center (GSFC) was selected to manage and develop a key component - the Earth Observing System (EOS). The EOS consisted of four major missions designed to monitor the Earth. The missions included 4 spacecraft. Terra (launched December 1999), Aqua (launched May 2002), ICESat (Ice, Cloud, and Land Elevation Satellite, launched January 2003), and Aura (scheduled for launch January 2004). The purpose of these missions was to provide support for NASA s long-term research effort for determining how human-induced and natural changes affect our global environment. The EOS Data and Information System (EOSDIS), a globally distributed, large-scale scientific system, was built to support EOS. Its primary function is to capture, collect, process, and distribute the most voluminous set of remotely sensed scientific data to date estimated to be 350 Gbytes per day. The EOSDIS is composed of a diverse set of elements with functional capabilities that require the implementation of a complex set of computers, high-speed networks, mission-unique equipment, and associated Information Technology (IT) software along with mission-specific software. All missions are constrained by schedule, budget, and staffing resources, and rigorous testing has been shown to be critical to the success of each mission. This paper addresses the challenges associated with the planning, test definition. resource scheduling, execution, and discrepancy reporting involved in the mission readiness testing of a ground system on the scale of EOSDIS. The size and complexity of the mission systems supporting the Aqua flight operations, for example, combined with the limited resources available, prompted the project to challenge the prevailing testing culture. The resulting success of the Aqua Mission Readiness Testing (MRT) program was due in no small measure to re-structuring the traditional programmatic and technical approach to a more efficient and robust program. Programmatically, it meant gaining the endorsement, commitment, and cooperation of the numerous subsystem element managers and other stakeholder organizations. Technically, it required an MRT program that was agile, could rapidly adapt to requirements changes, and was flexible in its overall approach. Furthermore, this paper addresses the following questions: 1. What are the key ingredients (e.g., test tools, organization) needed to conduct a successful MRT program? 2. What distinguishes EOS MRT from the traditional system testing approach? 3. Where should the focus of testing be since it is infeasible to test every element or subsystem? 4. How can MRT be applied effectively to other systems or missions? To provide answers to these questions, this paper relies heavily on real-life, hands-on experiences ("lessons learned") gained during mission readiness testing of the Terra ground system and, most recently, the Aqua and ICESat missions. Moreover, this paper explores how lessons learned were turned into lessons applied for the upcoming Aura mission. Although derived from the EOS missions, MRT techniques and strategies can be applied to enhance the testing of other missions.

Lehtonen, Ken↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗