Position Paper for WIFT98
Explore the source record for details and available documents.
SEARCH · Search NASA
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.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
The Phoenix Mars Scout Lander will launch in August 2007 and land on the northern plains of Mars in May of 2008. In a departure from traditional planetary surface mission operations, it will have no direct-to-Earth communications capability and will rely entirely on Mars-orbiting relays in order to facilitate command and control as well as the return of science and engineering data. The Mars Exploration Rover missions have demonstrated the robust data-return capability using this architecture, and also have demonstrated the capability of using this method for command and control. The Phoenix mission will take the next step and incorporate this as the sole communications link. Operations for 90 Sols will need to work within the constraints of Odyssey and Mars Reconnaissance Orbiter communications availability, anomalies must be diagnosed and responded to through an intermediary and on-board fault responses must be tolerant to loss of a relay. These and other issues pose interesting challenges and changes in paradigm for traditional space operations and spacecraft architecture, and the approach proposed for the Phoenix mission is detailed herein.
In this paper we describe the software that has driven these rovers more than a combined 11,000 meters over the Martian surface, including its design and implementation, and summarize current mobility performance results from Mars.
This paper describes experience using Obstacle Analysis to identify contingency requirements on an unpiloted aerial vehicle. A contingency is an operational anomaly, and may or may not involve component failure. The challenges to this effort were: ( I ) rapid evolution of the system while operational, (2) incremental autonomy as capabilities were transferred from ground control to software control and (3) the eventual safety-criticality of such systems as they begin to fly over populated areas. The results reported here are preliminary but show that Obstacle Analysis helped (1) identify new contingencies that appeared as autonomy increased; (2) identify new alternatives for handling both previously known and new contingencies; and (3) investigate the continued validity of existing software requirements for contingency handling. Since many mobile, intelligent systems are built using a development process that poses the same challenges, the results appear to have applicability to other similar systems.
This slide presentation reviews some of the issues concerning verification and validation testing of autonomous spacecraft routinely culminates in the exploration of anomalous or faulted mission-like scenarios using the work involved during the Dawn mission's tests as examples. Prioritizing which scenarios to develop usually comes down to focusing on the most vulnerable areas and ensuring the best return on investment of test time. Rules-of-thumb strategies often come into play, such as injecting applicable anomalies prior to, during, and after system state changes; or, creating cases that ensure good safety-net algorithm coverage. Although experience and judgment in test selection can lead to high levels of confidence about the majority of a system's autonomy, it's likely that important test cases are overlooked. One method to fill in potential test coverage gaps is to automatically generate and execute test cases using algorithms that ensure desirable properties about the coverage. For example, generate cases for all possible fault monitors, and across all state change boundaries. Of course, the scope of coverage is determined by the test environment capabilities, where a faster-than-real-time, high-fidelity, software-only simulation would allow the broadest coverage. Even real-time systems that can be replicated and run in parallel, and that have reliable set-up and operations features provide an excellent resource for automated testing. Making detailed predictions for the outcome of such tests can be difficult, and when algorithmic means are employed to produce hundreds or even thousands of cases, generating predicts individually is impractical, and generating predicts with tools requires executable models of the design and environment that themselves require a complete test program. Therefore, evaluating the results of large number of mission scenario tests poses special challenges. A good approach to address this problem is to automatically score the results based on a range of metrics. Although the specific means of scoring depends highly on the application, the use of formal scoring - metrics has high value in identifying and prioritizing anomalies, and in presenting an overall picture of the state of the test program. In this paper we present a case study based on automatic generation and assessment of faulted test runs for the Dawn mission, and discuss its role in optimizing the allocation of resources for completing the test program.
Topics covered include: Miniature Intelligent Sensor Module; "Smart" Sensor Module; Portable Apparatus for Electrochemical Sensing of Ethylene; Increasing Linear Dynamic Range of a CMOS Image Sensor; Flight Qualified Micro Sun Sensor; Norbornene-Based Polymer Electrolytes for Lithium Cells; Making Single-Source Precursors of Ternary Semiconductors; Water-Free Proton-Conducting Membranes for Fuel Cells; Mo/Ti Diffusion Bonding for Making Thermoelectric Devices; Photodetectors on Coronagraph Mask for Pointing Control; High-Energy-Density, Low-Temperature Li/CFx Primary Cells; G4-FETs as Universal and Programmable Logic Gates; Fabrication of Buried Nanochannels From Nanowire Patterns; Diamond Smoothing Tools; Infrared Imaging System for Studying Brain Function; Rarefying Spectra of Whispering-Gallery-Mode Resonators; Large-Area Permanent-Magnet ECR Plasma Source; Slot-Antenna/Permanent-Magnet Device for Generating Plasma; Fiber-Optic Strain Gauge With High Resolution And Update Rate; Broadband Achromatic Telecentric Lens; Temperature-Corrected Model of Turbulence in Hot Jet Flows; Enhanced Elliptic Grid Generation; Automated Knowledge Discovery From Simulators; Electro-Optical Modulator Bias Control Using Bipolar Pulses; Generative Representations for Automated Design of Robots; Mars-Approach Navigation Using In Situ Orbiters; Efficient Optimization of Low-Thrust Spacecraft Trajectories; Cylindrical Asymmetrical Capacitors for Use in Outer Space; Protecting Against Faults in JPL Spacecraft; Algorithm Optimally Allocates Actuation of a Spacecraft; and Radar Interferometer for Topographic Mapping of Glaciers and Ice Sheets.
Three Auxiliary Power Units (APU) on the Space Shuttle Orbiter each provide 145 hp shaft power to a hydraulic pump which outputs 3000 psi hydraulic fluid to 41 hydraulic actuators. A hydrazine fuel powered APU utilized throughout the Shuttle program has undergone many improvements, but concerns remain with flight safety, operational cost, critical failure modes, and hydrazine related hazards. The advanced hydraulic power system (AHPS), also known as the electric APU, is being evaluated as an upgrade to replace the hydrazine APU. The AHPS replaces the high-speed turbine and hydrazine fuel supply system with a battery power supply and electric motor/pump that converts 300 volt electrical power to 3000 psi hydraulic power. AHPS upgrade benefits include elimination of toxic hydrazine propellant to improve flight safety, reduction in hazardous ground processing operations, and improved reliability. Development of this upgrade provides many interesting challenges and includes development of four hardware elements that comprise the AHPS system: Battery - The battery provides a high voltage supply of power using lithium ion cells. This is a large battery that must provide 28 kilowatt hours of energy over 99 minutes of operation at 300 volts with a peak power of 130 kilowatts for three seconds. High Voltage Power Distribution and Control (PD&C) - The PD&C distributes electric power from the battery to the EHDU. This 300 volt system includes wiring and components necessary to distribute power and provide fault current protection. Electro-Hydraulic Drive Unit (EHDU) - The EHDU converts electric input power to hydraulic output power. The EHDU must provide over 90 kilowatts of stable, output hydraulic power at 3000 psi with high efficiency and rapid response time. Cooling System - The cooling system provides thermal control of the Orbiter hydraulic fluid and EHDU electronic components. Symposium presentation will provide an overview of the AHPS upgrade, descriptions of the four hardware elements, and a summary of development results to date.
Specification and development of fault management functionality in systems is performed in an ad hoc way - more of an art than a science. Improvements to system reliability, availability, safety and resilience will be limited without infusion of additional formality into the practice of fault management. Key to the formalization of fault management is a precise representation of off-nominal behavior. Using the upcoming Soil Moisture Active-Passive (SMAP) mission for source material, we have modeled the off-nominal behavior of the SMAP system during its initial spin-up activity, using the System Modeling Language (SysML). In the course of developing these models, we have developed generic patterns for capturing off-nominal behavior in SysML. We show how these patterns provide useful ways of reasoning about the system (e.g., checking for completeness and effectiveness) and allow the automatic generation of typical artifacts (e.g., success trees and FMECAs) used in system analyses.
Fault Management is an essential part of the system engineering process that is limited in its effectiveness by the ad hoc nature of the applied approaches and methods. Providing a rigorous way to develop and describe off-nominal behavior is a necessary step in the improvement of fault management, and as a result, will enable safe, reliable and available systems even as system complexity increases... The basic concepts described in this paper provide a foundation to build a larger set of necessary concepts and relationships for precise modeling of off-nominal behavior, and a basis for incorporating these ideas into the overall systems engineering process.. The simple FMEA example provided applies the modeling patterns we have developed and illustrates how the information in the model can be used to reason about the system and derive typical fault management artifacts.. A key insight from the FMEA work was the utility of defining failure modes as the "inverse of intent", and deriving this from the behavior models.. Additional work is planned to extend these ideas and capabilities to other types of relevant information and additional products.
Second Chance (SECC) was a bare bones version of Mars Science Laboratory's (MSL) Entry Descent & Landing (EDL) flight software that ran on Curiosity's backup computer, which could have taken over swiftly in the event of a reset of Curiosity's prime computer, in order to land her safely on Mars. Without SECC, a reset of Curiosity's prime computer would have lead to catastrophic mission failure. Even though a reset of the prime computer never occurred, SECC had the important responsibility as EDL's guardian angel, and this responsibility would not have seen such success without unparalleled systems engineering. This paper will focus on the systems engineering behind SECC: Covering a brief overview of SECC's design, the intense schedule to use SECC as a backup system, the verification and validation of the system's "Do No Harm" mandate, the system's overall functional performance, and finally, its use on the fateful day of August 5th, 2012.
Before the Curiosity rover can perform its science activities for the day, such as driving, moving its robotic arm, or drilling, it first has to ensure that its actuators are within their allowable flight temperatures (AFTs). When the rover is awake, flight software uses heaters to warm up and maintain thermal zones at operational temperatures. However, Curiosity spends about 70% of its time sleeping, with the flight computer off, in order to conserve energy. Dream Mode is a special behavior that allows the rover to execute warm-up activities while sleeping. Using Dream Mode, actuators can be warmed up to their AFTs before the flight computer wakes up and uses them - saving power and improving operational efficiency. This paper describes the motivation behind Dream Mode, how it was implemented and tested on Curiosity, and the challenges and lessons learned along the way.
No abstract available
NASA's Cassini Spacecraft, launched on October 15th, 1997 which arrived at Saturn on June 30th, 2004, is the largest and most ambitious interplanetary spacecraft in history. As the first spacecraft to achieve orbit at Saturn, Cassini has collected science data throughout its four-year prime mission (2004–08), and has since been approved for a first and second extended mission through 2017. As part of the final extended missions, Cassini will begin an aggressive and exciting campaign of high inclination, low altitude flybys within the inner most rings of Saturn, skimming Saturn’s outer atmosphere, until the spacecraft is finally disposed of via planned impact with the planet. This final campaign, known as the proximal orbits, requires a strategy for managing the Sun Sensor Assembly (SSA) health, the details of which are presented in this paper.
In July 2013, NASA's Solar Radiation and Climate Experiment experienced a battery anomaly which placed it into safemode halting all science observations. Initial attempts to recover the spacecraft to an operational configuration failed due to the reduced capacity of the battery. As the keystone mission for measuring total solar irradiance, and the cornerstone mission for measuring the solar spectral irradiance there was a strong motivation for developing a new operations concept that would allow SORCE to resume daily measurements of the Sun. The operations team faced many challenges over the next several months. For a five-day period in late 2013 the operations team was able resume science observations to cross-calibrate SORCE data with a new instrument launched in November 2013. After the cross-calibration campaign was completed a new operations concept was deployed which allowed SORCE to perform daylight only operations. In this mode of operations all non-essential components are powered off at each eclipse entry and then turned back on at sunrise. In March 2014 SORCE resumed making daily measurements of the Sun. This paper will review the events and lessons learned from the six-month recovery effort.
The recent experience of the SORCE flight operations team offers an excellent example of innovative engineering using limited resources. The goal of this paper is to extend to the space operations community the lessons learned during this critical redesign in order to aid other missions facing equally daunting challenges. The end result is a mission extended well beyond its designed life continuing to return important data to the science community to extend the climate record.