Search NASA⌕ Search

SEARCH · Search NASA

Results for “fault protection”

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.

At least 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Spacecraft fault tolerance: The Magellan experience

Interplanetary and earth orbiting missions are now imposing unique fault tolerant requirements upon spacecraft design. Mission success is the prime motivator for building spacecraft with fault tolerant systems. The Magellan spacecraft had many such requirements imposed upon its design. Magellan met these requirements by building redundancy into all the major subsystem components and designing the onboard hardware and software with the capability to detect a fault, isolate it to a component, and issue commands to achieve a back-up configuration. This discussion is limited to fault protection, which is the autonomous capability to respond to a fault. The Magellan fault protection design is discussed, as well as the developmental and flight experiences and a summary of the lessons learned.

Kasuda, Rick↗
NASA NTRS1990

Space station common module network topology and hardware development

Conceptual space station common module power management and distribution (SSM/PMAD) network layouts and detailed network evaluations were developed. Individual pieces of hardware to be developed for the SSM/PMAD test bed were identified. A technology assessment was developed to identify pieces of equipment requiring development effort. Equipment lists were developed from the previously selected network schematics. Additionally, functional requirements for the network equipment as well as other requirements which affected the suitability of specific items for use on the Space Station Program were identified. Assembly requirements were derived based on the SSM/PMAD developed requirements and on the selected SSM/PMAD network concepts. Basic requirements and simplified design block diagrams are included. DC remote power controllers were successfully integrated into the DC Marshall Space Flight Center breadboard. Two DC remote power controller (RPC) boards experienced mechanical failure of UES 706 stud-mounted diodes during mechanical installation of the boards into the system. These broken diodes caused input to output shorting of the RPC's. The UES 706 diodes were replaced on these RPC's which eliminated the problem. The DC RPC's as existing in the present breadboard configuration do not provide ground fault protection because the RPC was designed to only switch the hot side current. If ground fault protection were to be implemented, it would be necessary to design the system so the RPC switched both the hot and the return sides of power.

Anderson, P.↗
NASA NTRS1989

A system architecture for a planetary rover

Each planetary mission requires a complex space vehicle which integrates several functions to accomplish the mission and science objectives. A Mars Rover is one of these vehicles, and extends the normal spacecraft functionality with two additional functions: surface mobility and sample acquisition. All functions are assembled into a hierarchical and structured format to understand the complexities of interactions between functions during different mission times. It can graphically show data flow between functions, and most importantly, the necessary control flow to avoid unambiguous results. Diagrams are presented organizing the functions into a structured, block format where each block represents a major function at the system level. As such, there are six blocks representing telecomm, power, thermal, science, mobility and sampling under a supervisory block called Data Management/Executive. Each block is a simple collection of state machines arranged into a hierarchical order very close to the NASREM model for Telerobotics. Each layer within a block represents a level of control for a set of state machines that do the three primary interface functions: command, telemetry, and fault protection. This latter function is expanded to include automatic reactions to the environment as well as internal faults. Lastly, diagrams are presented that trace the system operations involved in moving from site to site after site selection. The diagrams clearly illustrate both the data and control flows. They also illustrate inter-block data transfers and a hierarchical approach to fault protection. This systems architecture can be used to determine functional requirements, interface specifications and be used as a mechanism for grouping subsystems (i.e., collecting groups of machines, or blocks consistent with good and testable implementations).

Smith, D. B.↗
NASA NTRS2017

Energy Management Operations for the InSight Solar-Powered Mission at Mars

This paper discusses how the change in launch date has changed the energy management challenges for InSight, and how the energy management approach for surface operations has been adapted to address those challenges. It also describes how energy balance and battery life are protected over the course of the InSight landed mission, in terms of a deliberate balance between autonomous on-board fault protection and ground commanding into reduced-load configurations that still make progress versus specific, prioritized mission success criteria. It describes the project’s unique statistical analysis and usage of Mars Exploration Rovers (MER) archived data on solar energy collection to develop and validate an explicit prelaunch margin policy versus energy reductions due to environment variability over multiple-sol sequences. And finally, the paper explains how this archived energy data has influenced the modification of the Phoenix-heritage autonomous fault protection, to guard against quickly-arising inclement power-generation conditions, such as rapid onset of a local dust storm or water ice cloud front.

Lisano II, MIchael E.↗
NASA NTRS1994

Test plan. GCPS task 7, subtask 7.1: IHM development

