Fault management
Fault management detects that something has gone wrong, decides how far to fall back, and gets the vehicle into a state the ground can recover without real-time contact.
The problem
Section titled “The problem”The environment makes this hard in three ways. Light time and relay geometry mean the ground cannot intervene inside the time to criticality for many faults. Power on a solar rover or a battery-limited lander is the resource the fallback itself consumes. And the flight computer is slow and memory-limited, so the logic must be small enough to verify [13][18].
Practice differs between mission classes for stated reasons: light time relative to time to criticality, whether a crew can intervene, and whether safe mode is a viable response at all. Safe mode is not available during orbit insertion or landing, where entering it forfeits the event [13]. A NASA handbook effort on fault management drew over 1100 review comments from ten Centers on its second draft, which its authors read as evidence that one document could not unify practice across mission types [13].
What has flown
Section titled “What has flown”The flown planetary designs converge on one structure: monitors that detect, persistence counts that filter single bad readings, a central engine that arbitrates among hard-coded responses by priority, and a small number of safe states entered by demotion that only the ground can reverse.
Cassini. As designed before launch, nine system monitors in Ada ran once per second, fifteen responses were written in the sequencing language, and a manager resolved concurrency with four priority levels and at most eight active responses. Stored sequences are halted before any system response, and responses must be safe to interrupt at any pause point [1]. In December 2012 a flight software change (version A8.9.0) let attitude control fault protection swap thruster branches a second time at tier 7, because the original logic could only swap once and would never isolate a leak on the B branch in a mixed configuration. Testing found two defects that were accepted: phantom reaction wheel momentum after a computer reset made a monitor trip six times, and a shared tier counter let another monitor trip nine times instead of the designed five [26]. No on-orbit behavior of the new logic is reported [26].
Mars Exploration Rovers. Responses are layered from always-available hardware protection, through flight software retries and data marking, to subsystem and system responses. On a solar rover the backbone is the autonomous shutdown and wakeup algorithm rather than a safe mode [3]. Less than 5 percent of surface time, about 30 of 700 sols per vehicle, went to anomaly recovery, because the daily tactical replanning process also recovers from anomalies [6].
Curiosity. The engine arbitrates over 1000 monitors and 39 system responses with a 1 Hz poll, and monitors latch red until reset so that a polling engine does not miss fast transients [2]. The authors state two costs: the engine services the first highest-priority response it examines rather than the monitor that tripped first, which is more likely the root cause, and aborts are allowed at any step boundary, which leaves an abort state space that cannot be fully tested [2]. Safe mode cannot follow the deep-space convention of continuous transmission, because the avionics and telecom load exceeds the 114 W power source; it interleaves sleep periods with communication windows [25]. A modeled safing day nets a 22 percent gain in battery state of charge, and flight experience at the time of that paper was two safing events in 342 sols [25].
Psyche. Monitors report to a centralized engine over one nominal mode and three tiers of safe mode, with fault protection allowed to demote modes and only the ground allowed to promote them [4]. The design has a few thousand identified failure modes, 8 system modes, about 650 monitors and 185 responses [22]. Payload responses were limited to power off and wait for the ground, with no reset and retry; the DSOC laser terminal alone produced about ten monitors, most masked during operations because any trip would end a communication opportunity [23].
EO-1. The Autonomous Sciencecraft Experiment is the longer flown record of onboard autonomy: a 21 day run under autonomous control with over 300 autonomously controlled image acquisitions [15]. It was a science-planning experiment, not a replacement for fault protection.
What is being tried now
Section titled “What is being tried now”Model-based diagnosis. These approaches reason from explicit component models instead of hard-coded thresholds. The motivating case is the Mars Polar Lander premature engine shutdown, where a latched leg-sensor noise spike was read as touchdown at about 40 m [10]. A 1996 prototype combining a planner, reactive executive and mode identification and recovery was demonstrated on a simulated Saturn orbit insertion and selected for Deep Space One, with fault isolation in 4 to 16 search steps (1.1 to 5.5 s) on a SPARC-5 workstation, not a flight processor [12]. The current JPL line is MONSID, a constraint-suspension engine. It was integrated into the ASTERIA CubeSat flight software with a model of 12 components and 100 state variables, 94 of which map to telemetry, but the spacecraft was lost in December 2019 before the planned experiment, so every result is a testbed result against replayed flight data [28]. The same model run over more than 7 million archived telemetry points confirmed the star tracker model and produced coarse sun sensor false positives traced to tuned parameters and an incomplete model, with no false positive or negative rate estimated [29]. The end-of-mission report states MONSID was exercised only on the ground testbed [34]. A 2026 simulation pairs MONSID with a capability-based mode commander that degrades through nominal, degraded and critical modes instead of entering safe mode on the first fault; the demonstration is a 180 s cascading fault run on a simulated attitude control system [31]. A rebuilt offline-compiled mode estimator for a lunar rover power subsystem measured peak memory of 89.05 MB against 116.2 MB for a solver-based search of the kind flown on Deep Space 1; the paper’s own conclusions overstate its Table 1 [35]. Status: flown once as a prototype lineage (Deep Space One), otherwise ground and simulation.
Fault protection absorbed into control. One position holds that fault protection already observes, models, estimates and directs, so it should be absorbed into state-based and model-based control of the same state [11]. It is an argument with no flown demonstration. Status: proposal.
Learned and statistical anomaly detection. A five-layer detector on Curiosity power telemetry combines fixed limits, quantile thresholds, prediction-error derivatives, an autoencoder and a command-versus-telemetry rule; it reports annotated plots and no precision, recall or latency [30]. A detector for a lunar rover concept, trained on 184 simulated runs because no mission data exists, reached true positive rates of 0.93 to 1.00 with detection latency of 1.3 to 2.1 s but precision of only 0.10 to 0.16, on synthetic data from the generating simulator [33]. Status: ground, with synthetic or replayed data.
Onboard replanning after faults. MEXEC restores a task network after a processor reset and rebuilds a valid remainder of the plan; on a RAD750 testbed it resolved plan problems in under 0.1 s after a simulated reset [36]. On ASTERIA in September 2019 it planned and executed uploaded task networks in flight within a 2 MB allocation, about 100 tasks, but the reactive recovery experiment ran only on the testbed after the spacecraft was lost [32]. A prototype tool checks the Europa Clipper command sequence against injected processor resets and found latent sensitivities in two scenarios, using exaggerated resource limits [37]. Status: partly flown; the fault-recovery part is ground-tested.
Operations for redundancy. On Perseverance, four locations hold critical files across two compute elements and none synchronizes automatically, so an autonomous swap can land the team on a stale machine; the response is a reusable ground synchronization activity [38].
Safe state cost
Section titled “Safe state cost”Safing is a power problem as much as a logic problem. In Curiosity safe mode the rover follows a fixed table of fault protection windows for waking, antenna choice and sleep, and because the rover is power negative whenever the compute element is on, window length trades communication against battery recharge [5]. At landing, nine Martian hours of daily safe mode communication still gained 22 percent state of charge per sol; by 2023 only 6.6 hours could be afforded, at a gain of 5.5 percent [5]. On MER the arrays supplied about 900 Wh per sol at the start of the mission and the CPU sleeps when no communication window is active; a failed-on heater switch on Opportunity cost 180 Wh each night [3].
Spurious or unavoidable trips are a measured cost of driving. On Curiosity, fault protection stopped 116 of 738 attempted drives (15.7 percent) over seven years, yet 91.7 percent of predicted cumulative odometry was still achieved [8]. Twenty-four types of fault protection produced incomplete drives [7]. Across Spirit, Opportunity, Phoenix, Curiosity, InSight and Perseverance, 48 major anomalies (four or more consecutive sols of lost progress) cost on average 11 percent of prime mission surface duration, 6.6 percent over the full mission, with a mean duration of 15 sols and a P95 of 45 sols; 11 were software anomalies [27].
Flight anomalies that exercised the protection
Section titled “Flight anomalies that exercised the protection”Two flash memory anomalies show faults that sat below the monitored layer. On Spirit, a flaw in the VxWorks DOS file system library left the rover in a continuous reset loop from sol 18 and out of contact for about three sols; the memory needed to mount the file system grew with the high water mark of files ever created, and two configuration parameters let the allocation expand past the free memory available [20]. On MSL at sol 200, uncorrectable NAND errors hung flight software and kept the prime compute element from powering down for its recharge cycle; the team commanded a swap to the backup element 16 hours after the first error message, 35 days before a solar conjunction blackout [21]. Both accounts are written by the project’s own teams and report single events, not rates [20][21].
Verification
Section titled “Verification”Fault protection cannot be tested exhaustively, so the practical question is how completeness is argued. Mars 2020 derived over 400 scenario-based cases across two flight software versions, prioritized to a minimal set of 150, and executed 265 [9]. Psyche scoped only 176 end-to-end cases and executed 76 before the launch slip; a GNC tiger team then found that attitude and rate error monitors had thresholds sized for slews while active during static pointing, and the post-slip regression ran 77 cases, 46 of high priority, in two months across 35 testbed shifts [22]. A three-month FMECA review found 147 previously unrecorded failure modes on four device types with no new single point failure, and a GNC review flagged about 33 percent of roughly 140 monitors for possible update [4]. The Psyche GNC off-nominal campaign produced more than 200 problem failure reports with twelve open at completion, from single-fault scenarios only [24].
Software size sets the scale of the problem. NASA flight software has grown roughly tenfold per decade, and one study argues for extending onboard fault protection techniques to cover residual software defects, citing an assumed one residual defect per thousand lines [18]. Cassini’s attitude control software retrospective covers the same lineage through in-flight autonomy and lessons learned [19].
Fault tolerance in flight computers predates fault protection software. The JPL-STAR design contrasted massive redundancy with selective replacement redundancy in a self-testing and repairing spacecraft computer, with quantitative reliability results deferred to later work [16]. SIFT put fault masking, diagnosis and reconfiguration in ordinary software, with independent processors voting on one another’s results, and its reliability numbers rest on assumed fault rates [17].
The numbers
Section titled “The numbers”| System | Quantity | Value | Source |
|---|---|---|---|
| Cassini | system monitors, responses, priority levels | 9, 15, 4 | [1] |
| Curiosity | monitors, system responses, poll rate | over 1000, 39, 1 Hz | [2] |
| Psyche | monitors, responses, system modes | about 650, 185, 8 | [22] |
| Mars 2020 | scenario cases derived, prioritized, executed | over 400, 150, 265 | [9] |
| Psyche | end-to-end cases scoped, executed before slip | 176, 76 | [22] |
| Curiosity | attempted drives stopped by fault protection | 116 of 738 | [8] |
| Curiosity | safe mode state of charge gain per sol, landing and 2023 | 22 percent, 5.5 percent | [5] |
| Mars surface missions | major anomalies, mean and P95 duration | 48, 15 and 45 sols | [27] |
| MONSID on ASTERIA | model components, state variables mapped to telemetry | 12, 94 of 100 | [28] |
What is not established
Section titled “What is not established”No source here reports a detection rate, false-trip rate or time to detect for a flown fault protection engine; the Curiosity engine description gives no flight execution statistics or CPU cost for the poll [2]. The Mars 2020 and Psyche counts are workload and analysis artifacts, not evidence of residual risk [4][9][22]. Psyche validation reports no coverage fraction against its failure modes and no detection latency [22]. The model-based approaches have timings from workstations, testbeds and simulated scenarios, not flight data [12][28][29]. The learned detectors have no result on real faults [30][33], and the state-based argument is unsupported by any mission comparison [11]. The MER anomaly record gives an aggregate recovery fraction without defining what counts as recovery [6]. Surveys of the fault management guidebook and the 2017 tool development carry no engineering quantities [13][14]. The Cassini second-swap change has no reported on-orbit behavior [26].
References
- Slonski, J. P. (1995). System Fault Protection Design for the Cassini Spacecraft
. IEEE Aerospace Applications Conference. Source
BibTeX
@inproceedings{slonski1995system, title = {System Fault Protection Design for the Cassini Spacecraft}, author = {Slonski, John P.}, booktitle = {IEEE Aerospace Applications Conference}, volume = {1}, pages = {279-292}, publisher = {IEEE}, year = {1995}, doi = {10.1109/aero.1996.495890}, abstract = {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 on board the Cassini spacecraft. Specifically, the topic is system level fault protection design, as opposed to subsystem fault protection design. The design of system fault protection for the Cassini spacecraft will be described at a high level in order to define the guiding principles of the design. This will include examining driving requirements, high level design trades, and major architectural elements, including practical details of their design. Finally, a detailed design description will be given of two Cassini fault protection responses which are likely to be used on most other spacecraft.} } - Benowitz, E. (2015). The Curiosity Mars Rover's Fault Protection Engine
. IEEE International Conference on Space Mission Challenges for Information Technology. Source
BibTeX
@inproceedings{benowitz2015curiosity, title = {The Curiosity Mars Rover's Fault Protection Engine}, author = {Benowitz, Ed}, booktitle = {IEEE International Conference on Space Mission Challenges for Information Technology}, volume = {111}, pages = {62-66}, address = {Big Sky, Montana}, year = {2015}, doi = {10.1109/smc-it.2014.16}, abstract = {The Curiosity Rover, currently operating on Mars, contains flight software onboard to autonomously handle aspects of system fault protection. Over 1000 monitors and 39 responses are present in the flight software. Orchestrating these behaviorsis the flight software's fault protection engine. In this paper, we discuss the engine's design, responsibilities, and present some lessons learned for future missions.} } - Neilson, T. (2005). Mars Exploration Rovers Surface Fault Protection
. IEEE International Conference on Systems, Man and Cybernetics. Source
BibTeX
@inproceedings{neilson2005mars, title = {Mars Exploration Rovers Surface Fault Protection}, author = {Neilson, Tracy}, booktitle = {IEEE International Conference on Systems, Man and Cybernetics}, volume = {1}, pages = {14-19}, address = {Big Sky, Montana}, year = {2005}, doi = {10.1109/icsmc.2005.1571115}, abstract = {The Mars exploration rovers surface fault protection design was influenced by the need for the solar powered rovers to recharge their batteries during the day to survive the night. The rovers were required to autonomously maintain thermal stability, and initiate reliable communication with orbiting assets or directly to Earth, while maintaining their energy balance. This paper describes the system fault protection design for the surface phase of the mission, including hardware descriptions and software algorithms. Additionally, a few in-flight experiences are described, including the Spirit flash memory anomaly and the Opportunity "stuck-on" heater failure.} } - Lumnah, A., Pujari, S. and Sereno, V. (2024). Driving Down Risk in the Psyche Fault Protection Design Post Launch Slip
. International Symposium on Experimental Robotics. Source
BibTeX
@inproceedings{lumnah2024driving, title = {Driving Down Risk in the Psyche Fault Protection Design Post Launch Slip}, author = {Lumnah, Alexander and Pujari, Swapnil and Sereno, Virginia}, booktitle = {International Symposium on Experimental Robotics}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.wdvmh8}, abstract = {The Psyche Mission is a NASA Discovery-class Mission to explore (16) Psyche, a large metallic asteroid that orbits the sun between 2.5 and 3.3 au. The spacecraft bus is a repurposed earth-orbiting telecommunication satellite bus developed by Maxar, combined with Avionics and software developed by JPL. To ensure this earth-orbiting spacecraft bus can survive the lengthy journey into deep space, a robust fault protection function was designed, implemented, and tested. Originally scheduled for July 2022, the launch date was postponed to October 2023 due to delays during system-level testing of the spacecraft. By the time the launch slip was announced, the fault protection design was fully implemented in software, and the V&V program was nearly complete. Consequently, the team found themselves with an additional year of unplanned development time, which provided the unique opportunity to revisit parts of the fault protection design, implementation, and V&V strategy prior to launch, while incorporating lessons learned from the previous year of testing.This paper provides an overview of the efforts taken to drive down risk in the Psyche fault protection design after the launch slip. These efforts can be split into three categories: additional “deep dive” analyses targeting higher risk areas of the design, improvements to the design and implementation that resulted in software changes, and the development of a rich set of high-fidelity risk reduction test cases meant to validate the fault protection function. This paper discusses the motivating concerns that drove each of these efforts and explains how lessons learned were incorporated into the post-launch slip development work. It summarizes the analyses that were spawned and explains the methods that were used to constrain and complete each analysis. It captures the trades made when deciding which design changes and software bug fixes to implement, and describes the processes used to implement and verify those changes in an agile manner. Finally, the paper captures the brainstorming process for devising a set of risk reduction tests used to improve confidence in the fault protection design, and validate its performance over a wide range of scenarios.} } - Rink, K., Boehmer, R., Kaplan, K., Larsen, R., Clark, J. and Neilson, T. (2023). Martian Mayday: The Evolution of Curiosity's Safe Mode Communication Over Ten Years
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{rink2023martian, title = {Martian Mayday: The Evolution of Curiosity's Safe Mode Communication Over Ten Years}, author = {Rink, Kimberly and Boehmer, Rudy and Kaplan, Kyle and Larsen, Reidar and Clark, Jessica and Neilson, Tracy}, booktitle = {IEEE Aerospace Conference}, pages = {1-12}, address = {Big Sky, Montana}, year = {2023}, doi = {10.1109/aero58975.2024.10521326}, abstract = {When the Curiosity Mars rover encounters a serious fault, it enters a configuration called safe mode. Curiosity’s autonomous safe mode behavior must keep the rover communicative and stable until the operations team can triage the issue and send recovery commands. In safe mode, Curiosity follows a preset schedule of windows that specify the antenna, telemetry for transmission, and solar time of each communication opportunity. The timing of these windows, called system fault protection (SFP) windows, is crucial for Curiosity to maintain both communication and power-positivity, or generating more energy that consumed. Not only do SFP windows dictate when Curiosity attempts to communicate over its ultra-high frequency and X-band radios, they also largely control the rover’s power consumption by dictating when its primary computer powers on and off, known as awake and sleep states. Because Curiosity is power-negative when awake, sleep time is necessary to charge its batteries to a higher state of charge than the previous sol, or Martian day.During Curiosity’s prime mission, fault protection engineers regularly updated SFP windows to accommodate changing Mars relay orbits and relative geometry of Earth and Mars. The initial SFP windows at landing directed Curiosity to stay awake for nine Martian hours of communication each sol. This design allowed enough sleep time for Curiosity to increase the state of charge of its batteries by 22% over a single sol in safe mode. But as the mission progressed, updates to SFP windows were additionally driven by Curiosity’s aging power source, which continuously requires increased sleep time to maintain power-positivity. As of 2023, 6.6 hours of safe mode communication per sol will only increase the battery state of charge by 5.5%. Secondary factors that were not present during Curiosity’s prime mission—including changing uplink strategies and Mars relay infrastructure—have introduced new challenges to updating SFP windows. The process of selecting SFP window times has evolved into an iterative analysis that must consider several dynamic operational factors to achieve a balance of communication time and power consumption. By using this analysis to converge on a design that satisfies energy requirements and desired communication opportunities, fault protection engineers ensure Curiosity’s safe mode configuration in its extended mission remains truly safe. This paper discusses how Curiosity uses SFP windows to communicate in safe mode, the factors that influence how SFP windows are designed, and how both the design process and the windows themselves have changed over ten years of surface operations.} } - Matijevic, J. and Dewell, E. (2005). Anomaly Recovery and the Mars Exploration Rovers
. SpaceOps Conference. Source
BibTeX
@inproceedings{matijevic2005anomaly, title = {Anomaly Recovery and the Mars Exploration Rovers}, author = {Matijevic, Jacob and Dewell, Emily}, booktitle = {SpaceOps Conference}, year = {2005}, doi = {10.2514/6.2006-5957}, abstract = {The premise of the design of operations for the Mars Exploration Rovers (MER) is that the vehicles will drive each day. As a result, they will encounter some aspect of the terrain environment that cannot be anticipated or otherwise accommodated by the sequences linked onboard that day. The operations team then must correct the problem by planning then commanding the execution of a different drive the next day. Often other aspects of the operation on the surface of Mars: environmental changes, component degradation, errors in sequence design or execution, etc., lead to anomalies which must be addressed before normal operations can resume. The operational design that makes it possible to recover from a driving error each day also reduces the time needed to recover from anomalies. As an example of the efficiency achieved, less than 5% (about 30 sols out of 700 sols of operations) of the time on the surface has been devoted to recovery from anomalies for each vehicle. In this paper the major anomalies experienced by the MER rovers will be recounted and the streamlined approaches to addressing these problems described. The operational flexibility developed for these missions is also a function of the system design that anticipated a number of likely faults and conditions arising from uncertainty in sequence execution and environmental change. This design will be described as well as the considerations in operation that motivated this design. These considerations will likely be present in any future surface mission.} } - Rankin, A., Maimone, M., Biesiadecki, J., Patel, N., Levine, D. and Toupet, O. (2020). Driving Curiosity: Mars Rover Mobility Trends During the First Seven Years
. IEEE Aerospace Conference, 20220000780. Source
BibTeX
@inproceedings{rankin2020driving, title = {Driving Curiosity: Mars Rover Mobility Trends During the First Seven Years}, author = {Rankin, Arturo and Maimone, Mark and Biesiadecki, Jeffrey and Patel, Nikunj and Levine, Dan and Toupet, Olivier}, booktitle = {IEEE Aerospace Conference}, number = {20220000780}, pages = {1-19}, institution = {NASA}, year = {2020}, doi = {10.1109/aero47225.2020.9172469}, abstract = {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, A., Maimone, M., Biesiadecki, J., Patel, N., Levine, D. and Toupet, O. (2021). Mars Curiosity Rover Mobility Trends During the First Seven Years
. Journal of Field Robotics, 5. Source
BibTeX
@article{rankin2021mars, title = {Mars Curiosity Rover Mobility Trends During the First Seven Years}, author = {Rankin, Arturo and Maimone, Mark and Biesiadecki, Jeffrey and Patel, Nikunj and Levine, Dan and Toupet, Olivier}, journal = {Journal of Field Robotics}, volume = {38}, number = {5}, pages = {759--800}, year = {2021}, doi = {10.1002/rob.22011}, abstract = {Abstract NASA's Mars Science Laboratory (MSL) Curiosity rover landed on Mars on August 6, 2012. In the 7 years between landing and August 6, 2019 (sol 2488), Curiosity has driven 21,318.5 m 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 cm to its longest drive of 142.5 m, with an average drive distance of 28.9 m. Real‐time human intervention is not possible during Curiosity's drives due to the latency in uplinking commands and downlinking telemetry. Instead, the operations team relies on Curiosity's fault protection, autonomous navigation, and visual odometry software to keep the rover safe during drives. During its first 7 years on Mars, Curiosity has attempted 738 drives. While 622 drives ran to completion, 116 drives were prevented or stopped early by Curiosity's fault protection software. The primary risks to mobility success have been wheel damage, wheel entrapment, progressive wheel sinkage, and the potential for hardware or cable failures that result in an inability to command one or more steer or drive actuators. In this paper, we describe Curiosity's mobility subsystem, mobility trends over the first 21.3 km of the mission, operational aspects of mobility fault protection, risks to continued mobility success, and risk mitigation strategies.} } - Clark, J. J., Lam, M., DuCharme, L., Lumnah, A. and Morantz, C. (2022). Validation of the Mars 2020 Fault Protection Design: Navigating the Infinity of the Off-Nominal
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{clark2022validation, title = {Validation of the Mars 2020 Fault Protection Design: Navigating the Infinity of the Off-Nominal}, author = {Clark, Jessica J and Lam, Mary and DuCharme, Lauren and Lumnah, Alex and Morantz, Chaz}, booktitle = {IEEE Aerospace Conference}, pages = {1-8}, publisher = {IEEE}, year = {2022}, doi = {10.1109/aero53065.2022.9843661}, abstract = {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.} } - Ingham, M. and Robertson, P. (2005). Model-based autonomy
. IEEE Systems, Man, and Cybernetics Conference. Source
BibTeX
@inproceedings{ingham2005model, title = {Model-based autonomy}, author = {Ingham, Michel and Robertson, Paul}, booktitle = {IEEE Systems, Man, and Cybernetics Conference}, year = {2005}, url = {https://ntrs.nasa.gov/citations/20060043275} } - Rasmussen, R. D. (2008). GN&C Fault Protection Fundamentals, 20100020171. ntrs.nasa.gov/citations/20100020171
BibTeX
@misc{rasmussen2008gnc, title = {{GN\&C} Fault Protection Fundamentals}, author = {Rasmussen, Robert D.}, howpublished = {Presentation at the Jet Propulsion Laboratory, California Institute of Technology}, number = {20100020171}, year = {2008}, url = {https://ntrs.nasa.gov/citations/20100020171}, abstract = {This is a companion presentation for a paper by the same name for the same conference. The objective of this paper is to shed some light on the fundamentals of fault tolerant design for GN&C. The common heritage of ideas behind both faulted and normal operation is explored, as is the increasingly indistinct line between these realms in complex missions. Techniques in common practice are then evaluated in this light to suggest a better direction for future efforts.} } - Pell, B., Bernard, D. E., Chien, S., Gat, E., Muscettola, N., Nayak, P. P., Wagner, M. D. and Williams, B. C. (1996). A Remote Agent Prototype for Spacecraft Autonomy
. Space Sciencecraft Control and Tracking in the New Millennium. Source
BibTeX
@inproceedings{pell1996remote, title = {A Remote Agent Prototype for Spacecraft Autonomy}, author = {Pell, Barney and Bernard, Douglas E. and Chien, Steve and Gat, Erann and Muscettola, Nicola and Nayak, P. P. and Wagner, Michael D. and Williams, Brian C.}, booktitle = {Space Sciencecraft Control and Tracking in the New Millennium}, series = {SPIE Proceedings}, volume = {2810}, pages = {74-90}, year = {1996}, doi = {10.1117/12.255150}, abstract = {NASA has recently announced the New Millennium Program (NMP) to develop 'faster, better, cheaper' spacecraft in order to establish a 'virtual presence' in space. A crucial element in achieving this vision is onboard spacecraft autonomy, requiring us to automate functions which have traditionally been achieved on ground by humans. These include planning activities, sequencing spacecraft actions, tracking spacecraft state, ensuring correct functioning, recovering in cases of failure and reconfiguring hardware. In response to these challenging requirements, we analyzed the spacecraft domain to determine its unique properties and developed an architecture which provided the required functionality. This architecture integrates traditional real-time monitoring and control with constraint-based planning and scheduling, robust multi-threaded execution, and model-based diagnosis and reconfiguration. In a five month effort we successfully demonstrated this implemented architecture in the context of an autonomous insertion of a simulated spacecraft into orbit around Saturn, trading off science and engineering goals, and achieving the mission goals in the face of any single point of hardware failure. This scenario turned out to be among the most complex handled by each of the component technologies. As a result of this success, the integrated architecture has been selected to control the first NMP flight, Deep Space One, in 1998. It will be the first AI system to autonomously control an actual spacecraft.} } - Fesq, L. M. and Jacome, R. W. (2015). Developing a fault management guidebook for NASA's deep space robotic missions
. AIAA Infotech @ Aerospace. Source
BibTeX
@inproceedings{fesq2015developing, title = {Developing a fault management guidebook for NASA's deep space robotic missions}, author = {Fesq, Lorraine M. and Jacome, Raquel W.}, booktitle = {AIAA Infotech @ Aerospace}, publisher = {American Institute of Aeronautics and Astronautics}, year = {2015}, doi = {10.2514/6.2015-1795}, abstract = {NASA designs and builds systems that achieve incredibly ambitious goals, as evidenced by the Curiosity rover traversing on Mars, the highly complex International Space Station orbiting our Earth, and the compelling plans for capturing, retrieving and redirecting an asteroid into a lunar orbit to create a nearby a target to be investigated by astronauts. In order to accomplish these feats, the missions must be imbued with sufficient knowledge and capability not only to realize the goals, but also to identify and respond to off-nominal conditions. Fault Management (FM) is the discipline of establishing how a system will respond to preserve its ability to function even in the presence of faults. In 2012, NASA released a draft FM Handbook in an attempt to coalesce the field by establishing a unified terminology and a common process for designing FM mechanisms. However, FM approaches are very diverse across NASA, especially between the different mission types such as Earth orbiters, launch vehicles, deep space robotic vehicles and human spaceflight missions, and the authors were challenged to capture and represent all of these views. The authors recognized that a necessary precursor step is for each sub-community to codify its FM policies, practices and approaches in individual, focused guidebooks. Then, the sub-communities can look across NASA to better understand the different ways off-nominal conditions are addressed, and to seek commonality or at least an understanding of the multitude of FM approaches. This paper describes the development of the Space Robotic Fault Management Guidebook, which is intended to be the first of NASA's FM guidebooks. Its purpose is to be a field-guide for FM practitioners working on deep space robotic missions, as well as a planning tool for project managers. Publication of this Deep Space Robotic FM Guidebook is expected in early 2015. The guidebook will be posted on NASA's Engineering Network on the FM Community of Practice website so that it will be available to all NASA projects. Future plans for subsequent guidebooks for the other NASA sub-communities are proposed.} } - Fesq, L. (2017). New developments in ISHM for NASA robotic flight systems. dataverse.jpl.nasa.gov/dataset.xhtml
BibTeX
@misc{fesq2017new, title = {New developments in ISHM for NASA robotic flight systems}, author = {Fesq, Lorraine}, year = {2017}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/47330} } - Sherwood, R., Chien, S., Tran, D., Cichy, B., Castano, R., Davies, A. and Rabideau, G. (2005). An expert system for autonomous spacecraft control
. Annual Guidance and Control Conference. Source
BibTeX
@inproceedings{sherwood2005expert, title = {An expert system for autonomous spacecraft control}, author = {Sherwood, Rob and Chien, Steve and Tran, Daniel and Cichy, Benjamin and Castano, Rebecca and Davies, Ashley and Rabideau, Gregg}, booktitle = {Annual Guidance and Control Conference}, publisher = {JPL Open Repository}, year = {2005}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/41182} } - Avizienis, A. (1967). Design of Fault-Tolerant Computers
. November 14-16, Fall Joint Computer Conference. Source
BibTeX
@inproceedings{avizienis1967design, title = {Design of Fault-Tolerant Computers}, author = {Avizienis, Algirdas}, booktitle = {November 14-16, Fall Joint Computer Conference}, pages = {733}, year = {1967}, doi = {10.1145/1465611.1465708}, abstract = {Reliable performance of hardware has been a requirement for digital systems since the construction of the first digital computer. Improper functioning of the logic circuits in a digital system is manifested by logic faults, which are defined for this paper as "permanent or transient deviations of logic variables from the values specified in design."} } - Goldberg, J., Green, M. W., Kautz, W. H., Levitt, K. N., Melliar-Smith, P. M., Schwartz, R. L. and Weinstock, C. B. (1984). Development and Analysis of the Software Implemented Fault-Tolerance (SIFT) Computer
. SRI International for NASA Langley Research Center, NASA CR-172146. Source
BibTeX
@techreport{goldberg1984development, title = {Development and Analysis of the Software Implemented Fault-Tolerance (SIFT) Computer}, author = {Goldberg, Jack and Green, Milton W. and Kautz, William H. and Levitt, Karl N. and Melliar-Smith, P. Michael and Schwartz, Richard L. and Weinstock, Charles B.}, number = {NASA CR-172146}, institution = {SRI International for NASA Langley Research Center}, year = {1984}, url = {https://ntrs.nasa.gov/citations/19840010885}, abstract = {SIFT (Software Implemented Fault Tolerance) is an experimental, fault-tolerant computer system designed to meet the extreme reliability requirements for safety-critical functions in advanced aircraft. Errors are masked by performing a majority voting operation over the results of identical computations, and faulty processors are removed from service by reassigning computations to the nonfaulty processors. This scheme has been implemented in a special architecture using a set of standard Bendix BDX930 processors, augmented by a special asynchronous-broadcast communication interface that provides direct, processor to processor communication among all processors. Fault isolation is accomplished in hardware; all other fault-tolerance functions, together with scheduling and synchronization are implemented exclusively by executive system software. The system reliability is predicted by a Markov model. Mathematical consistency of the system software with respect to the reliability model has been partially verified, using recently developed tools for machine-aided proof of program correctness.} } - Dvorak, D. (2009). NASA Study on Flight Software Complexity
. AIAA Infotech@Aerospace Conference. Source
BibTeX
@inproceedings{dvorak2009nasa, title = {NASA Study on Flight Software Complexity}, author = {Dvorak, Daniel}, booktitle = {AIAA Infotech@Aerospace Conference}, year = {2009}, doi = {10.2514/6.2009-1882}, abstract = {In 2007 the NASA Office of Chief Engineer commissioned a multi-center study to bring forth technical and managerial strategies to address risks from growth in size and complexity of flight software in NASA’s space missions. The motivation for the study grew from problems attributed to flight software in a variety of missions—in both pre-launch and post-launch activities—and concerns that such problems were growing with the expanding role of flight software. The study was tasked to examine the growth in flight software size and complexity, recommend ways to reduce and better manage complexity, and identify methods of testing complex logic. This report examines complexity throughout the engineering lifecycle—from requirements definition through design, development, verification, and operations—and presents sixteen findings and associated recommendations.} } - Brown, J. (2008). Cassini Attitude Control Flight Software: From Development to In-Flight Operation
. AIAA Guidance, Navigation, and Control Conference. Source
BibTeX
@inproceedings{brown2008cassini, title = {Cassini Attitude Control Flight Software: From Development to In-Flight Operation}, author = {Brown, Jay}, booktitle = {AIAA Guidance, Navigation, and Control Conference}, volume = {88}, year = {2008}, doi = {10.2514/6.2008-6806}, abstract = {The Cassini Attitude and Articulation Control Subsystem (AACS) Flight Software (FSW) has achieved its intended design goals by successfully guiding and controlling the Cassini-Huygens planetary mission to Saturn and its moons. This paper describes an overview of AACS FSW details from early design, development, implementation, and test to its fruition of operating and maintaining spacecraft control over an eleven year prime mission. Starting from phases of FSW development, topics expand to FSW development methodology, achievements utilizing in-flight autonomy, and summarize lessons learned during flight operations which can be useful to FSW in current and future spacecraft missions.} } - Reeves, G. E. and Neilson, T. A. (2005). The Mars Rover Spirit FLASH Anomaly
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{reeves2005mars, title = {The Mars Rover Spirit FLASH Anomaly}, author = {Reeves, Glenn E. and Neilson, Tracy A.}, booktitle = {IEEE Aerospace Conference}, pages = {4186-4199}, address = {Big Sky, Montana}, year = {2005}, doi = {10.1109/aero.2005.1559723}, abstract = {The Mars Exploration Rover "Spirit" suffered a debilitating anomaly that prevented communication with Earth for several anxious days. With the eyes of the world upon us, the anomaly team used each scrap of information, our knowledge of the system, and sheer determination to analyze and fix the problem, then return the vehicle to normal operation. This paper will discuss the Spirit FLASH anomaly, including the drama of the investigation, the root cause and the lessons learned from the experience} } - National Aeronautics and Space Administration. (2013). Mars Science Laboratory (MSL) Sol-200 Anomaly
. NASA Lessons Learned Information System, Lesson No. 11201. Source
BibTeX
@techreport{nasa2013msl, title = {Mars Science Laboratory (MSL) Sol-200 Anomaly}, author = {{National Aeronautics} and {Space Administration}}, number = {Lesson No. 11201}, institution = {NASA Lessons Learned Information System}, type = {Lessons Learned Entry}, year = {2013}, url = {https://www.nongnu.org/lzip/msl-sol-200-anomaly.html} } - Pujari, S., Summer, J., Sereno, V. and Lumnah, A. (2024). Two Steps Forward: Evolving Psyche's Fault Protection Validation Post-Launch Slip
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{pujari2024two, title = {Two Steps Forward: Evolving Psyche's Fault Protection Validation Post-Launch Slip}, author = {Pujari, Swapnil and Summer, Jonathan and Sereno, Virginia and Lumnah, Alexander}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.grmhhb}, abstract = {On October 5th, 2023, the Psyche Mission is targeted to launch to the large metallic asteroid (16) Psyche that will be exploring the exposed core material of a differentiated planetesimal-class asteroid. This unique NASA Discovery-class Mission combines a Solar Electric Propulsion (SEP) Chassis from Maxar Technologies with JPL’s contribution of avionics, flight software, and fault protection design. The Psyche Fault Protection (FP), implemented as autonomous algorithms, can detect, isolate, respond to, and recover from off-nominal conditions that may prevent mission success.The FP Verification and Validation (V&V) campaign involved numerous types of testing including FP infrastructure, monitor & response end-to-end (E2E) functionality, scenario testing, and stress and robustness testing across both high and low-fidelity venues. Due to delays in system level software testing, Psyche had to reschedule its original launch window from July 2022 to October 2023. This paper focuses on how the V&V campaign was scoped and executed prior to the launch slip and then improved after the launch slip. Adaptations included testing a comprehensive E2E regression test suite by targeting updates made to the GNC FP design, a streamlined data execution that employed variance of initial conditions and a consistent test procedure, and a robust and efficient data review strategy including tooling to automate checks. By capitalizing on the additional time, resources, and insights gained from Psyche’s launch slip, the Fault Protection V&V campaign benefited from a more comprehensive and rigorous validation process. This paper captures the knowledge and processes employed to validating Psyche’s Fault Protection design such that future FP V&V campaigns can benefit from more robust testing.} } - Srivastava, P., Bates-Tarasewicz, H. A., Cloutier, K. D., De Soria-Santacruz Pich, M., Lumnah, A. J. and Wilkerson, M. (2024). Psyche's Payload Fault Protection Design and Strategy for Launch Readiness
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{srivastava2024psyche, title = {Psyche's Payload Fault Protection Design and Strategy for Launch Readiness}, author = {Srivastava, Priyanka and Bates-Tarasewicz, Haley A. and Cloutier, Kyle D. and De Soria-Santacruz Pich, Maria and Lumnah, Alexander J. and Wilkerson, Marcus}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.ivff4w}, abstract = {NASA's Psyche mission is a journey to the unique metal-rich (16) Psyche asteroid orbiting the Sun between Mars and Jupiter to get a better insight into the Earth's core and the core of other terrestrial planets. The mission will offer a unique scientific value by mapping the asteroid and studying its properties with the help of a robust Spacecraft that carries a highly capable Payload suite onboard. Psyche's Payload suite is a novel collection of heritage and technology demonstration instruments. Heritage instruments include a Multispectral Imager, a Magnetometer, and a Gamma Ray and Neutron Spectrometer. The Deep Space Optical Communications (DSOC) instrument is a Class D technology demonstration that will perform optical communications at AU-magnitude distances. The Spacecraft will need to survive in vaguely known environments and with a wide range of uncertainties from the time of Launch to the Psyche Science Orbital Operations period. Most of these instruments will be functioning at the same time in conjunction with the rest of the subsystems, and with limited contact with the ground operations team on Earth. To ensure that the Spacecraft and instruments are robust to possible anomalies and can remain healthy and functional to meet the science goals and overall mission success criteria, Psyche's Fault Protection (FP) and Payload teams designed and implemented an autonomous onboard fault management architecture and engine. This Flight Software-based autonomy will execute fault detection, isolation and perform health recovery actions to prevent propagation of anomalous behavior between the instruments and the rest of the Spacecraft. This paper details the history of how Psyche’s Payload Fault Protection design evolved and was fine-tuned through a rigorous testing and analysis campaign to address the needs and challenges of the diverse set of instruments. It describes the key lessons learned, including the ones that emerged post launch-slip in the year 2022, and how a shift in the FP Verification and Validation (V&V) strategy helped the team gain increased confidence in the instruments for Launch readiness in 2023.} } - Arthur, P., Navarro, J., Sover, K., Sternberg, D. and Twu, P. (2024). Psyche Mission System Level Guidance, Navigation, and Control Off-Nominal Testing
. IEEE Microwave Theory and Techniques Society Chapter. Source
BibTeX
@inproceedings{arthur2024psyche, title = {Psyche Mission System Level Guidance, Navigation, and Control Off-Nominal Testing}, author = {Arthur, Paige and Navarro, Jessica and Sover, Kimberly and Sternberg, David and Twu, Philip}, booktitle = {IEEE Microwave Theory and Techniques Society Chapter}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.ttjou7} } - Neilson, T. A. and Manning, R. M. (2013). Curiosity's autonomous surface safing behavior design
. AIAA SPACE Conference. Source
BibTeX
@inproceedings{neilson2013curiosity, title = {Curiosity's autonomous surface safing behavior design}, author = {Neilson, Tracy A. and Manning, Robert M.}, booktitle = {AIAA SPACE Conference}, publisher = {JPL Open Repository}, year = {2013}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/44367} } - Bates, D., Lee, A., Meakin, P. and Weitl, R. (2013). Fault protection design and testing for the Cassini spacecraft in a "mixed" thruster configuration
. AIAA Guidance, Navigation, and Control Conference. Source
BibTeX
@inproceedings{bates2013fault, title = {Fault protection design and testing for the Cassini spacecraft in a "mixed" thruster configuration}, author = {Bates, David and Lee, Allan and Meakin, Peter and Weitl, Raquel}, booktitle = {AIAA Guidance, Navigation, and Control Conference}, publisher = {American Institute of Aeronautics and Astronautics}, year = {2013}, doi = {10.2514/6.2013-4632} } - Heverly, M. and Bareh, M. (2026). The Impact of Major Anomalies of Robotic Mars Surface Missions on Mission Timeline
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{heverly2026impact, title = {The Impact of Major Anomalies of Robotic Mars Surface Missions on Mission Timeline}, author = {Heverly, Matt and Bareh, Magdy}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2026}, doi = {10.48577/jpl.zlcejq} } - Mackey, R. M., Nikora, A., Altenbuchner, C., Bocchino, R., Sievers, M., Fesq, L., Kolcio, K. O., Litke, M. J. and Prather, M. (2021). On-Board Model Based Fault Diagnosis for CubeSat Attitude Control Subsystem: Flight Data Results
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{mackey2021board, title = {On-Board Model Based Fault Diagnosis for CubeSat Attitude Control Subsystem: Flight Data Results}, author = {Mackey, Ryan M and Nikora, Allen and Altenbuchner, Cornelia and Bocchino, Robert and Sievers, Michael and Fesq, Lorraine and Kolcio, Ksenia O. and Litke, Matthew J. and Prather, Maurice}, booktitle = {IEEE Aerospace Conference}, pages = {1-17}, publisher = {IEEE}, year = {2021}, doi = {10.1109/aero50100.2021.9438342}, abstract = {Self-sufficient, robotic spacecraft require estimates of their hardware health state in order to project future system state and plan actions toward achieving mission goals. In this paper, we report on integration of a Model-Based Fault Diagnosis (MBFD) model and reasoning engine into flight software leveraging the Arcsecond Space Telescope Enabling Research in Astrophysics (ASTERIA) mission, including test results against captured flight data using the ASTERIA system testbed. Our effort integrated the Model-based Off-Nominal State Identification and Detection (MONSID) model-based reasoning system, developed by Okean Solutions, into ASTERIA flight software using the F Prime software framework. The MONSID engine was supplied with a model of the Blue Canyon Technologies XACT attitude control system (ACS) and tested against flight data and seeded fault tests. While we were unable to conduct an on-board experiment due to the premature loss of ASTERIA, our effort proved the feasibility of on-board model-based fault management, demonstrating reliable and accurate diagnosis using captured data, and further supporting a closed-loop spacecraft autonomy demonstration including autonomous navigation in off-nominal conditions.} } - Nikora, A., Aleem, M., Mackey, R., Fesq, L., Chung, S., Kolcio, K., Prather, M. and Matthew, L. (2020). Demonstrating Assurance of Model-Based Fault Diagnosis Systems on an Operational Mission
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{nikora2020demonstrating, title = {Demonstrating Assurance of Model-Based Fault Diagnosis Systems on an Operational Mission}, author = {Nikora, Allen and Aleem, Mishaal and Mackey, Ryan and Fesq, Lorraine and Chung, Seung and Kolcio, Ksenia and Prather, Maurice and Matthew, Litke}, booktitle = {IEEE Aerospace Conference}, pages = {1-16}, publisher = {IEEE}, year = {2020}, doi = {10.1109/aero47225.2020.9172282}, abstract = {Developers of robotic scientific and commercial spacecraft are trending towards use of onboard autonomous capabilities for responding quickly to dynamic environments and rapidly changing situations. These capabilities need to know the state of the spacecraft's health. Model-based fault diagnosis (MBFD) is an approach to estimating health by continuously verifying accurate behavior and diagnosing off-nominal behavior. Proper functioning of MBFD depends on 1) the quality of the diagnostic system model that is analyzed and compared to commands and onboard measurements to estimate a system's health state, and 2) the correct functionality of the diagnosis engine interrogating the model and comparing its analyses to observed system behavior. Our goal is to develop Verification and Validation (V&V) techniques for MBFD to provide future missions sufficient confidence in its functionality and performance to deploy it on the systems they develop. Our work has been focused on infusing the techniques we developed earlier to an operational mission. First, we are constructing diagnostic models of a spacecraft attitude control system and updating our diagnostic engine so they can be demonstrated aboard the Arcsecond Space Telescope Enabling Research in Astrophysics (ASTERIA) mission, an operational spacecraft for which experiments in autonomy are being planned and executed, using the V&V techniques we have previously developed to assure they are both correct and complete. Since it is nearing the end of its life, ASTERIA provides a unique opportunity to demonstrate MBFD since the monitored components are expected to fail. Our demonstration will give system developers additional confidence to make timely, informed MBFD deployment decisions. Second, we will be completing performance assessments of the diagnostic engine/diagnostic model ensemble both on the flight system and ground-based testbeds to gain confidence in MBFD's ability to run successfully in a spacecraft's resource-constrained environment without adversely affecting other on-board activities. Finally, we are capturing our experience in preparing this demonstration in a set of checklists and guidance documents. Current practice includes high-level institutional guidance documents and standards, but at a high level of abstraction that does not necessarily address specific MBFD concerns. The purpose of the new checklists is to provide future mission developers clear, unambiguous, procedure-oriented guidance on assuring MBFD. This paper describes our work in these areas. For the first area, we describe the diagnostic models and updated diagnostic engine that will be used for the on-board demonstration. We describe how the V&V techniques we developed earlier are used to assure model and engine correctness and completeness. For the second area, we identify the performance measurement and assessment techniques used to characterize the diagnostic engine and diagnostic models, and discuss the effect of measured performance on overall mission operation. Finally, we present the checklist and guidance documents and describe how they meet the goals of providing system developers with clear, unambiguous, procedure-oriented guidance on MBFD assurance. We show how the techniques we have developed map into those artifacts.} } - Ratadiya, P., Alimo, R., Kahovec, B., Vatan, F. and Gilbert, W. (2024). RAMAN: Robust Approaches for Multimodal Anomaly Detection in Mars Rover Power Systems
. NASA Undergraduate Student Research Program. Source
BibTeX
@inproceedings{ratadiya2024raman, title = {RAMAN: Robust Approaches for Multimodal Anomaly Detection in Mars Rover Power Systems}, author = {Ratadiya, Pratik and Alimo, Ryan and Kahovec, Brian and Vatan, Farrokh and Gilbert, William}, booktitle = {NASA Undergraduate Student Research Program}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.9napfq}, abstract = {This paper proposes RAMAN, a framework of approaches for multimodal anomaly detection that is robust to multiple anomaly types, input data, and domain constraints for the Mars Science Laboratory (MSL) power subsystem. Existing anomaly detection systems focus on a subset of anomalies and require a human expert for verification, making the process prone to bias and scaling issues. RAMAN combines the strengths of unsupervised feature extraction methods with the domain knowledge of Martian power systems. It uses thresholding methods based on architectures like autoencoders and spline approximations to find anomalies in different data modalities. The system is evaluated on the power systems data of the Curiosity rover and preliminary results show that it outperforms existing baselines while also scoring high on qualitative evaluation from field experts. The main strengths of RAMAN are its unit composition that helps detect anomalies in subsystems, easy extension to other Martian and non-Martian systems, and easy usability through interactive interfaces.} } - Biberstein, J., Karaman, S., De Weck, O., Sternberg, D., Fesq, L., Kolcio, K. and Prather, M. (2026). Graceful Degradation of Spacecraft Capabilities with Simulated Component Failure
. Intersociety Energy Conversion Engineering Conference. Source
BibTeX
@inproceedings{biberstein2026graceful, title = {Graceful Degradation of Spacecraft Capabilities with Simulated Component Failure}, author = {Biberstein, Josef and Karaman, Sertac and De Weck, Olivier and Sternberg, David and Fesq, Lorraine and Kolcio, Ksenia and Prather, Maurice}, booktitle = {Intersociety Energy Conversion Engineering Conference}, publisher = {JPL Open Repository}, year = {2026}, doi = {10.48577/jpl.xbi72d}, abstract = {Development of fault detection, identification, and recovery systems for space missions requires engineers to consider interactions among all spacecraft subsystems. These systems must be robust and rigorously tested so as to not cause harm to the spacecraft. Combined with the complexity of the interactions that must be considered, this leads to conservative approaches even in modern spacecraft where the system includes redundant components, yet the response to most faults is to transition to safe mode and wait for intervention from the ground. However, a single fault may not disable a spacecraft to an extent which precludes continued operation, especially in spacecraft with redundant components. In this case, transitioning to safe mode and waiting for human intervention leads to mission downtime which impacts spacecraft performance and could be avoided. In this work, we prototype a new framework for fault detection, identification, and recovery that introduces graceful degradation of spacecraft capability in the presence of component failure. To demonstrate our framework, we focus on the attitude control subsystem. We simulate using the syssim library, a software package that enables the modular modeling of arbitrary dynamical systems with a robust and expressive API for defining faults to be injected at runtime. The MONSID library — a model-based health assessment software based on the technique of constraint suspension developed by Okean Solutions — is used in the loop for fault detection and diagnosis. We evaluate the performance of this ensemble on a non-trivial cascading fault in a set of sensors associated with an attitude control system. Graceful degradation is demonstrated across groups of redundant components that allow the spacecraft to continue operation even when a single component, such as a reaction wheel or gyroscope, has failed.} } - Troesch, M., Mirza, F., Hughes, K., Rothstein-Dowden, A., Bocchino, R., Donner, A., Feather, M., Smith, B., Fesq, L., Barker, B. and Campuzano, B. (2020). MEXEC: An Onboard Integrated Planning and Execution Approach for Spacecraft Commanding
. Workshop on Integrated Execution / Goal Reasoning. Source
BibTeX
@inproceedings{troesch2020mexec, title = {MEXEC: An Onboard Integrated Planning and Execution Approach for Spacecraft Commanding}, author = {Troesch, Martina and Mirza, Faiz and Hughes, Kyle and Rothstein-Dowden, Ansel and Bocchino, Robert and Donner, Amanda and Feather, Martin and Smith, Benjamin and Fesq, Lorraine and Barker, Brian and Campuzano, Brian}, booktitle = {Workshop on Integrated Execution / Goal Reasoning}, year = {2020}, url = {https://ai.jpl.nasa.gov/public/papers/IntEx-2020-MEXEC.pdf} } - Claridge, S., Patterson, J., Hasnain, Z., Goel, A., Patterson, K., Rouquette, N. F., Wagner, C., Hasseler, T. D. and Ingham, M. D. (2026). Supervised and Unsupervised Methods for Detecting Anomalies in an Autonomous Long-range Lunar Rover
. EUROPEAN CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY. Source
BibTeX
@inproceedings{claridge2026supervised, title = {Supervised and Unsupervised Methods for Detecting Anomalies in an Autonomous Long-range Lunar Rover}, author = {Claridge, Sofie and Patterson, Jack and Hasnain, Zaki and Goel, Ashish and Patterson, Katharine and Rouquette, Nicolas F. and Wagner, Caleb and Hasseler, Tristan D. and Ingham, Michel D.}, booktitle = {EUROPEAN CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY}, publisher = {JPL Open Repository}, year = {2026}, doi = {10.48577/jpl.kqud0q}, abstract = {Autonomous space systems must navigate complex environments and accomplish concurrent tasks without continuous input and supervision from human operators. Interactions between subsystems and with the environment may lead to unintended behavior, resulting in downtime, delays, goal degradation, loss of functionality, or even catastrophic failures. The Endurance mission concept requires a lunar rover to traverse thousands of kilometers over a long period of time (multiple years) across the South Pole-Aitken Basin on the far side of the Moon. Onboard system health management is required to detect and diagnose anomalies and faults that pose a risk to mission objectives. To this end, we propose training both unsupervised and supervised machine learning models to detect and diagnose anomalies onboard a rover over the courseof a mission, supported by a pipeline for anomaly data generation that enables training and evaluation. We generate synthetic anomaly signatures using a low-fidelity mission simulator which outputs labeled datasets to enable supervised learning. We present results from a field experiment in which we deploy this supervised model as a ROS network node in a rover-ground network. In parallel, we train unsupervised models to detect anomalies in the mobility system by training on experimental field data and present results which verify the ability to detect anomalies observed by field operators as well as anomalies which were not detected by the operators. Our work demonstrates how machine learning models can detect anomalies onboard by leveraging multiple data sources, including pre-launch test data and operational data from earlier phases of the mission, and provides a pathway for improving anomaly detection as a rover’s mission progresses.} } - Verma, V., Gaines, D., Rabideau, G., Schaffer, S. and Joshi, R. (2017). Autonomous Science Restart for the Planned Europa Mission with Lightweight Planning and Execution
. International Conference on Automated Planning and Scheduling. Source
BibTeX
@inproceedings{verma2017autonomous, title = {Autonomous Science Restart for the Planned Europa Mission with Lightweight Planning and Execution}, author = {Verma, Vandi and Gaines, Dan and Rabideau, Gregg and Schaffer, Steve and Joshi, Rajeev}, booktitle = {International Conference on Automated Planning and Scheduling}, publisher = {JPL Open Repository}, year = {2017}, url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/48030} } - Fesq, L., Beauchamp, P., Altenbuchner, C., Bocchino, R., Feather, M., Hughes, K., Kennedy, B., Mackey, R., Mirza, F., Sternberg, D., Smith, M. W., Troesch, M., Seager, S., Knapp, M., Kolcio, K. and Doran, P. (2021). Results from the ASTERIA CubeSat Extended Mission Experiments
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{fesq2021results, title = {Results from the ASTERIA CubeSat Extended Mission Experiments}, author = {Fesq, Lorraine and Beauchamp, Patricia and Altenbuchner, Cornelia and Bocchino, Rob and Feather, Martin and Hughes, Kyle and Kennedy, Brian and Mackey, Ryan and Mirza, Faiz and Sternberg, David and Smith, Matthew W. and Troesch, Martina and Seager, Sara and Knapp, Mary and Kolcio, Ksenia and Doran, Patrick}, booktitle = {IEEE Aerospace Conference}, pages = {1-11}, publisher = {IEEE}, year = {2021}, doi = {10.1109/aero50100.2021.9438402} } - Gomez, A. R., Hasnain, Z., Ingham, M. D., Chung, S. H. and Williams, B. C. (2026). Scalable Model-Based Discrete Mode Estimation for a Lunar Rover Power System
. International Conference on Space Operations. Source
BibTeX
@inproceedings{gomez2026scalable, title = {Scalable Model-Based Discrete Mode Estimation for a Lunar Rover Power System}, author = {Gomez, Annabel R. and Hasnain, Zaki and Ingham, Michel D. and Chung, Seung H. and Williams, Brian C.}, booktitle = {International Conference on Space Operations}, publisher = {JPL Open Repository}, year = {2026}, doi = {10.48577/jpl.kmuomw}, abstract = {Reliable autonomous operation of planetary rovers requires robust onboard monitoring and diagnosis of power systems under uncertain and dynamic conditions. This work presents a model-based mode estimation framework for a simplified rover power system that combines physics-based modeling with probabilistic reasoning to estimate system and environmental state, including anomalous behavior. The approach adapts the Miniature Mode Estimation (Mini-ME) architecture to perform real-time belief tracking over discrete component modes based on noisy measurement signals including voltage, current, temperature, and state of charge, and command inputs into the system. Mini-ME is a system health management tool that monitors components, diagnoses faults in real-time, and supports downstream system recovery. We simulate the physics of the simplified power system under varying loads using a lumped parameter equivalent circuit model that captures the electrical and thermal behavior of the battery. A compiled automaton is used to encode admissible probabilistic state transitions and observation likelihoods derived from sensor models. By compiling out the combinatorial search and integrating these representations within a Bayesian update process, the system efficiently detects, isolates, and diagnoses anomalies arising from faults or unexpected operating regimes. The simulation results demonstrate accurate recovery of hidden system modes during chargedischarge cycles, illustrating how model-based reasoning supports autonomous fault diagnosis and system health management in autonomous missions. The major contribution of the paper is a thorough set of computational experiments to evaluate the performance of compiled mode estimation, versus uncompiled mode estimation, on space relevant benchmarks.} } - Schaffer, S., Chien, S. and Ferguson, E. (2018). Validation of Fault-Tolerant Plans for Europa Clipper. ntrs.nasa.gov/citations/20210008437
BibTeX
@misc{schaffer2018validation, title = {Validation of Fault-Tolerant Plans for Europa Clipper}, author = {Schaffer, Steve and Chien, Steve and Ferguson, Eric}, year = {2018}, url = {https://ntrs.nasa.gov/citations/20210008437}, abstract = {The Europa Clipper mission will explore that icy moon in a series of brief flybys through the Jovian radiation belts. A single event upset in the spacecraft flight computer during these critical scientific periods could jeopardize the success of the mission. Rather than safing and awaiting operator intervention, the Clipper mission envisions limited onboard autonomy that can restore spacecraft state sufficiently to resume the encounter observation plan as rapidly as possible. The contingency plan is contained in an Activity Restart Timeline (ART) that is transmitted in parallel with the nominal plan, which must be co-validated jointly against all spacecraft state and resource constraints amid unpredictable fault timing. A prototype validation tool was built that leverages declarative spacecraft models and automated search techniques to find such potential inconsistencies in the unified contingent mission plan. Early validation results within motivating scenarios are presented.} } - Ruderman, E. (2024). Redundant Flight Computer and File Partition Maintenance Design for the Mars2020 Mission
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{ruderman2024redundant, title = {Redundant Flight Computer and File Partition Maintenance Design for the Mars2020 Mission}, author = {Ruderman, Evan}, booktitle = {IEEE Aerospace Conference}, publisher = {JPL Open Repository}, year = {2024}, doi = {10.48577/jpl.pz8dkx} }