Software bug caused CAPSTONE’s radio silence
NASA has explained what caused communication issues with its CAPSTONE spacecraft: a bug in the code.
CAPSTONE (Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment) was launched atop a Rocket Lab Electron in June and on July 4 the company’s Photon spacecraft deployed CAPSTONE for a several month-long journey to the Moon.
During commissioning, engineers noted some inconsistent ranging data and sent a command to access diagnostic data. Alas, the command wasn’t formatted to the radio’s liking and the spacecraft fell silent. At that point, the spacecraft’s fault detection system should have immediately rebooted the radio but didn’t, “because of a fault in the spacecraft flight software.”
Software defects in spacecraft code are nothing new. It can, however, be very difficult to deal with them when working with bandwidth constraints or something rapidly dismantling itself in a fireball of failure.
For the latter, the example of the maiden flight of the Ariane 5 rocket on June 4, 1996, springs effortlessly to mind. A bug in the Inertial Reference System (used for where the rocket was pointing) resulted in a good, old-fashioned overflow as a 16-bit integer was the recipient of 64-bit variable. The rocket ended up pointing in the wrong direction and was destroyed less than a minute into the launch.
It would take a year and a good deal of agonizing over how a seemingly simple bug in code lifted from the Ariane 4 could cause such a catastrophe before the Ariane 5 would fly again.
As for bandwidth constraints, we’ve no doubt that the CAPSTONE incident sent a shiver through the spines of the SOHO (Solar and Heliospheric Observatory) team after a mistake in a sequence of commands sent to the spacecraft resulted in the billion-dollar mission almost being lost in 1998 had it not been for some determined engineers and supportive management.
Other notable software errors include the infamous loss of NASA’s Mars Climate Orbiter, sent hurtling into the Martian atmosphere due in part to one element of the software working in imperial units while the other used the metric system, resulting in a trajectory that caused the orbiter to disintegrate in the atmosphere of Mars.
Going further back, there was the Mariner 1 mission to Venus, destroyed shortly after its 1962 launch when its Atlas-Agena rocket veered off course. Working through the aftermath, engineers pinpointed an error in one of the equations loaded into the flight computer that guided the rocket. Very much a case of the programming was OK but the specification was not.
There are many more examples of software problems blighting missions – Boeing’s Calamity Capsule and woeful lack of quality control is one of the more recent.
However, for now the CAPSTONE mission is back on track. The spacecraft kept its antenna pointed at Earth and its solar panels kept the battery charged until the radio was eventually restored to life. With luck, it has had its glitch for this mission.
After all, in space, no one can hear you blue screen.
See more here: theregister.com
Please Donate Below To Support Our Ongoing Work To Defend The Scientific Method
PRINCIPIA SCIENTIFIC INTERNATIONAL, legally registered in the UK as a company 
incorporated for charitable purposes. Head Office: 27 Old Gloucester Street, London WC1N 3AX.
Trackback from your site.
Jerry Krause
| #
Hi the register.com,
No I do not expect the author of this article to read this comment. I make it to possibly cause a PSI Reader to ponder about what they read. The author who wrote: “a bug in the code” was not being accurate, and therefore not being honest. The problem was an “error” in the code. And error made by a NASA programer or possibly even by a NASA engineer. But some people do not want to admit that people (they) make errors which have consequences. Better to blame a human error on a nonhuman entity–a bug.
Have a good day, Jerry
Reply