The overall objective of Task 7 is to identify cost-effective life cycle integrated health management (IHM) approaches for a reusable launch vehicle's primary structure. Acceptable IHM approaches must: eliminate and accommodate faults through robust designs, identify optimum inspection/maintenance periods, automate ground and on-board test and check-out, and accommodate and detect structural faults by providing wide and localized area sensor and test coverage as required. These requirements are elements of our targeted primary structure low cost operations approach using airline-like maintenance by exception philosophies. This development plan will follow an evolutionary path paving the way to the ultimate development of flight-quality production, operations, and vehicle systems. This effort will be focused on maturing the recommended sensor technologies required for localized and wide area health monitoring to a technology readiness level (TRL) of 6 and to establish flight ready system design requirements. The following is a brief list of IHM program objectives: design out faults by analyzing material properties, structural geometry, and load and environment variables and identify failure modes and damage tolerance requirements; design in system robustness while meeting performance objectives (weight limitations) of the reusable launch vehicle primary structure; establish structural integrity margins to preclude the need for test and checkout and predict optimum inspection/maintenance periods through life prediction analysis; identify optimum fault protection system concept definitions combining system robustness and integrity margins established above with cost effective health monitoring technologies; and use coupons, panels, and integrated full scale primary structure test articles to identify, evaluate, and characterize the preferred NDE/NDI/IHM sensor technologies that will be a part of the fault protection system.

Greenberg, H. S.↗
NASA NTRS2008

Mars Reconnaissance Orbiter In-flight Anomalies and Lessons Learned: An Update

The Mars Reconnaissance Orbiter mission has as its primary objectives: advance our understanding of the current Mars climate, the processes that have formed and modified the surface of the planet and the extent to which water has played a role in surface processes; identify sites of possible aqueous activity indicating environments that may have been or are conducive to biological activity; and thus identify and characterize sites for future landed missions; and provide forward and return relay services for current and future Mars landed assets. MRO's crucial role in the long term strategy for Mars exploration requires a high level of reliability during its 5.4 year mission. This requires an architecture which incorporates extensive redundancy and cross-strapping. Because of the distances and hence light-times involved, the spacecraft itself must be able to utilize this redundancy in responding to time-critical failures. For cases where fault protection is unable to recognize a potentially threatening condition, either due to known limitations or software flaws, intervention by ground operations is required. These aspects of MRO's design were discussed in a previous paper [Ref. 1]. This paper provides an update to the original paper, describing MRO's significant in-flight anomalies over the past year, with lessons learned for redundancy and fault protection architectures and for ground operations.

Mars Reconnaissance Orbiter↗
NASA NTRS2020

Driving Curiosity: Mars Rover Mobility Trends During the First Seven Years

NASA’s Mars Science Laboratory (MSL) mission landed the Curiosity rover on Mars on August 6, 2012. As of August 6, 2019 (sol 2488), Curiosity has driven 21,318.5 meters over a variety of terrain types and slopes, employing multiple drive modes with varying amounts of onboard autonomy. Curiosity’s drive distances each sol have ranged from its shortest drive of 2.6 centimeters to its longest drive of 142.5 meters, with an average drive distance of 28.9 meters. Real-time human intervention during Curiosity drives on Mars is not possible due to the latency in uplinking commands and downlinking telemetry, so the operations team relies on the rover’s flight software to prevent an unsafe state during driving. Over the first seven years of the mission, Curiosity has attempted 738 drives. While 622 drives have completed successfully, 116 drives were prevented or stopped early by the rover’s fault protection software. The primary risks to mobility success have been wheel wear, wheel entrapment, progressive wheel sinkage (which can lead to rover embedding), and terrain interactions or hardware or cabling failures that result in an inability to command one or more steer or drive actuators. In this paper, we describe mobility trends over the first 21.3km of the mission, operational aspects of the mobility fault protection, and risk mitigation strategies that will support continued mobility success for the remainder of the mission.

Rankin, Arturo↗
NASA NTRS2005

Lessons Learned in the Livingstone 2 on Earth Observing One Flight Experiment

The Livingstone 2 (L2) model-based diagnosis software is a reusable diagnostic tool for monitoring complex systems. In 2004, L2 was integrated with the JPL Autonomous Sciencecraft Experiment (ASE) and deployed on-board Goddard's Earth Observing One (EO-1) remote sensing satellite, to monitor and diagnose the EO-1 space science instruments and imaging sequence. This paper reports on lessons learned from this flight experiment. The goals for this experiment, including validation of minimum success criteria and of a series of diagnostic scenarios, have all been successfully net. Long-term operations in space are on-going, as a test of the maturity of the system, with L2 performance remaining flawless. L2 has demonstrated the ability to track the state of the system during nominal operations, detect simulated abnormalities in operations and isolate failures to their root cause fault. Specific advances demonstrated include diagnosis of ambiguity groups rather than a single fault candidate; hypothesis revision given new sensor evidence about the state of the system; and the capability to check for faults in a dynamic system without having to wait until the system is quiescent. The major benefits of this advanced health management technology are to increase mission duration and reliability through intelligent fault protection, and robust autonomous operations with reduced dependency on supervisory operations from Earth. The work-load for operators will be reduced by telemetry of processed state-of-health information rather than raw data. The long-term vision is that of making diagnosis available to the onboard planner or executive, allowing autonomy software to re-plan in order to work around known component failures. For a system that is expected to evolve substantially over its lifetime, as for the International Space Station, the model-based approach has definite advantages over rule-based expert systems and limit-checking fault protection systems, as these do not scale well. The model-based approach facilitates reuse of the L2 diagnostic software; only the model of the system to be diagnosed and telemetry monitoring software has to be rebuilt for a new system or expanded for a growing system. The hierarchical L2 model supports modularity and expendability, and as such is suitable solution for integrated system health management as envisioned for systems-of-systems.

