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.

The software and macro changes resulting from these SCRs were verified and validated using the testssummarized in the Table 8-5. The testing was, naturally, all performed in the ITF to provide the highest fidelityenvironment possible.Table 8-5. Tests Executed and Passed to Verify SCRsTest IDTFSW0013TMSSSCR3242TMSSSCR3243TMSSSCR3243_2TMSSSCR3243_3TMSSSCR3245TMSSSCR3246TMSSSRC3247TMSSSCR3251TMSSSCR3252TMSSSCR3253Test DescriptionGyro Uncage / drag-free, Backup drag-free, drag-free Sensor FailureDrag-free Control Performance VerificationThruster Distribution Algorithm Performance VerificationAdditional Thruster FailureMSS version 3_4_3_0 Unit TestingMode 1B Bias CalculationGndRT v5.1.3 Real-Time Ground System TestingLoss of drag-free Safemode ResponseVMS Macros v2.11 TestSpecial Macros v2.11 TestSafemode Macros v2.11 TestThe implementation of these SCRs took place in two sessions: first the software changes to the ATC andSafemode tests, then the VMS and Safemode macro changes. On June 25, 2004 the ATC S/W Change <strong>Flight</strong>Readiness Review (FRR) was held and approved pending closure of a few tests still in analysis.The process of changing the software in the CCCA is a lengthy one. It is possible to implement patches oroverlays to the RAM but any changes implemented this way would vanish if the computer rebooted andreloaded itself from EEPROM. Instead the EEPROM has to get updated and the preferred, most reliable way toachieve that is to start by loading a new image into the Solid State Recorder (SSR, where there are severalmemory boards dedicated to holding images of the FSW) and then from there into the CCCA EEPROM whilethe CCCA is operating under the Start-UP ROM (SUROM).This was an impressive process. From problem identified in 17 May to software solutions developed, coded,tested, and loaded onto the spacecraft by 30 June with the corresponding VMS, Safemode, and Special macroscoded, tested, and loaded by 3 August. All of this was achieved while the operations team (and note that thedevelopment team was also part of the on-call operations support team) continued with the IOC testing andcalibration on the vehicle.Given an uplink rate of 1024 bps at best and 128 bps at worst the process of uplinking several megabytes of codeis tedious. 3 days was required to load and verify the new CCCA image on the vehicle. The new image wasstarted via a commanded A-side reboot on 29 July 2004 and the final VMS, Safemode, and Special macros wereinstalled on the vehicle by 3 August.8.5.5 Safemode DiscussionAll spacecraft must face the possibility that some critical hardware element will fail, putting the long term safetyof the spacecraft and the mission at risk. The <strong>GP</strong>B <strong>Flight</strong> Software mitigates this risk with its Safemodeapplication. This basic idea of this application is to perform tests on selected telemetry monitors from thehardware or software; tests which compare the measured values of these monitors against limits that can be246 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!