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

Lessons:1. Perform all tests with a realistic signal levels as possible.2. Review test data with manufacturer to ensure as-installed performance matches manufacturer’sspecifications. Projects with existing 4th Generation TDRSS transponders should review their test databefore launch to ensure they do not have the same or similar problems.3. Thermal-Vac unit testing is advisable when reworking frequency characteristics of a unit, given newunderstanding of crystal oscillator performance / frequency variation with pressure environment.4. When testing a unit, a manufacturer should verify that the unit’s performance is both withinspecifications and within family – once a design has been manufactured and tested multiple times, out offamily test results are a good indication of possible manufacturing flaws. Additionally, requirementsneed to be evaluated to determine if they should be tightened to assure adequate on-orbit performance.5. Test configurations should be optimized to monitor RF system performance at all times – the ability toflag anomalous telemetry and compare prime/redundant strings in real time is preferable.6. Each test should have a set of objectives and success criteria (preferably measurable in the test data)defined prior to the test, and a post-test review should clearly establish that the test objectives andsuccess criteria were met.16.1.2.2 Independent configurability of redundant equipmentIssue Summary: Independent configurability of redundant equipment is required.Description of the GP-B experience:GP-B’s flight computer consists of two separate processors and is designed to be cold-redundant: only onecomputer may be powered at a time. Each processor holds an independent default parameter and macro set,identical at launch, but is modified as part of vehicle tuning operations. In the event of a major vehicle fault, theprimary processor is shut down and the backup is cold-booted which then starts to execute to its defaultparameter set.In this architecture, the only way to update the parameter and macro set on the backup processor is to performa “fail-over” to the backup side, allow the processor to boot-up and run with the default parameters and macros,and then perform an update. This process is very disruptive to the mission, so much so in GP-B’s case that wehave elected not to update the backup-side configuration if and when some other event forces the vehicle to thebackup system.Lesson:• Design the computer system so that all configurable elements for both processors (code, parameters,macros, etc.) may be loadable when either processor is running. This will ensure that, in the event of aprocessor failure, the backup system will control the vehicle with the same parameter set as the primarysystem.16.1.2.3 Computer memory design, monitoring and error correctionIssue Summary: Design of digital systems for single event upset (SEU) monitoring and correction.Description of the GP-B experience:GP-B has noted 34 separate anomalies relating to radiation induced single or multi-bit errors in its flightprocessor set. To a large extent, such events are unavoidable for spacecraft operating in a radiationenvironment. It has been noted that the multi-bit error rate (errors that are not correctable using the in-448 March 2007 Chapter 16 — Lessons Learned and Best Practices