Clementine: The Software Error That Left a Thruster Firing for Eleven Minutes

Clementine was already a scientific success when software destroyed its next mission phase

Clementine launched in January 1994 as a joint Department of Defense and NASA technology demonstration and lunar mission. It completed a global lunar mapping campaign and returned roughly 1.6 million images before leaving lunar orbit for a planned encounter with asteroid 1620 Geographos.^[1] On May 7, however, an onboard computer problem caused an attitude-control thruster to remain on long enough to consume the available propellant and spin the spacecraft at about 80 revolutions per minute.^[2] The lunar mission survived historically; the asteroid mission did not.

Partial mission success complicates the word “failure”

The software accident did not erase Clementine’s lunar achievements, but it did destroy the spacecraft’s planned second act.

The trigger was an onboard computer malfunction during autonomous testing

NASA’s mission histories describe the event as a computer glitch or malfunction that caused a thruster to fire continuously.^[1][3] The incident occurred while Clementine was performing increasingly autonomous spacecraft-control activities in preparation for the Geographos encounter. Once the processor entered the faulty state, the attitude-control command remained asserted instead of terminating normally.

The protective timeout was itself implemented in software

A critical design detail made the event much worse. Clementine used software-based thruster protection rather than an independent hardware one-shot. NASA lessons-learned material explains that a watchdog or countdown protection intended to stop a long firing was either defective or unavailable in the software state reached during the failure.^[4] If the processor that commands an actuator is also responsible for enforcing the actuator’s maximum on-time, a crash can disable both the command logic and the safety logic simultaneously.

Redundancy fails when both channels share the same failure mode

A software watchdog running on the failed processor is not independent protection against processor lockup.

Eleven minutes of thrust consumed the propellant needed to recover attitude

The attitude-control system expended its hydrazine while the spacecraft accelerated into a rapid spin. NASA’s later fault-protection study states that the thrusters remained improperly commanded for roughly eleven minutes and that Clementine was left without enough attitude-control fuel to despin.^[5] Without stable pointing, the planned asteroid imaging campaign became impractical even though other parts of the spacecraft remained functional.

The accident changed thinking about independent actuator safing

NASA engineers later cited Clementine when discussing why fault-protection functions should not depend on the same software they are meant to supervise.^[5] A safer architecture can include hardware timers, independent command inhibits, separate processors, or actuator electronics that time out automatically. The exact implementation varies, but the principle is simple: a single software lockup should not be able to command a hazardous actuator indefinitely.

Safety mechanisms should survive the failure they are intended to stop

That sounds obvious, yet common-mode dependence remains one of the hardest problems in safety-critical design.

Configuration management also mattered to the Clementine story

NASA’s lessons-learned entry on critical command timing describes a flight-software release in which protective timing behavior was not fully present and recommends stronger software configuration management and testbed verification.^[4] Space missions frequently upload patches and new releases after launch, so the question is not only whether a fix exists but whether the exact intended software image reaches the vehicle and behaves as tested.

The failure became a reference point for later asteroid missions

NASA’s fault-protection literature contrasts Clementine with the later NEAR mission, which used a more conservative philosophy for burns and independent protection.^[5] Engineers designed critical operations so an anomaly would shut thrust down, preserve recovery opportunities, and avoid placing one processor in control of both hazardous actuation and its ultimate timeout. In that sense Clementine’s loss produced concrete architectural lessons.

Successful missions inherit the memory of failed ones

Spaceflight reliability advances partly because later teams encode previous accidents into new constraints, reviews, and protection systems.

Why Clementine belongs in software-failure history

Clementine belongs in this history because it shows how a software problem can turn a recoverable computer upset into an irreversible propulsion event. The primary computer, command path, and protective timing logic were coupled too tightly, allowing one failure to drain the resource required for recovery.^[4][5]

The broader lesson applies far beyond spacecraft. Software increasingly controls motors, valves, heaters, and other physical actuators. When a program can keep energy flowing after the program itself has become unhealthy, the system needs an independent way to stop it. Clementine demonstrated the cost of discovering that principle in flight.

Clementine’s story also warns against treating software timing protections as independent simply because they are written in a different routine. Independence is architectural, not textual. If both the hazardous command and the watchdog rely on the same processor, scheduler, memory, or execution state, one fault can disable both. Safety engineers therefore analyze common-cause failures explicitly and ask which protections remain available after the primary controller becomes untrustworthy. The same reasoning appears today in industrial shutdown circuits, automotive electronic controls, and medical infusion devices.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES

1. 01
   NASA — 30 Years Ago: Clementine Changes Our View of the Moon ↗nasa.gov
2. 02
   NASA Science — Clementine Mission ↗science.nasa.gov
3. 03
   NASA NSSDC — Clementine Project Information ↗nssdc.gsfc.nasa.gov
4. 04
   NASA Lessons Learned — Redundant Verification of Critical Command Timing ↗llis.nasa.gov
5. 05
   NASA Technical Memorandum — Spacecraft Fault Protection ↗ntrs.nasa.gov

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.