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 FSW also met its subsystem level performance specifications. A major requirement of the FSW was toprovide all mission level capabilities mentioned above, while allowing the spacecraft computer (CCCA) tooperate with acceptable usage margins. This requirement was stated in LM SCSE-15 (<strong>Flight</strong> SoftwareRequirements Specifications): “Computer timing margins shall be defined as: PDR is 60% or less usage; CDR is65% or less usage; vehicle acceptance review is 95% or less usage”FSW performance was measured by the time duration (or percentage of allotted time) required for 1Hz and10Hz task processing. Data for a typical week during science data collection are shown in Figure 8-33 andFigure 8-34. Processing times were averaged over ~4 hour periods for this plot. Red lines represent themaximum processing time over the averaging interval, blue lines represent the average processing time, andgreen lines represent the minimum processing time. The 1Hz processing times (Figure 8-33) show a maximumof about 35% (350 milliseconds), which exceeds the performance specification of both 60% (PDR) and 95%(vehicle acceptance). The 10Hz processing times (Figure 8-34) show maxima under 90% (90 milliseconds) withan average of just over 65% (65 milliseconds), also meeting performance specifications.Additionally, watchdog timers were used to ensure that 1Hz and 10Hz processing tasks finished within theallotted time. This provided a means of monitoring the software performance and tracking the number of cyclesthat “timed out” before the processing task was complete. Based on flight data analyzed near the end of the <strong>GP</strong>Bscience mission, the FSW incurred zero (0) 1Hz processing timeouts during the first 400 days of the <strong>GP</strong>Bmission. Eleven (11) 10Hz processing timeouts were recorded over this same time span (an average of ~36 dayson-orbit per 10Hz timeout). Processing overload caused negligible (if any) interruption to on-orbit activities orscience data collection.Overall, the design and implementation of the <strong>GP</strong>B <strong>Flight</strong> Software met or exceeded all high-level systemrequirements, and most importantly, contributed to the realization of mission goals.Figure 8-33. CCCA 1Hz CPU Usage (in %) averaged over ~4 hours. (Red = max; Blue = avg; Green = min):240 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!