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.
Fault protection can include a wide range of topics, ranging from fault prevention to autonomous fault detection and recovery. This paper will address a portion of the autonomous fault detection and recovery implemented onboard the Cassini spacecraft. Specifically, the topic is system fault protection design, as opposed to subsystem fault protection design.
NASA's Cassini Spacecraft, launched on October 15th, 1997 and arrived at Saturn on June 30th, 2004, is the largest and most ambitious interplanetary spacecraft in history. In order to meet the challenging attitude control and navigation requirements of the orbit profile at Saturn, Cassini is equipped with a monopropellant thruster based Reaction Control System (RCS), a bipropellant Main Engine Assembly (MEA) and a Reaction Wheel Assembly (RWA). In 2008, after 11 years of reliable service, several RCS thrusters began to show signs of end of life degradation, which led the operations team to successfully perform the swap from the A-branch to the B-branch RCS system. If similar degradation begins to occur on any of the B-branch thrusters, Cassini might have to assume a "mixed" thruster configuration, where a subset of both A and B branch thrusters will be designated as prime. The Cassini Fault Protection FSW was recently updated to handle this scenario. The design, implementation, and testing of this update is described in this paper.
The Cassini Attitude and Articulation Control Subsystem (AACS) Fault Protection (FP) has been successfully supporting operations for over 10 years from launch through the end of the prime mission. Cassini's AACS FP is complex, containing hundreds of error monitors and thousands of tunable parameters. Since launch there have been environmental, hardware, personnel and mission event driven changes which have required AACS FP to adapt and be robust to a variety of scenarios. This paper will discuss the process of monitoring, maintaining and updating the AACS FP during Cassini's lengthy prime mission as well as provide some insight into lessons learned during tour operations.
The Command and Data Subsystem (CDS) on Cassini is responsible for uplink command processing, spacecraft intercommunications and control, and downlink telemetry formatting. The 10.7 year mission life, 160 minute round-trip light time, and extended periods of operation without continuous ground communications drive the CDS design in directions of redundancy, autonomy, and fault protection to accomodate the mission objectives.
The difficulties encountered in designing a redundancy management system are discussed and strategies for minimizing the cost and schedule impacts associated with fault protection are provided. Specific examples from the Magellan project are used with emphasis placed on control system fault protection. The major problem areas are the following: (1) the interaction between two semiindependent fault protection systems, (2) the response to faults which are detected by monitoring variables with long time constants, and (3) the design of the 'action scheduler'.
The QuickScat and Sea Winds instruments are radar scatterometer instruments that will be used to measure ocean surface winds.
On July 30th 2020, the Mars 2020 mission successfully launched out of Cape Canaveral, Florida, passed through the Earth’s shadow, and began its short cruise to Mars. Less than seven months later, the Perseverance rover touched down safely in Jezero Crater to begin its ambitious mission that includes looking for signs of ancient life and collecting samples for future return to Earth. Getting to the successful landing, or “Tango Delta Nominal,” could not have been achieved without also considering the off-nominal. One of the teams supporting this ambitious mission is the fault protection (FP) team. This team is tasked with assessing the various failures, or faults, that could prevent mission success and with ensuring that the autonomous behaviors built into the software and hardware can detect faults and recover the vehicle to a safe state. As part of its charter, the FP team designed a test campaign to provide confidence in the system’s robustness to off-nominal scenarios across all of Mars 2020’s mission phases. The greatest challenge associated with designing such a validation campaign was reducing the infinite number of anomalous scenarios into a finite test suite. In addition, the tests needed to be executed efficiently in order to utilize the team’s limited test venue access, but still needed to maintain a level of rigor that guaranteed confidence in the test outcomes. Given that each test scenario generated massive amounts of data, the team also developed methods for quickly ascertaining whether the autonomous fault protection behaviors maintained vehicle safety in the presence of an anomaly. This paper summarizes the processes that the Mars 2020 fault protection team employed to execute its off-nominal validation campaign. It captures both the methods of generating a suite of off-nominal tests, as well as reducing it to a subset that can be realistically executed within schedule and resource constraints. It also describes the various processes and philosophies that the team utilized to execute the tests efficiently, including creating a standardized procedure template, keeping the test cases modular so that they could be easily interchanged, and capturing common fault injections in a change-controlled database. Finally, it will describe the tools and processes for assessing the test data, focusing in particular on a tool that evaluated vehicle state using “secondary” sources of data to validate that the software had truly configured the spacecraft to the expected safe state.
No abstract available
A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to- 1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-by-step fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis "top-down" approach, and a functional fault-mode-effects-and-analysis via "bottoms-up" approach. Via this process, the mitigation and recovery strategy(s) per Fault Containment Region scope (width versus depth) the FP architecture.
The Cassini spacecraft fault protection design includes fault monitors that use a state-space architecture to monitor the performance of spacecraft functions.
On November 20, 2017, ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics), a 6U CubeSat performing a technology demonstration of astrophysical measurements, deployed from the ISS. The technology demonstration goals to achieve precision photometry via arcsecond-level line-of-sight pointing error and highly stable focal plane temperature control were met by February 2018. Extended mission operations are ongoing, with the primary focus on observing nearby stars for transiting exoplanets. Throughout development and operations, the roles of mission assurance and fault protection have proven critical to achieving the primary technical goals and to maintaining a healthy spacecraft through multiple extended missions. Given the budget and schedule constraints typical of a CubeSat, innovative tailoring of processes has been critical to success throughout both development and operations of ASTERIA. Mission assurance plays an important role in identifying and evaluating risk and developing cost-effective mitigations. Flexibility in the fault protection design offers a variety of options for implementing risk mitigations as risks have been uncovered both in pre-delivery testing and in mission operations. This paper will discuss the approach taken on ASTERIA to implement mission assurance and fault protection and the resulting benefits to operational efficiency and success. It will briefly address the advantages of this approach during development, in which the combination of the roles provided mission assurance significant insight to system risks, which feeds back into testing methodologies and directly into fault protection design. Operations will be discussed in detail. During this phase, the roles merge to identify in-flight fault protection updates to efficiently respond to anomalies and improve the likelihood of successful technology demonstrations. The paper will also detail the tools that are used to analyse data, identify anomalies, and develop the updates to uplink to the spacecraft. Finally, the general operational approach will be discussed to highlight the usefulness of the ASTERIA processes and their applicability to future CubeSat missions.
The Mars Exploration Rovers surface fault protection design was influenced by the fact that the solar-powered rovers must recharge their batteries during the day to survive the night. the rovers needed to autonomously maintain thermal stability, initiate safe and reliable communication with orbiting assets or directly to Earth, while maintaining energy balance. This paper will describe the system fault protection design for the surface phase of the mission.
On October 24th, 1998, the Deep Space One (DS-1) spacecraft launched aboard a Delta II rocket as the first step towards the bold task of testing and validating 12 new technologies for future missions. This launch also represented yet another thrilling event; namely, the successful test and validation of a 13th heretofore undisclosed technology: model-based code-generation of the spacecraft's system-level fault-protection (FP) software from behavioral state diagrams and structural models.In this paper, we describe the process we used to leverage model-based code generation from state diagrams and structural specifications to better respond to the evolving requirements and scope of DS- I's system-level fault-protection design, development, test and operation. The evolution of the high-level design and the low-level changes in the flight software architecture and interfaces contributed to multiplying the number and frequency of fault-protection software releases thereby creating a multitude of software integration issues. To address the resulting software integration issues, we broadened the scope of code -eneration to other forms of model- based analysis techniques more traditionally associated with first-principle's reasoning about physical models. Additionally, we describe our in-flight launch and initial acquisition 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.
NASA’s Psyche mission will launch in 2022 and begin a 3.6-year cruise to the metallic asteroid Psyche, the largest metal asteroid in the solar system. The baseline spacecraft design is a hybrid of JPL’s deep-space heritage subsystems with commercial partner Maxar’s electric propulsion, power, and structure subsystems. The Psyche mission will feature the first use of Hall thrusters for a NASA mission, and the first use of Hall thrusters beyond cis-lunar space. This paper will provide an overview of the electric propulsion subsystem and details of the flight system implementation for the Psyche mission. The concept of operations is discussed including subsystem-level operations, the initial checkout after launch, and cruise and orbital operations. Command and control interfaces with the spacecraft and fault protection design are presented. Finally, the status of subsystem assembly and test is described.
Fault protection as a discipline involves a collection of flight software logic and operational processes for detecting unacceptable anomalous behavior, responding prior to reaching criticality, restricting the propagation of a failure beyond a fault containment region, and recovering the vehicle back to full or degraded functionality if possible. The System Fault Protection (SFP) design for the SMAP Earth orbiter was put to the test during its 90-day vehicle commissioning activities. During this time, the SFP software autonomously protected the vehicle from multiple faults to critical hardware, and the operations team successfully returned the observatory to its science state. The SFP also performed well in the presence of anomalous behavior below true safety limits by not taking unnecessary response actions, instead allowing the operations team time to monitor the behavior. Certain aspects of the SFP design were modified during operations via both parameter updates and a full flight software update in order to better match the vehicle behavior in the flight environment. An evaluation of the SMAP SFP performance during vehicle Commissioning will be provided in this paper, as well as a set of lessons learned largely focused on visibility, SFP mutability in operations, responses to peripheral device faults, and Safe Mode recovery and design. By capturing some of the knowledge gained during SMAP Commissioning, it is intended that this paper provide guidance for making future System Fault Protection designs more robust and supportive of operations.
The work presented in this paper describes an approach used to develop SysML modeling patterns to express the behavior of fault protection, test the model's logic by performing fault injection simulations, and verify the fault protection system's logical design via model checking. A representative example, using a subset of the fault protection design for the Soil Moisture Active-Passive (SMAP) system, was modeled with SysML State Machines and JavaScript as Action Language. The SysML model captures interactions between relevant system components and system behavior abstractions (mode managers, error monitors, fault protection engine, and devices/switches). Development of a method to implement verifiable and lightweight executable fault protection models enables future missions to have access to larger fault test domains and verifiable design patterns. A tool-chain to transform the SysML model to jpf-Statechart compliant Java code and then verify the generated code via model checking was established. Conclusions and lessons learned from this work are also described, as well as potential avenues for further research and development.