Search NASA⌕ Search

SEARCH · Search NASA

Results for “Astronautics”

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.

39 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2026

Moon Base Transportation - Deliveries to the Lunar Surface

Development of the Moon Base will enable a home away from home for astronauts who will live and work at humanity’s first lunar outpost. In this effort, NASA’s Moon Transportation Office is responsible for enabling the transformational missions required to deliver habitats, supplies, science payloads, and all other elements needed to cultivate a permanent presence on the Lunar Surface. The Mission Concept (MC) is characterized through evaluation of an end-to-end architecture that can successfully deliver a generalized heavy large-volume payload, in excess of 4000 kg, to a precision landing and touchdown on the lunar surface. The mission architecture utilizes a single launch configuration of a Lunar Lander (LL) with a unique propellant system. The LL has an integral orbital transfer capability and features jettisonable elements. The design circumvents the need for prop transfer on orbit and multiple launch configurations. The launch vehicle (LV) for this work will assume the capability to deliver a payload in excess of 40,000 kg to orbit, affording multiple LV solutions. Considerations for the LL and payload deployment from the fairing are assumed to be handled through compliance with a launch providers’ Interface Requirements Document (IRD). The MC will span from launch at Kennedy Space Center (KSC) to terminal descent and touchdown on the lunar surface, requiring a total ΔV on the order of 6 km/s beyond what is required to get the vehicle stack to a 200 km circular Low Earth Orbit (LEO). Major mission phases include: launch and launch vehicle separation, transfer operations, pre-landing navigation, and lunar descent and touchdown. A Concept of Operations (ConOps) is used as the primary design driver for defining architecture of the vehicles necessary to achieve final payload delivery. Numerous ground rules and assumptions will be provided for each phase of the mission. Concept designs for the LL is presented. An emphasis of the design maximizes a feasible path for maturation, manufacturing, and operation. A self-imposed practical consideration for this effort is the incorporation of legacy designed hardware to minimize expensive, time-intensive, and high-risk hardware development cycles. The propulsion system of the LL adopts a conventional storable bipropellant configuration of monomethyl hydrazine (MMH) and mixed oxides of nitrogen (MON3). This effort will showcase a unique propellant delivery system to minimize the reliance on propellant management devices (PMDs) during descent. Numerous key constraints have been considered, across the multiple segments of the mission. These include the unique aspects of center of gravity (CG) management, thruster plume effects including self-impingement, propulsion system hardware limitations, navigation during multiple mission phases, and landing gear geometry for uneven terrain. These constraints shape the trades necessary for precision landing of heavy cargo and ensure compatibility with broader Moon Base Transportation concepts. The resulting insights inform future transportation strategies for the Moon and beyond; directly contributing to the development of cargo‑delivery standards that will support the long‑term buildup of a sustainable, continuously inhabited Moon Base.

Lunar Habitat↗
NASA NTRS2009

General Purpose Data-Driven Monitoring for Space Operations

As modern space propulsion and exploration systems improve in capability and efficiency, their designs are becoming increasingly sophisticated and complex. Determining the health state of these systems, using traditional parameter limit checking, model-based, or rule-based methods, is becoming more difficult as the number of sensors and component interactions grow. Data-driven monitoring techniques have been developed to address these issues by analyzing system operations data to automatically characterize normal system behavior. System health can be monitored by comparing real-time operating data with these nominal characterizations, providing detection of anomalous data signatures indicative of system faults or failures. Data-driven techniques have a number of advantages over other methods for monitoring complex space vehicles. Unlike model-based systems, the developer does not need to understand or encode the internal operation of the system. The knowledge required to monitor the system is automatically derived from archived data from system operation. Unlike rule-based systems, data-driven systems do not require system analysts to define nominal relationships among sensors. Analysts can and often do determine these relationships for a system with few sensors; it is more difficult to analytically determine the nominal relationship among a large number of sensors. Data-driven techniques are not limited to low-dimensional spaces and work as effectively with dozens of parameters as they do with a few. Knowledge bases formed by data-driven techniques are also easy to update. As the operating envelope of the monitored system is expanded, data-driven techniques can be quickly retrained to incorporate the new behavior into the knowledge base. The expertise and time-consuming process of updating a model or rule base to maintain consistency with the new operation is not required. The Inductive Monitoring System (IMS) is a data-driven system health monitoring software tool that has been successfully applied to several aerospace applications. IMS uses a data mining technique called clustering to analyze archived system data and characterize normal interactions between parameters. This characterization, or model, of nominal operation is stored in a knowledge base that can be used for real-time system monitoring or analysis of archived events. System data is compared with the nominal IMS model to produce a measure of how well current system behavior matches the normal behavior defined by the training data. Significant deviations from the nominal system model can provide alerts to system malfunctions or precursors of significant failures. The scope of IMS based data-driven monitoring applications continues to expand with current development activities. Successful IMS deployment in the International Space Station (ISS) flight control room to monitor ISS attitude control systems has led to applications in other ISS flight control disciplines, such as thermal control. It has also generated interest in data-driven monitoring capability for Constellation, NASA's program to replace the Space Shuttle with new launch vehicles and spacecraft capable of returning astronauts to the moon, and then on to Mars. Several projects are currently underway to evaluate and mature the IMS technology and complementary tools for use in the Constellation program. These include an experiment on board the Air Force TacSat-3 satellite, and ground systems monitoring for NASA's Ares I-X and Ares I launch vehicles. The TacSat-3 Vehicle System Management (TVSM) project is a software experiment to integrate fault and anomaly detection algorithms and diagnosis tools with executive and adaptive planning functions contained in the flight software on-board the Air Force Research Laboratory TacSat-3 satellite. The TVSM software package will be uploaded after launch to monitor spacecraft subsystems such as power and guidance, navigation, and control (GN&C). It will analyze data in real-time to demonstrate detection of faults and unusual conditions, diagnose problems, and react to threats to spacecraft health and mission goals. The experiment will demonstrate the feasibility and effectiveness of integrated system health management (ISHM) technologies with both ground and on-board experiments. Initially, the TVSM software will run open loop, providing system health information and recommendations to ground operators, without automatically performing fault-mitigating corrective actions. After the end of the satellite's mission, closed loop tests combining TVSM monitoring and diagnosis with reactive capabilities by the flight software will be performed. In addition to monitoring for long periods of actual operation, the experiment will include fault injection into TacSat-3 data as well as commanded operations to test and evaluate automatic ISHM monitoring and recovery under controlled conditions.

Satellites↗
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↗