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...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

processor EDAC parity word) is higher than originally predicted from pre-launch analyses. Any multi-bit errorin the central processor has the potential of forcing a fail-over to the backup processor; this event seriouslydegrades the science data taken by the space vehicle.Lessons:1. Develop and test patch procedures to rapidly correct multi-bit errors via ground command. Developdetailed memory maps sufficient to allow the operations team to identify the potential criticality of anymulti-bit error.2. Design into the codes detailed SEU multi-bit error reporting schemes. The <strong>GP</strong>-B flight computer needsto use a software debug interface to read out the locations of multi-bit errors.3. Choose memory and processor components based on on-orbit performance data when possible. The<strong>GP</strong>-B spacecraft suffered 34 multi-bit errors when pre-launch estimates for the susceptibility of theprocessor memory predicted only one during the mission. Detailed re-analysis during the missionbrought to light flight data from another mission that agreed with our experience, but was not used bythe team during processor memory selection (the data was published, but was not identified at thattime). In lieu of this data, the team should have chosen memory with an established performance record.16.1.2.4 Ground simulator fidelityIssue Summary: <strong>Flight</strong> projects should pay careful attention to ground simulator fidelity.Description of the <strong>GP</strong>-B experience:<strong>GP</strong>-B uses an Integrated Test Facility (ITF) to test and verify flight codes and command sequences for use onorbit. The ITF is a combination of flight-like hardware, hardware dynamics simulators, and software simulatorsto model the operation of the vehicle as a whole in its on-orbit environment. This is a critical development anddebugging tool for the project. While a good model for much of the spacecraft, not all interfaces are includedand some that are provide only static values (they are not dynamic and thus do not respond to spacecraftoperation as one would expect)A number of anomalies have been identified that relate to issues generated due to lack of fidelity of the ITF.Command sequences operated differently on the vehicle because the ITF did not have sufficient fidelity to showresponse, or that the interfaces were incomplete and thus did not respond where the vehicle did.Lessons:1. Manage the simulation facility like the vehicle; devote significant program resources and use aerospacebest practices to maintain the design and configuration of the system.2. Carefully define and broadly communicate the scope of any vehicle or subsystem simulator. Simulators,by their nature, cannot be perfect and including all vehicle features may be prohibitive. However, acareful plan managed by a dedicated team of simulation supervisors – independent from the teamdeveloping the spacecraft – would improve fidelity.3. Include as many interfaces as possible in the model. Wherever possible, use flight-like hardware ratherthan software models of systems. This includes cables built to flight prints.16.1.2.5 Gas thruster contaminationIssue Summary: Gas thrusters are vulnerable to contamination.<strong>Gravity</strong> <strong>Probe</strong> B — <strong>Post</strong> <strong>Flight</strong> Analysis • Final <strong>Report</strong> March 2007 449

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

Saved successfully!

Ooh no, something went wrong!