12.07.2015 Views

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

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

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

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

When single MBEs did not result in autonomous safemode response, affected memory locations were manuallypatched in order to avoid executing corrupted code or accessing corrupted memory values. The software teamdeveloped a valuable set of tools that allowed rapid identification, diagnosis, and correction of MBEs. Thesetools consisted of realtime diagnostic commands that displayed the address of affected locations in memory andthe (corrupted) value of that memory location. This information allowed software engineers to assess theoperating risk imposed by the MBE, and to verify that the memory location had not been overwritten since theMBE was detected. Occasionally, MBEs would corrupt areas within a data buffer that were overwritten soonafter corruption—these became known as “self-clearing MBEs”. After diagnostic data was collected and itconfirmed that an MBE had occurred, the FSW team utilized the Integrated Test Facility to develop realtimecommands to manually rewrite the affected memory locations to their expected value. The entire process, fromdetection through patching, was routinely performed in less than 6 hours throughout the <strong>GP</strong>B mission. Theplanning and forethought that resulted in this efficient set of tools for correcting MBEs ensured minimal sciencedata loss due to corrupted onboard memory.254 March 2007 Chapter 8 — Other Spacecraft Subsystems Analyses

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!