Hayden, Sandra C.↗
NASA NTRS2012

Model-Based Verification and Validation of Spacecraft Avionics

Verification and Validation (V&V) at JPL is traditionally performed on flight or flight-like hardware running flight software. For some time, the complexity of avionics has increased exponentially while the time allocated for system integration and associated V&V testing has remained fixed. There is an increasing need to perform comprehensive system level V&V using modeling and simulation, and to use scarce hardware testing time to validate models; the norm for thermal and structural V&V for some time. Our approach extends model-based V&V to electronics and software through functional and structural models implemented in SysML. We develop component models of electronics and software that are validated by comparison with test results from actual equipment. The models are then simulated enabling a more complete set of test cases than possible on flight hardware. SysML simulations provide access and control of internal nodes that may not be available in physical systems. This is particularly helpful in testing fault protection behaviors when injecting faults is either not possible or potentially damaging to the hardware. We can also model both hardware and software behaviors in SysML, which allows us to simulate hardware and software interactions. With an integrated model and simulation capability we can evaluate the hardware and software interactions and identify problems sooner. The primary missing piece is validating SysML model correctness against hardware; this experiment demonstrated such an approach is possible.

MBV&V↗
NASA NTRS1982

Galileo spacecraft power distribution and autonomous fault recovery

There is a trend in current spacecraft design to achieve greater fault tolerance through the implemenation of on-board software dedicated to detecting and isolating failures. A combination of hardware and software is utilized in the Galileo power system for autonomous fault recovery. Galileo is a dual-spun spacecraft designed to carry a number of scientific instruments into a series of orbits around the planet Jupiter. In addition to its self-contained scientific payload, it will also carry a probe system which will be separated from the spacecraft some 150 days prior to Jupiter encounter. The Galileo spacecraft is scheduled to be launched in 1985. Attention is given to the power system, the fault protection requirements, and the power fault recovery implementation.

Detwiler, R. C.↗
NASA NTRS2011

CoNNeCT Baseband Processor Module

A document describes the CoNNeCT Baseband Processor Module (BPM) based on an updated processor, memory technology, and field-programmable gate arrays (FPGAs). The BPM was developed from a requirement to provide sufficient computing power and memory storage to conduct experiments for a Software Defined Radio (SDR) to be implemented. The flight SDR uses the AT697 SPARC processor with on-chip data and instruction cache. The non-volatile memory has been increased from a 20-Mbit EEPROM (electrically erasable programmable read only memory) to a 4-Gbit Flash, managed by the RTAX2000 Housekeeper, allowing more programs and FPGA bit-files to be stored. The volatile memory has been increased from a 20-Mbit SRAM (static random access memory) to a 1.25-Gbit SDRAM (synchronous dynamic random access memory), providing additional memory space for more complex operating systems and programs to be executed on the SPARC. All memory is EDAC (error detection and correction) protected, while the SPARC processor implements fault protection via TMR (triple modular redundancy) architecture. Further capability over prior BPM designs includes the addition of a second FPGA to implement features beyond the resources of a single FPGA. Both FPGAs are implemented with Xilinx Virtex-II and are interconnected by a 96-bit bus to facilitate data exchange. Dedicated 1.25- Gbit SDRAMs are wired to each Xilinx FPGA to accommodate high rate data buffering for SDR applications as well as independent SpaceWire interfaces. The RTAX2000 manages scrub and configuration of each Xilinx.

Yamamoto, Clifford K↗
NASA NTRS1996

The Mars Global Surveyor Spacecraft Test Laboratory

The spacecraft testbed is a crucial part of the spacecraft development and operations phase. Given the aggressive schedule of the Mars Global Surveyor spacecraft, the Spacecraft Test Laboratory will play a crucial part during the MGS development phase in support of flight software testing, fault protection testing, sequence testing, and other areas to meet the November, 1996 launch date.

MGS↗
NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗
NASA NTRSDate not supplied

Solid-State Exergy Optimized Electric Aircraft Thermal and Fault Management

Future air vehicles will increasingly incorporate electrical powertrains that require very tight system level integration of power, propulsion, thermal, fault protection, and airframe technologies. This paper provides an overview of a new category of thermal energy conversion technology that can be used to enable a fully solid-state integrated thermal and fault management electric aircraft protection system, while synergistically managing and recycling both the low-grade waste heat from electrical components and the high-grade waste heat from engine components. This is achieved with exergy amplification of the powertrain waste-heat, a new class of fast flight-weight breakers, new class of long variable conductance heat pipe with multiple switchable condensers, new class of turbofan integrated heat exchangers and a gradient-based powertrain system optimizer.

safety↗