Slashdot Mirror


Bad Code May Have Crashed Schiaparelli Mars Lander (nature.com)

cadogan west writes "In the accordance with the longstanding tradition of bad software wrecking space probes (See Mariner 1), it appears a coding bug crashed the ESA's latest attempt to land on Mars." Nature reports: Thrusters, designed to decelerate the craft for 30 seconds until it was metres off the ground, engaged for only around 3 seconds before they were commanded to switch off, because the lander's computer thought it was on the ground. The lander even switched on its suite of instruments, ready to record Mars's weather and electrical field, although they did not collect data...

The most likely culprit is a flaw in the craft's software or a problem in merging the data coming from different sensors, which may have led the craft to believe it was lower in altitude than it really was, says Andrea Accomazzo, ESA's head of solar and planetary missions. Accomazzo says that this is a hunch; he is reluctant to diagnose the fault before a full post-mortem has been carried out... But software glitches should be easier to fix than a fundamental problem with the landing hardware, which ESA scientists say seems to have passed its test with flying colours.

2 of 163 comments (clear)

  1. Re:easier to fix? by Anonymous Coward · · Score: 0, Insightful

    Easier to fix - in that, "we don't have to spend 10 years redesigning the entire fucking lander, we just need to fix the fucking software and send a new fucking copy of the same hardware in six fucking months."

    Jesus fucking christ, are you really that fucking Asperger's?

  2. Re:There is no bad code. by m00sh · · Score: 3, Insightful

    Testing on another planet is not that easy, though.

    Yes, test it all in production.

    Since testing is sooooooooo hard.

    Landing is the most complicated part and Beagle and others have failed exactly here. There should be x100 or even more code for unit and integration testing than the actual code itself for the landing code. And, those tests should run through every permutation possible of every possible failure point or bad sensor readings.

    There is no way it thinks it has landed with that many sensor inputs. It is simply code that is not put through a good enough testing system.