Mars Climate Orbiter failure: cause and lessons
Mars Climate Orbiter was lost on September 23, 1999, after a mismatch between pound-seconds and newton-seconds in ground-software data led to an incorrect trajectory. NASA identified both the units error and failures in verification.
What caused the Mars Climate Orbiter failure?
The immediate cause was a units mismatch in ground software. A ground-software file reported small thruster impulses in pound-seconds, while the navigation team used those values as newton-seconds. The interface specification required metric units. The incorrect data distorted estimates of the spacecraft's trajectory, bringing it too close to Mars during orbit insertion on September 23, 1999. Contact was lost and never re-established.
Why wasn't the mismatch caught? NASA's Mishap Investigation Board identified weaknesses in systems engineering, communication, staffing and training, and verification and validation. The loss was not simply a conversion mistake: the checks connecting the software interface to flight operations did not detect and resolve it.
Reliability lesson — Mission Ready's retrospective analysis: Make units and assumptions explicit at every interface, test the complete data path, and independently check whether results are physically plausible. These are engineering lessons drawn from the investigation, not evidence that a particular product would have prevented the loss.
The Ariane 5 Flight 501 software failure illustrates a different numerical-assumption problem. The Mars Polar Lander loss offers a separate lesson in interpreting sensor inputs. Neither had the same immediate cause as Mars Climate Orbiter.
To examine how incorrect interface data can propagate to system hazards, explore software FMEA or design and test for hidden edge cases training.
Sources: NASA JPL's preliminary finding and the NASA Mishap Investigation Board Phase I report.
What the software actually got wrong
A ground-software file supplied thruster impulse data in pound-seconds instead of the required newton-seconds. Navigation software treated those values as metric, distorting trajectory estimates and bringing the spacecraft too close to Mars.
Ground-software impulse data did not match the required units
A ground-software file supplied thruster impulse data in pound-seconds instead of the required newton-seconds. Navigation software treated those values as metric, distorting trajectory estimates and bringing the spacecraft too close to Mars.
Requs AI Edge Case flags this exact pattern at the requirements and architecture stage — before a single line of code implementing it exists — so the assumption behind it gets challenged while it is still cheap to fix.
Beyond code coverage and "shall" testing
Root causes like this one rarely show up in code coverage or requirements-compliance testing, because nobody wrote a requirement anticipating the specific edge case that broke. Requs AI Edge Case and Requs AI Software FMEA are built to surface exactly this class of overlooked failure mode — before the software is written.
Surfaces this before code exists
Identifies edge cases like this one at requirements and architecture time, using the Common Defect Enumeration to catalog failure patterns seen across hundreds of real-world software failures — including this one.
Connects the failure mode to the hazard
Traces this class of root cause directly to the system-level hazard it can produce, so a defect pattern like this one gets flagged during design review instead of after it ships.
Find the overlooked root causes before they ship.
Schedule a demonstration, or explore how Requs AI Edge Case and Software FMEA use the Common Defect Enumeration.
See real failures this would have caught
Failures like this one can be found before release. See how Requs AI finds them early:
- Software FMEA tool — find failure modes and root causes before code ships
- Software reliability prediction — predict defects before code is written (IEEE 1633)
- Software risk assessment checklist — spot the risks behind failures like this