Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Software Error Likely Killed MGS Spacecraft

Posted by kdawson on Thu Jan 11, 2007 11:32 AM
from the off-by-one dept.
Aglassis writes "NASA investigators have determined that a software update performed in June of 2006 may have doomed the 10-year-old spacecraft. Apparently the software error caused the solar arrays to drive against a mechanical stop which then forced the spacecraft into safe mode. Unfortunately, after that the spacecraft's radiator was pointed at the sun which overheated the battery and destroyed it. Contact was lost with the Mars Global Surveyor spacecraft in November 2006. NASA will form an internal review board to determine formally the cause of the loss of the spacecraft and what remedial actions are needed for future missions."
+ -
story

Related Stories

[+] Mars Probe Probably Lost Forever 167 comments
David Shiga writes, "NASA's silent Mars Global Surveyor (MGS) spacecraft is likely lost forever. The space agency attempted to take a picture of the 10-year-old spacecraft using the newer Mars Reconnaissance Orbiter, but did not detect it, either because its orbit has shifted since last contact, or because it isn't reflecting enough sunlight to be visible. NASA has now ordered its Opportunity rover to listen from the planet's surface for MGS's radio beacon. If that fails, the agency may call on the European Space Agency's Mars Express spacecraft to join the search. But MGS may already have run out of power and NASA officials are not optimistic about recovering it."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by LiquidCoooled (634315) on Thursday January 11 2007, @11:35AM (#17556812) Homepage Journal
    I don't believe it.
    Its most likely the Martian automated defense system setup just before we sent a probe and destroyed their civilisation [slashdot.org].
  • Battery (Score:5, Funny)

    by Anonymous Coward on Thursday January 11 2007, @11:37AM (#17556846)

    overheated the battery and destroyed it
    Have NASA been using Dell batteries?
  • by pilgrim23 (716938) on Thursday January 11 2007, @11:37AM (#17556850)
    Typical response to a problem: form a committee!
  • by quadelirus (694946) on Thursday January 11 2007, @11:37AM (#17556852)
    One crash in ten years? Why don't the NASA guys write consumer operating systems?
    • Re: (Score:3, Informative)

      Because it'd be even less user friendly than Linux. Plus they'd also require people to run 80386 processors with 4 MB memory, if that.
          • by the_humeister (922869) on Thursday January 11 2007, @01:04PM (#17558246)
            I don't know. And people with their "keyboard" and "mouse." Idiots I say. The only true way to interact with a computer is by plugging wires into the serial port and generating the necessary electrical pulses myself.
              • Luxury! (Score:5, Funny)

                by avronius (689343) * <avron@canada.com> on Thursday January 11 2007, @02:28PM (#17559686) Homepage Journal
                We used to live in a vacuum tube. When the computer was running, and your bit was accessed, you almost had enough light to read by. Mother would disconnect the tube when she went to bed, causing floating point errors for almost eight clock-cycles...

                Or at least, that's how I remember it...
    • Re: (Score:3, Insightful)

      Why don't computers use NASA-quality hardware, ready for space?
      Why don't all computers use just a single configuration (peripherals, cards, interfaces)?

            The purpose of an operating system is so much wider than what the Mars Global Surveyor had to do.
    • by edremy (36408) on Thursday January 11 2007, @12:36PM (#17557770)
      Actually, they buy their OS's off the shelf. (VxWorks for the rovers, for example)

      That said, you could get software written to this level of perfection if you wanted. It's easy- follow the space shuttle's team's example. You have a stable team of mature developers who work reasonable hours. You test the hell out of the software to the point a single bug in a test is reason to redo the software. You run the software on four identical computers and make sure they all agree.

      Then you hire another entire team to write code that does the same thing, but otherwise has no contact with the first team. That software runs on a fifth computer that takes over if something happens to the other four.

      Willing to pay for that?

  • *phew* (Score:5, Funny)

    by Daetrin (576516) on Thursday January 11 2007, @11:40AM (#17556886)
    NASA investigators have determined that a software update performed in June of 2006 may have doomed the 10-year-old spacecraft. Apparently the software error caused the solar arrays to drive against a mechanical stop which then forced the spacecraft into safe mode.

    Glad i'm not the programmer who came up with that bit of code! Their next performace review is going to be _lots_ of fun!

  • by Bazman (4849) on Thursday January 11 2007, @11:43AM (#17556930) Journal
    Funny definition of 'safe mode'. I'd get the main antenna pointing at the earth, the battery radiator pointing away from the sun, and the computer going 'what do I do know, smarty earthlings?' and waiting for a command.

    Maybe NASA's 'safe mode' just put 'safe mode' in the corners of all the returned images and did them in 8-bit colour...

  • by Ancient_Hacker (751168) on Thursday January 11 2007, @11:45AM (#17556956)
    Just one more example of how Computer Science sint quite up to the reliability requirements of Space:
    • A missing comma in a Do-loop statement causes the first mission to Mars rocket to go off course and blow up.
    • The space-shuttle programs had a race condition that causes the first launch to be scrubbed.
    • The space-shuttle re-entry program had one important variable off by a factor of -4, causing rthe first re-entry to be a bit wobbly.
    • A Ariane guidance program had multiple basic design glitches that caused the first launch to blow up.
    • The F-16 autopilot worked very well, until the plane was deployed to Australia, where on its way there it bounced off the equator.
    • The LEM landing program didnt protect itself from spurious radar data, causing the computer to get behind.

    Aero and space are very unforgiving of human coding errors.

    • Re: (Score:3, Insightful)

      I wouldn't call it a failure of Computer Science; it's a QA failure without a doubt.

      Mistakes happen when you code. Sure, you try to minimize them but even the most carefully designed code can't be guaranteed to be 100% error free. That's why you employ, presumably, a top-notch QA team to check and recheck, testing your "perfect" code in ways that perhaps you never even considered.

      This is what you would expect in a terrestrial application. When the platform that your code is going to run on isn't bound to th
      • by Mayhem178 (920970) on Thursday January 11 2007, @12:48PM (#17557946)
        For the uninformed, QA = Quality Assurance. A must-have for any self-respecting software model.

        NASA has got it rough, has since the mid 70s. Their wildest successes are regarded as routine and hardly noticed by the public eye. Their failures, on the other hand, are spun to be the worst disasters in human history. Granted, when shuttles explode and people die, it's reasonable that the public be concerned. But it seems to me that for every 20 great things that NASA accomplishes, the media picks 1 failure (and sometimes blows that failure out of proportion) to rile the masses into a furious frenzy calling for the dissolution of NASA.
    • by Fishbulb (32296) on Thursday January 11 2007, @12:50PM (#17557984)
      The F-16 didn't "bounce off the equator". Before it ever flew, in simulation the computer flipped the plane over when it crossed the equator due to a bug that incorrectly handled southern lattitudes. Additionally, since the computer "flip" happened instantaneously, and the f-16 can roll at much higher G forces than the pilot can take, the flip would have killed the pilot (and the F-16 would have happily continued on its way).

      http://portal.acm.org/ft_gateway.cfm?id=163293&typ e=pdf&coll=GUIDE&dl=GUIDE&CFID=11154656&CFTOKEN=19 136062 [acm.org]
      • In other disciplines, the engineers ARE math guys. Face it, compared to other engineering types, software engineers and programmers are SLOPPY. This is because engineering has thousands of years worth of spectacular cork-ups with enormous death tolls to look back on, and engineering students are (I'm guessing, IANAE) shown horrific, traffic-safetyesque movies like Blood on the Protractor, Slide Rule Massacre, and London Bridge is Falling Down, Killing Litle Johnny's Entire Family.

        Maybe we CS types need our own safety movies, perhaps When Buffers Attack!, Threads: Your Parallel Friends or Quagmires of Debugging DOOM?, or maybe Metric or Imperial: You Mean there's a Difference? Or maybe we need to recognize that many of us have the same awesome responsibility that other engineers do of protecting human lives from the consequences of our mistakes. I'm told that this point is hammered home in engineering schools, why not in CS departments?
        • by unix_core (943019) on Thursday January 11 2007, @12:35PM (#17557758)
          I think I've seen some of those, starring Troy McLure right?
        • Re: (Score:3, Insightful)

          CS people are math guys too, at least many of us are. That doesn't mean we necessarily have the expertise to validate aerospace control algorithms on the fly- that's why the's an entire discipline of aerospace engineers, because you can't expect all the *other* engineers to have sufficient knowledge.

          Things like this are built as teams- and team members have to make certain assumptions about the accuracy of the other team members' work. Those algorithms should have been validated before even being handed off
        • by Flavio (12072) on Thursday January 11 2007, @02:17PM (#17559450) Homepage
          In other disciplines, the engineers ARE math guys. Face it, compared to other engineering types, software engineers and programmers are SLOPPY. This is because engineering has thousands of years worth of spectacular cork-ups with enormous death tolls to look back on, and engineering students are (I'm guessing, IANAE) shown horrific, traffic-safetyesque movies like Blood on the Protractor, Slide Rule Massacre, and London Bridge is Falling Down, Killing Litle Johnny's Entire Family.

          Engineering and applied mathematics are much more demanding than computer programming. Sure, one could argue that "computer science is math too", but my experience is that CS majors don't graduate with a strong math background. And even if they did once know some calculus and linear algebra, they were never required to apply it like an EE or Applied Math person would.

          So while you could find a rigorous programmer or software engineer (and I use the term "software engineer" very loosely, because few individuals actually fit that description), it's often a lot easier to look for an engineer or applied mathematician with good programming skills. Their math and physics is usually significantly stronger, and they actually understand what they're programming.
  • Is this a sign? (Score:5, Insightful)

    by Billosaur (927319) * <wgrother@nOspam.optonline.net> on Thursday January 11 2007, @12:07PM (#17557284) Journal

    Some expert is always trumpeting the fact that "Johnny can't program," to which many of us roll our eyes and go back to coding. But could this be a sign that the quality of the help NASA is hiring is such that these kinds of mistakes are now rampant? I mean, this could have been avoided if the code had been tested out on a full-scale mock-up of the machine, to verify that it did what it was supposed to do, before ever sending the commands to the actual machine. If anything, it's a QA failure.

    • Re:Is this a sign? (Score:5, Insightful)

      by benevixit (754447) on Thursday January 11 2007, @12:43PM (#17557856)
      In all fairness, writing code for a spacecraft is a lot harder than most of our Earthbound coding projects. These are custom-built machines running one-of-a-kind hardware; one can simulate components independently but it's very difficult to figure out how the hardware is going to behave up there in the vacuum. For example, consider the one function of maintaining orientation. Most spacecraft use telescopes that look for star reference points. They look for particular star configurations and use microthrusters or gyroscopes to adjust their orientation. Imagine what it would take to simulate this: a zero-gravity vacuum with a realistic star-field at focus=infinity. Any laboratory mock up is going to cost a lot more than launching a new spacecraft. And that's just one subsystem. Software upgrades at NASA go through a really rigorous quality control regimen, often requiring programmers to justify _individual_lines_ of their code to a review committee. Even then they usually won't patch noncritical bugs until the primary mission is completed. I think your point is a good one. And the key lesson is not that NASA QA sucks, it's that programming for spacecraft is _tough_. I know they are constantly investigating new ways (like more standardization, code re-use, and formal verification procedures) of improving software reliability.
  • by ccmay (116316) on Thursday January 11 2007, @12:11PM (#17557344)
    I guess those things happen. But at least it wasn't an error converting units, like the other Mars spacecraft that was lost. That is just incredibly stupid. Glad I'm not the "engineer" who wasted thousands of man-years and hundreds of millions of taxpayers' dollars because I was too stupid or lazy to convert between meters and feet.

    On a positive note, it has provided me an instructive example for when I help my teenagers with their math homework. If they say it's "almost" correct, I tell them that the guy who screwed up the Mars mission probably said the same thing.

    -ccm

    • by iamlucky13 (795185) on Thursday January 11 2007, @03:49PM (#17561504)
      It wasn't one engineer. It was a team effort. And it wasn't a very simple matter of "forgetting". Several factors combined, including re-use of code from the MGS mission (a conversion factor was in the old code, but not recognized when the code was adapted for the doomed MCO) and budget constraints that limited pre-flight testing (so bug was missed...and in fact might have still been missed even with more testing). The effects of the bug were also subtle enough that 3 minor main engine firings were conducted without enough error showing up to reveal the problem. It wasn't until the long orbital insertion firing that the error in the trajectory became noticeable, and by then it was too late. The team's first clue something was wrong was when the spacecraft didn't radio home after the engine burn.

      The details are really convoluted, but the Wikipedia page [wikipedia.org] on the mission has a decent write up explaining how the mistake was made, with additional resources cited. The PDF paper giving a perspective from the MCO team is particularly revealing, if you've got some time on your hands.