GP-B Post-Flight Analysis—Final Report - Gravity Probe B - Stanford ...

By a process of elimination, the GP-B Anomaly Review Team concluded that this is probably what happened inthe backup CCCA (main computer) on-board the spacecraft on Friday, March 18, 2005. The flight computermaintains a history of completed instructions up to within one second of executing an instruction in a badmemory location. However, once the watchdog timer expires and the computer reboots, this history is lost.Thus, the occurrence of such an event can only be deduced by eliminating other possible causes.14.1.3 GP-B Safemodes and Anomaly ResolutionConsider the following: GP-B is a unique, once-in-history experiment. Its payload, including the gyroscopes,SQUID readouts, telescope and other instrumentation took over four decades to develop. Once launched, thespacecraft was physically out of our hands, and typically, we only communicated with it about every two hoursvia scheduled telemetry passes. Thus, we entrusted the on-board flight computer (and its backup) with the taskof safeguarding the moment-to-moment health and well-being of this invaluable cargo. How did the GP-Bflight computer accomplish this critically important task? The answer is the safemode subsystem.14.1.3.1 The GP-B Safemode SystemMost autonomous spacecraft have some kind of safemode system on-board. In the case of GP-B, Safemode is anautonomous subsystem of the flight software in the GP-B spacecraft's on-board flight computers. The GP-BSafemode Subsystem is comprised of three parts:1. Safemode Tests—Automatic checks for anomalies in hardware and software data.2. Safemode Masks—Scheme for linking each safemode test with one or more safemode responsesequences.3. Safemode Responses—Pre-programmed command sequences that are activated automatically when acorresponding test fails to provide an expected result.Figure 14-8. Uploading commands to the spacecraft from the MOC, following a B-side computer reboot.These tests and response commands are designed to safeguard various instruments and subsystems on thespacecraft and to automatically place those systems in a known and stable configuration when unexpectedevents occur.For example, one of the tests in the GP-B Safemode Subsystem checks to ensure that the communications linkbetween the on-board flight computer and the GP-B MOC here at Stanford is alive and active. The requirementfor this test is that the flight computer must receive some command from the MOC at least once every 12 hours.If the flight computer does not receive a command within that time frame, we assume that normal telemetry isnot working, and the pre-programmed response commands cause the computer to automatically reboot itselfand then re-establish communication. This test is a variation of the “deadman switch” test used on high-speed406 March 2007 Chapter 14 — Data Collection, Processing & Analysis