Call the space repair man - March 14, 2008
Two different bits of hi-tech space kit have malfunctioned embarrassingly this week.
First up: the flyby of Saturn’s moon Enceladus turns out not to have been the total success it first appeared. A software hiccup meant the Cassini probe’s Cosmic Dust Analyzer failed to collect data when it flew through a geyser spewing from the moon (see Nature’s pre flyby coverage for more on the mission). The other four instruments measuring fields and particles did work, according to Reuters.
“An unexplained software hiccup with Cassini's Cosmic Dust Analyzer instrument prevented it from collecting any data during closest approach, although the instrument did get data before and after the approach,” explains NASA (press release).
“When it went through the plume, it was not working properly,” Bob Mitchell, Cassini program manager, told Reuters. “We had tested that software very carefully. We don't know why it didn't work properly.”
Hopefully the cause of the glitch can be determined before the second of eight fly-bys comes in August.
The second space breakdown has happened aboard the ISS, where a giant robot has refused to wake up. According to USA Today NASA thinks it should be able to fix it quite quickly.
“We don’t have our hair on fire and need to do something in the next couple of hours, but we’re working it,” LeRoy Cain, chairman of the mission management team, told a press briefing (AP).
The 12 foot high, Canadian-built Dextre robot is designed to help with maintenance of the space station.
Image: North Polar Region of Enceladus / NASA/JPL/Space Science Institute
Comments
All these things again point to deficiencies in software practice. It's disappointing really that the development of software as failed to come of age. What I am referring to here for those with no background in computer science is the failure to apply formal methods in software development. The application of such methods would replace statements such as: "We had tested that software very carefully. We don't know why it didn't work properly.” with statements like "We proved valuable properties of the onboard software. We proved, for example, that the software meets it's specification, that it has valuable termination properties (such as deadlock freedom), is deterministic and maps to the hardware. We are now reviewing the specification for potential design errors, however the design has been mechanically checked for inconsistencies. This leaves us with few options to examine so we should be able to correct the problem quickly. Failing that, something truly unpredictable has happened and we may have a hardware failure."
Posted by: Steven Ericsson-Zenith | March 14, 2008 08:04 PM