The Mechanism
The Mechanism
The technical failure is a unit mismatch in a file-based interface between two software components developed by two different organizations.
C RECONSTRUCTED FROM MISHAP INVESTIGATION BOARD REPORT
C SM_FORCES module - Lockheed Martin Astronautics
C Computes impulse from angular momentum desaturation events
SUBROUTINE COMPUTE_AMD_IMPULSE(THRUST, DURATION, IMPULSE)
REAL*8 THRUST ! Thruster force (pounds-force, lbf)
REAL*8 DURATION ! Firing duration (seconds)
REAL*8 IMPULSE ! Output: impulse
C FAILURE POINT: Impulse computed in pound-force-seconds (lbf-s)
C The Software Interface Specification requires newton-seconds (N-s)
C No conversion is applied. No unit annotation in the output file.
IMPULSE = THRUST * DURATION
RETURN
END
The output file is a text file with numeric values. A representative line:
C RECONSTRUCTED FROM MIB BEHAVIORAL DESCRIPTION
C Actual file format was mission-specific
C
C Event_ID Timestamp Impulse_X Impulse_Y Impulse_Z
AMD_0042 1999-073T14:22:31 0.09213 0.00142 -0.00891
The value 0.09213 is in pound-force-seconds. The JPL navigation software reads it as newton-seconds. The actual value in newton-seconds is 0.09213 × 4.44822 = 0.40984 N-s. The navigation software underestimates the impulse by a factor of 4.45.
For any single AMD event, the error is negligible. A typical AMD impulse is on the order of 0.1 to 1.0 lbf-s. The difference between 0.1 lbf-s and 0.1 N-s is about 0.35 N-s. Over a nine-month cruise with hundreds of AMD events, the cumulative error is significant: enough to displace the trajectory by 169 km at Mars arrival.
The MIB report identified multiple points where the error could have been caught but was not:
Integration testing. The SM_FORCES output was never tested end-to-end with the JPL navigation software using a known test case where the expected result could be independently computed. A test case with a known thruster force, a known duration, and an expected impulse in newton-seconds would have revealed the 4.45x discrepancy immediately. No such test existed.
Unit labels. The output file format does not include unit labels. The numbers are unadorned. A file format that included a unit identifier (“N-s” or “lbf-s”) in a header or per-field would have made the mismatch detectable by inspection. The absence of unit labels in the file format is a design decision that made the error invisible.
Trajectory anomaly investigation. The navigation team observed that trajectory correction maneuvers were consistently larger than expected. This observation was documented in navigation reports. It was attributed to unmodeled forces (solar radiation pressure, outgassing). The team did not investigate whether the AMD data could be the source of the discrepancy. The MIB report notes that the team’s modeling uncertainty budget was large enough to absorb the error, so the discrepancy did not trigger an anomaly investigation under the mission’s existing criteria.
The SIS document itself. The Software Interface Specification was written. It was reviewed. It specified SI units. But it was a document, not a contract enforced at the software level. No validation code checked the units of the data in the file. No schema enforced the expected range of values. The SIS was a human-readable specification that required human compliance. No automated system verified compliance.
The mechanism is not a coding error in the traditional sense. Neither SM_FORCES nor the JPL navigation software has a bug. SM_FORCES correctly computes impulse in pound-force-seconds. The JPL software correctly reads impulse in newton-seconds. Each component, tested in isolation, performs correctly. The failure is at the interface. The two components agree on the data format (a text file with numeric fields) and disagree on the unit system. The interface specification resolves the disagreement in principle, but nothing resolves it in practice.
This is the anatomy of an interface contract failure. The contract exists. Neither party checks compliance. The contract is indistinguishable from fiction.