Mars Failures: Bad luck or Bad Programs? 389
HobbySpacer writes "One European mission is on its way to Mars and two US landers will soon launch. They face tough odds for success. Of 34 Mars missions since the start of the space age, 20 have failed. This article looks at why Mars is so hard. It reports, for example, that a former manager on the Mars Pathfinder project believes that "Software is the number one problem". He says that since the mid-70s "software hasnâ(TM)t gone anywhere. There isnâ(TM)t a project that gets their software done."" Or maybe it has to do with being an incredible distance, on an inhumane climate. Either or.
I think it's the metric system (Score:2, Funny)
Re:I think it's the metric system (Score:4, Funny)
Re:I think it's the metric system (Score:5, Funny)
On behalf of the Zhti Ti Kofft (and it is nice to see at least one of you using our proper names); I should like to take this opportunity to inform you of one simple rule when approaching our planet.
We drive on the left.
Thank you.
Re:I think it's the metric system (Score:5, Funny)
Re:I think it's the metric system (Score:3, Interesting)
It'll make me think twice (Score:3, Insightful)
We landed on the moon with 512 bytes of RAM (Score:3, Funny)
I think it's hard to get to Mars because it's far away and it it's in SPACE! It doesn't take a rocket scientist to figure that out! Well on second though....
Re:We landed on the moon with 512 bytes of RAM (Score:5, Insightful)
With 512 BYTES of ram you can literally look at the entire contents. You can be aware of every single bit on the system.
Now, where we have gigabytes of ram, and even more other storage it is simply impossible to sort through every bit. This errors roll in.
I'm not sure what to do about it, but I see why there is difficulty.
Re:We landed on the moon with 512 bytes of RAM (Score:4, Informative)
no, for instance the Mars Pathfinder spacecraft had "128 Mbyte mass memory" and used a R6000 computer. While the rover had "0.5 Mbyte RAM mass storage" The R6000 is much less powerful than the original pentium.
http://mars.jpl.nasa.gov/MPF/mpf/fact_sheet.htm
NASA computer technology has for the past decade or two been a few or more years behind the state of the art in consumer electronics. Largely because they have to put the electronics through more testing and only use chips that will withstand possible radiation with low power consumption. Plus add on the years of development of the spacecraft itself... means that your desktop probably (Anyone want to do the math?) has more computing power than all the deep space explorers ever launched, combined.
Re:We landed on the moon with 512 bytes of RAM (Score:5, Insightful)
Yes, but can your computer recover from a triple memory failure? Can you rewire your computer remotely to fall back on a redundent system? Frankly I keep the covers off my case to keep my CPU from overheating.
State of the art is not always measured in Gigahertz.
Re:We landed on the moon with 512 bytes of RAM (Score:5, Informative)
A bit of advice: Leave the covers on, but make sure that you have enough case fans to ensure that the CPU has a constant air current over it. I have the fan on the front of my box blow in and the fan on the back (plus the power supply) blow out. If you leave your case closed, the improved air flow will actually lower the temperature of your CPU and motherboard.
Re:We landed on the moon with 512 bytes of RAM (Score:3, Insightful)
The grandparent post's point still stands. 128MB is one huge mass of program and data to debug. I know I wouldn't stake my reputation on a "bug free" multi-megabyte program--only a fool would.
Remember, the true complexity of a program increases exponentially with the size of the program.
This is why I will never trust Windows for anything more than a gaming platform (millions of lines of hastily-writte
Re:We landed on the moon with 512 bytes of RAM (Score:5, Interesting)
Thing is, space exploration isn't done with *current* technology. The computing technology used in a lot of aerospace applications is 20-30 years old. There are a number of reasons for this, but the ones I've heard of are:
1. The projects are long-term, and have been in development for a lot of years. Especially when it comes to government projects. They can't just up and switch to the latest tech whenever it comes around, otherwise it will end up like DNF and never see the light of day.
2. The engineers don't trust the latest and greatest. The technology isn't considered mature enough. All the bugs have been worked out in the older tech, so it's more robust, the engineers are more familiar with it, and more often than not, manufacturers have shunk and simplified the designs significantly since introduction.
It's more likely that you'd find a 8086 processor in the space shuttle than a Pentium 4 unless someone brings a laptop aboard. It wasn't all that long ago that NASA put adds on websites and geek magazines appealing for old 8086 processors for spare parts. I haven't heard anything since, so either they found a supplier, or they're too busy piecing together the Columbia.
Re:We landed on the moon with 512 bytes of RAM (Score:2)
It's nearly impossible to find space-rated, radiation-hardened components that are anywhere near 'cutting edge'. The smaller the process, the more likely the component will be damaged by radiation - that pretty much eliminates 'cutting edge' stuff and newly shrunk old stuff.
It's really a shame that manufacturer's can't easily produce space-rated components cheaply, and it's also a shame that the space-rated component market is not large enough to support that niche as a viable business.
Re:We landed on the moon with 512 bytes of RAM (Score:4, Interesting)
Re:We landed on the moon with 512 bytes of RAM (Score:2)
Re:We landed on the moon with 512 bytes of RAM (Score:3, Interesting)
With the moon missions, there were manned craft, and so every line of code had to be checked and rechecked--and hundreds of guys were on the ground watching everything that happened, twenty-four seven, until the astronauts were safely back on the ground.
Now, windows for a Mars launch come mu
Re:We landed on the moon with 512 bytes of RAM (Score:5, Interesting)
I haven't read the whole site in a while, but IIRC, it describes the typical problems with software: underscoping the problem (in the 60s, most people assumed that the computer hardware development would be the majority of the effort), code bloat (the computer required much more memory than originally planned), buggy production code, schedule slips, problems caused by cruft. When the project started, they just waded right in to coding with few tools and little awareness of the need for proper engineering practice.
This particular case was made more difficult by the program loading procedure: the program ROM was made one bit at a time by hand threading magnetic cores on to tiny wires then embedding it in a solid block of epoxy. The write-compile-debug cycle could be weeks. If bugs were discovered late in the schedule, the astronauts just had to work around them. The software devleopers did have mainframe-based simulators for development, though.
With the gigabytes of space available for today's software, I'm surprised that any modern space projects get finished at all.
Many Moon Missions Failed Too (Score:5, Interesting)
It's a hard probelm to send a probe to the Moon or Mars. landing and aerocapture at Mars are dicy things.
sabatoge (Score:2, Funny)
Re:sabatoge (Score:2)
Re:sabatoge (Score:2)
I don't think the Martians need any help - the bureaucrats at NASA are sabotaging it just fine.
That said, how did this get modded "insightful"? What, exactly, is the insight? Maybe there should be a "+/-1, TinFoilHat" mod.
Re:sabatoge (Score:3, Funny)
I used to mock the whole tin foil hat idea, until I put one on. Once their signals stopped entering my brain I started to see things differently. If you have never actually tried a tin foil hat then you shouldn't laugh.
Its a shame (Score:2, Insightful)
because software is one of the only things that could and should be theoretically perfect
maths (especially that based on 1 or 0 is either right or wrong it seems to be only when humans get involved that things go wrong and mistakes happen
Chess is also a Formal System (Score:3, Interesting)
Theoretically, all programs have latent bugs, unless they are too simple to do much.
Re:Its a shame (Score:2, Insightful)
Software is human beings communicating with each other in ambigous natural languages and then trying to convert what they think they understand into a hyper specific computer language that a program (ie compiler) will translate into machine code.
The hard part is trying to eliminate all the killer misunderstandings. One of the early Geminis came down se
Software - The only thing right on the Shuttle (Score:5, Interesting)
Part of it was the fact they had absolute geniouses working on the problem. Think of it, they designed a system in the late 1970's, tested it on the ground, and had it successfully fly for 20 years without a major "oopsie". Or rather, if a major "Oopsie" happened, they had ways around, over, or through it. They spent YEARS developing the flight software for the Shuttle.
Software CAN be done right. It just has to be a priority.
Re:Software - The only thing right on the Shuttle (Score:3, Interesting)
And when I point out an aerospace system that does work, showing me a zillion ones that don't doesn't invalidate my point. The difference between the systems that work and the system that fail is crafstmanship.
Re:Its a shame (Score:3, Insightful)
And theoretically prohibitively expensive.
I have yet to meet someone who is geniunely willing to pay for software quality. They simply don't care or understand. Once the software reaches some minimum threshold of "working", the project gets cut off or put on some other tangent.
Re:Its a shame (Score:2, Interesting)
Used to be comp.sci was about comp.sci not staying upto date with the latest code monkey script language.
There is still a reason why the majority of *real* work is coded in C. Its a simple language that gets things done.
The dot.com busta VB script kiddies [e.g. three week IT grads] come and go. True comp.sci'ers stick along better.
Tom
manned mars mission (Score:5, Funny)
I really hope this explains why there isn't a manned mission. =)
Re:manned mars mission (Score:4, Interesting)
Men are from Mars.. (Score:4, Funny)
Re:Men are from Mars.. (Score:2, Funny)
I disagree, Mr. Editor (Score:4, Insightful)
Just as in the NFL when a receiver drops an easy pass and someone yells that he gets paid to catch passes like that, programers get PAID not to fuck things up.
Re:I disagree, Mr. Editor (Score:2)
And I can clearly tell you are not one considering you can not even spell the profession correctly. It's programmers, two 'm's.
And your comparison between a receiver and a programmer is wrong. A receiver is gifted and talented and can catch the ball in many ways, in the gut, in the air, on there stomach (Antonio Freeman vs Minnesota on MNF) all this and defending off the defense. But at the end of the day it is still catching the ball.
As a Programmer, I can not ju
Programmers (Score:5, Insightful)
Yes, programmers have erred. To err is human, to allow errors to propagate into mission failures is a failure of systems engineering, and I think that is where the real blame lies. A lot of the problem is thatspacecraft systems engineers often have a very amateurish grasp of software, if any at all.
For example, on Mars Climate orbiter, a junior programmer failed to properly understand the requirements. However, systems failed to:
Re:I disagree, Mr. Editor (Score:5, Funny)
Re:I disagree, Mr. Editor (Score:4, Insightful)
Regarding the losses of the two space shuttles, it is hardly fair to compare hardware failure to software failure. The physical behavior of a mechanical system is not deterministic--stress something hard enough and it will break, and it is impossible to predict when a particular part will fail in advance. You can do lots of testing to get a sense of when, on average, a part will fail under certain conditions, and you can design and engineer as best as possible for something to work even if a part fails, but parts will fail and sometimes hardware failures are irrecoverable.
Software, on the other hand, is completely deterministic. With error-checking and proper testing, it is possible, at least in principle, to write software that will not fail. Software failure that results in loss of life is simply inexcusable.
Re:I disagree, Mr. Editor (Score:3, Insightful)
Software is NEVER deterministic in an operating environment. Just because you can put it on a bench and test the snot out of it does not certify it's behavior in the real world. I have written many programs that work perfectly in testing, only to have a user punch in
Re:I disagree, Mr. Editor (Score:5, Insightful)
That's just bunk. As a programmer writing software for spacecraft you must be able to anticipate every possible value and account for it. Every condition should be able to be gracefully handled by an error checking routine. There is zero room for failure. If that means it takes 20 years to write, test, rewrite, and retest the perfect program, then so be it. When human life is involved price is not an object. (well, within reason of course since there's a dollar value on human life in the space program, but the negative publicity value is astronomically more than the dollar value of the loss of human life.)
Re:I disagree, Mr. Editor (Score:3, Funny)
Their Mission Statement: "To boldly go where no man has gone before, and anticipate absolutely everything."
Management Failure (Score:3, Insightful)
Oh come on! (Score:2)
Please stop denying it, the great Anthropoligist and Engineer Erich von DÃniken [daniken.com] has been writing about this for decades. Wake up and smell the Martians.
hehe
Wrong Motivation (Score:4, Funny)
Re:Wrong Motivation (Score:2)
Thus the interest by the Chinese! Their 'Moon' program is nothing but a decoy. They plan to change Mars from 'red' to Red.
The software motto... (Score:5, Insightful)
If you underestimate the resources you need to do software right, of course you'll have problems -- either getting it done on time, or getting the quality to the level it needs to be (or both).
That problem is hardly unique to the space programs. And of course, it would be a little tricky trying to upload a software patch to a hunk of solar-powered metal a few million miles away.
I wonder how much NASA et al. really tap the resources they should be tapping -- I mean, there ARE areas of industry where mission-critical or life-critical software has been developed and deployed for some time now. Maybe it's just a question of getting the right kind of experience in-house...
Xentax
Re:The software motto... (Score:2)
Or, as is often the case, "Data In, Garbage Out."
And what the users want is "Garbage In, Data Out."
Re:The software motto... (Score:5, Interesting)
Software not the problem... (Score:2, Insightful)
An opportunity here... (Score:5, Funny)
The first samples returned should have mystical properties ascribed to them and then sold on EBay. This should generate enough revenue to substantially increase the size of the "cost envelope"...
cheers
(I got engaged last night) =)
Small Simple... Solid State (Score:5, Interesting)
Also, solid state, however big and bulky, isn't susceptible to the radiation that many mega-tiny chips are... by writing (and testing) the software in the simplest manner, and building a VERY specific piece of hardware out of solid state components.. and lots of unit testing... you're more likely to get there.
For the same reason the 486 was the only space-rated intel processor for quite a long time (not sure if thats still true).
I'd rather go on "slower" simpler hardware that does a very specific job... and you can repair with a soldering iron.
Re:Small Simple... Solid State (Score:2)
Recall that on the first manned moon landing, the software screwed up and the lander would have been lost if the pilot hadn't taken manual control at the last minute!
Re:Small Simple... Solid State (Score:2)
Re:Small Simple... Solid State (Score:2)
A more intricate, complex system may have provided the lander with the intellect to figure out that it was going to be grey paste on the red earth if it did that (as opposing what happens to humans who fall from the sky).
Re:Small Simple... Solid State (Score:2, Funny)
10 REM my Martian exploration program
20 GOTO MARS
Re:Small Simple... Solid State (Score:2)
The problem is that all of the Mars shots we've launched so far--and all of the failures referred to--have been unmanned probes. So the question remains: how do you plan to get the guy with the soldering iron up there?
Re:Small Simple... Solid State (Score:3, Interesting)
Actually, the current microchips are inherently rad-hard (radiation resistance). This wasn't the case in the past. It's something about the size of the features being small and also shallow, so that not much charge is deposited as a charged particle passes through. 0.25 and 0.18 microns are apparently especially good. However, as feature size continues to go down, things will get worse again.
You
Re:Small Simple... Solid State (Score:5, Informative)
The GCs read only memory consisted of a series of peg-boards into which the code was wire wrapped (by hand). There were 74,000, 16-bit instructions that could be programmed in this way. There was 4k iron-core memory in the computer. There were two GCs used in Apollo. The CSM one was responsible for leaving earth orbit, mid-course correction(s), entering lunar orbit, etc. The LM GC controlled descent and ascent as well as autopilot functions for lunar orbit docking. The computers ran the programs for these manuevers from ROM, but using astronaut input parameters using the "noun-verb" input methodology.
The software was actually very sophisticated and did not consist of simple control loops - joystick feedback was actually processed to ensure commands kept the spacecraft within limits. The most important parameter was keeping the antennae pointed at the Earth.
AFAIK, there are no space-qualified Intel built '486s. There are space-qualified computer systems with '486s in them, which may seem like semantics, but these systems typically employed multiple '486s, with bus operations and data continually compared to look for differences indicating upsets. This is a point that always confuses people because at one point IBM/NASA indicated the AP101 Block IIs had the same amount of power as a '486 - this seems to be misinterpreted as the AP101s have '486s built into them.
Half a lifetime ago, I helped with some hardware failure analysis for the IBM Orbiter Computer Systems Group (It was an intermittently failing memory board on STS-4) and I have to say that they were the most impressive software group that I have ever been associated with. They learned their skills with the Apollo CSM/LM GCs and Apollo Instrumentation Ring - you just don't make mistakes when the instructions are wire wrapped. The software engineers that worked on the shuttle software didn't have a problem with going with the (relatively) complex AP101s (originally designed for the B-1). Going from wire wrapped ROM to battery backed RAM was seen as a good thing, but it did not mean that the software development process changed in any way.
I'm trying to remember if there were two or three support binders for each module of software in which the requirements were clearly defined, the science and reference information provided, all calculations/constants defined to support the software binder. Coding is always the last thing that is done and only if the support binders are complete and signed off. This process is very expensive, but the software produced is essentially perfect (I believe that there has been one non-safety of flight software error in shuttle history and several hundred thousand lines of code). Complexity isn't the issue.
I think the issue is, is there a software development methodology/process that fits in with NASA's "smaller, better, cheaper" and produces the same quality as the Shuttle/Apollo?
myke
Budget and motivation (Score:3, Insightful)
However just throwing money at the problem isn't going to solve it, I'd suggest throwing away the rulebook and starting over for unmanned systems, better craft, less of the multimillion dollar single units and more cheaper devices that can carry out multiple landings at once.
For once, it might be worth imagining a Beowolf cluster of those things - because with many cheaper devices, the mission would most likely have a modicum of success.
Methodolgies (Score:2, Insightful)
Re:Methodolgies (Score:3, Informative)
http://www.fastcompany.com/online/06/writestuff
That's what they do, and I'm glad I don't.
And as for domain expertise not counting for much, that may be true for some domains, but sure as hell is not for mine (medical informatics).
Re:Methodolgies (Score:2)
XP is a methodology more suited to commercial environments, particularly web based where the requiremens are often in a state of flux. I would not expect to see NASA telling their coders twice a week that mission requirents have changed and they now need X inst
Re:Methodolgies (Score:4, Insightful)
Or, at least when it comes to writing rock-solid code that reliably does the wrong thing...
Mistakes (Score:5, Interesting)
-Restil
Re:Mistakes (Score:3, Insightful)
That's why some folks at NASA develop [nasa.gov] more sophisticated control software that can take of failures. The RAX experiment on DS1 probe successfully demonstrated this approach viable.
However, at the moment the project suffers major rewrite in C++, notorious for its 'safety', for reasons having very little to do with engineer
Sorting out the stages (Score:2, Insightful)
It looks as if the testing and debugging starts at the begining and works through the mission. I suppose this will eventially work, but it seems to be an expensive way to do it.
almost /.dotted (Score:2, Informative)
Why is Mars so hard?
by Jeff Foust
Monday, June 2, 2003
This June will see the beginning of the most ambitious exploration of the Red Planet in a quarter-century. If all goes well, three launch vehiclesâ"one Soyuz and two Deltaâ"will lift off this month, placing four spacecraft on trajectories that will bring them to Mars by this December and January. Those spacecraft include the first European Mars orbiter, Mars Express; Beagle 2, the British lander built with a mix of public and private f
Rocket Science is hard (Score:5, Insightful)
The flip side is that. After Mars Ovserver spectatularly failed in 1993 ("Martians"), NASA started to go with faster, cheaper, better. The idea was, instead of a single $1 billion mission every 5 years with with 90% chance of success, why not 2 $200 million missions every two years, with an 80% chance of success. Everyone loves this idea when it works (Pathfinder), but when a cheap spacecraft fails, the public doesn't care if it cost $10 million or $10 billion, all we know is that NASA is wasting money.
So, the answer is, NASA has hit some bad luck. But the idea of faster, cheaper, better is ultimately a cost-effective one, so if we can solve these software problems (I mean, can't someone independently design a landing simulator?), and NASA can get 80-90%, we'll be getting a lot more science for the dollar. But NASA-haters will always have some missions to point to as a "waste" of money, and try to cut funding as it's mismanaged; other space junkies will insst that anything under 100% is unacceptble, and costs should double to move from 80% to 100%. I don't which attitude is more damaging.
NASA has a "good" track record since Observer, unfortunately, the highest profile missions have generally failed. If MER-1, and MER-2 are both succesful, and SIRTF flies this summer, then everyone should get off of NASA unmanned program's back for a while.
It's the martians silly. (Score:2)
I mean notice, they never land near the face or the pyramids!
(apologies to the author Robert Doherty for stealing the idea from his Area 51 series)
Tough assignment... (Score:5, Insightful)
Which is why we should continue to try. Giving up, saying "space travel is just too costly and risky" is a big cop-out. If we could send people to a different stellar object (the moon) in 1969 with the equivalent of a pocket calculator but not now, what does that say of our technology? Or sociology? Sure you could take the narrow-minded approach and say "and what does that bring us? The ability to jump from rock to rock in our solar system?" If so, you might as well ask why people decided to go to the poles (just ice) or whatever. You're still missing the point.
Kjella
NASA Management Practices and Quality of Software (Score:5, Insightful)
In my years at NASA Goddard I saw a dysfunctional management operate in ignorance of reality.
There was much praise of the employee who "went the extra mile", "put in long hours" and "served the customer" (that applied to contractor employees). There was also very little thought paid to the consequences of those practices.
What's the first thing to go when you're tired? It's not your body -- it's your mind. That's right -- if you're staying at work until you're feeling tired, you're making mistakes that need to be corrected later. The tireder you are, the more mistakes. The tireder you are, the less you can actually do.
I witnessed people who wore their exhaustion as a badge of honor. And, when they got into management, insist that others emulate their bad example. The result that I saw was people who should have been kept out of management becoming increasingly dominant. This was accentuated by the "faster, better, cheaper" ideology promulgated by former NASA administrator Goldin. This ideology was used to get rid of more experienced (and thus costly) people who were aware of the consequences of trying to squeeze more work out of fewer people.
It could take a long time for NASA to recover from this culture. The failure of projects in the past few years, the crash of Columbia could be turning points -- or they could be used by incompetents to justify even more dysfunctional behavior.
Re:NASA Management Practices and Quality of Softwa (Score:3, Insightful)
(1) Schedule realistically, so that tasks can be completed without overtime. This may mean some things just cannot be done in the desired time period. Learn to accept that.
(2) Hire and retain sufficient staff, so that the work can be shared between multiple people. This may mean that some of the time the company will be overstaffed. Accept that too.
Obviously both these suggestions come with a pricetag, but lost missions aren't free either...
Time for a standard RT OS and tools? (Score:2, Interesting)
"inhumane(?!) climate" (Score:2)
I'm not surprised. (Score:5, Interesting)
Since software engineering is still a 'black art' as far as most traditional engineers and project managers are concerned, there isn't the real intuition/understanding of when things are starting to look bad. Without looking at code AND knowing something about it, you won't stand a chance 'intuiting' whether or not things are going well.
Writing software is an expensive business in both time and money. It's also a very young business without the same 'discipline of implementation' as other areas. Until the process matures and people realise that doing it on the cheap gives you cheap software, things aren't going to change and Mars probes are going to continue to produce craters.
And then there are the conspiracy theorists. (Score:2)
Hoagland thinks many of the Mars missions--including the failed European/Russian Mars 96 mission--were deliberately sabotaged by various space agency officials that want to prevent people from finding out that Mars used to not only have life, but intelligent life on that planet. You should read Hoagland's book The Monument of Mar
It's really quite simple (Score:5, Insightful)
Look at the Space Shuttle. The space shuttle has never had a catastrophic computer failure-- but every line of code on that truck has survived review by a group of programmers. They've examined it, line by line, multiple times, in order to ensure that it's exactly right, because the cost of failure is 7 astronauts and a multimillion dollar orbiter.
The new Mars programs, however, are part of the streamlined "do it on the cheap" NASA. NASA put the Mars Rover down using mostly off-the-shelf and open-source software and a small amount of home-brew stuff. No matter how good open source software gets, it still hasn't undergone the level of review that the Space Shuttle code has seen. No matter how popular an off-the-shelf package is, it's not cost-effective for the manufacturer to give it that sort of treatment. NASA can't afford to do that level of code review because that costs them the ability to do some other program.
NASA is simply trying to do more with less in the unmanned launches, and the cost of that is we need to expect some failures. These failures are unfortunately very visible...
-JDF
I don't get what's so hard ... (Score:5, Funny)
Then after 3 months you are then shot into a planet and stopped by a parachute and then some air bags. The entire time literally thrown into the surface.
And all this with the safety and security, of the lowest bidder.
I dunno, you tell ME why these missions have a high failure rate. Could it be there is no humans on board therefore not as much care is taken to insure the safe delievery of these machines? Could it be the fact that they are designed not to go to mars, but to go to mars as cheaply as possible. Could it be that no one really has a whole lot of information so a lot about mars is (pun intended) hit or miss?
Software is unreliable by design (Score:2)
I am on mission to mars - make way make way (Score:2)
One of my friends is (more or less) a rocket-scientist (or likes to think he is
He is currently doing a study on what it would take to launch a bunch of Kiwi's into space/orbit
(don't ask) using existing, off the shelf technology. It's part of his physics degree.
(IF he finishes his study I might see if we can get it linked on
Anyway, asked him about a mission to Mars the other
Disagreeing with Hemos (Score:5, Insightful)
I have to really disagree with this. NASA is used to dealing with alien climates and terrain and astronomical distances. NASA is also used to dealing with problems. They have some of the best problem solvers out there, and when something goes wrong, then tend to pinpoint why. When NASA says A, B, and C are the causes of failure, I believe them. When NASA cannot figure out why something went wrong, I worry.
What I'm trying to say is, distance and inhuman conditions shouldn't have that much of an affect on how well a probe works. We built Voyagers I and II, didn't we? They worked even better than expected. And they encountered climates and conditions which make Mars look easy.
NASA has dealt with so many varying circumstances and climates over the years, and been so blunt about their mistakes, I find it hard to believe that they would blame the failures of an entire class of missions on something "easy." And yes, blaiming failures on software is an easy way out, how many times have you heard someone say "Oh! It must be the software!" when something doesn't go as expected?
Now, I know this guy doesn't speak for NASA as a whole, but as a NASA trained administrator, and the head of some very large projects, I'm willing to take his opinions at face value. If he says it looks like software has really been a cause of failure, who am I to laugh at his expertise and belittle his explanations? I might not like his explanation, but I buy it.
Interesting... (Score:5, Funny)
Never test for an error condition you don't know how to handle. -- Steinbach
Software is Hard (Score:5, Insightful)
PHB's also haven't figured out that developers aren't interchangeable widgets. If you know C, it doesn't mean you'll be immediately productive in Korn shell scripting, and vice-versa.
PHB's also haven't figured out that experience is key. There are exceptions, but generally speaking, a young hotshot isn't going to be as productive as an experienced professional. Sure, the young hotshot might get v1.0 done first, but it'll be buggy, unreliable, unscalable, hard to maintain, etc.
The "problem with software" is almost entirely a management issue, imho.
-Teckla
Re:Software is Hard (Score:4, Insightful)
PHB's also haven't figured out that developers aren't interchangeable widgets. If you know C, it doesn't mean you'll be immediately productive in Korn shell scripting, and vice-versa.
I think this statement is true, but only because of the failure of education (or lack thereof). A good software analyst, is trained to think about the concepts, not the language. When I was a senior, we had a class where every project was a new language. One of the professor's summed it up, "Any monkey can learn a programming language by reading a book. An analyst will know what he's doing, no matter the language." It's all too sad that most employers hire based on language experience, and not successful software engineering practices.
The "problem with software" is almost entirely a management issue, imho.
For many reasons, but proper software engineering is understood but not popular. The results of a Cleanroom Engineering project have been well documented. Why isn't it popular? It doesn't have a fun sounding name and it's tedious to do correctly.
Certainly bad by comparison with Venus (Score:4, Interesting)
A more detailed comparison (Score:3, Informative)
Software (Score:4, Insightful)
I always thought that there should be a way, to build a probes navigation and propulsion systems in a standardized whay so that avionics software wouldn't need to change that much.
Sort of a standardized platform if you will for doing solar system exploration.
This platform would consist of a number of parts that would not change, and could be reusable in a number of different configurations for building a probe, depending on what its job was.
Cameras, photometers, spectrometers, and power sources could all be packaged in the same why depending on the probes job.
Every probe that nasa launches is always customized and built around cost and included packages.
I am not so sure that is the best way to go about it as you have to reinvent all the software to manage the probe every time you build one.
Probes should be cheap, produced in high volume, (thousands) and interchangeable.
With a standardized approach, failure rates should come down a bit and costs should be reduced.
-Hack
My space failure (Score:3, Interesting)
If we were to do it again, we probably would have had some kind of radiation-resistant reset system, because building the whole thing in rad-hard would be very expensive (our budget was $1500 plus donated equipment!) But having a few rad-hard devices to reset the box in case of a crash would probably have been affordable.
About 100 amateur radio operators contacted our payload, and relayed their GPS coordinates to others using amateur packet radio. At the same time, the GPS unit on board the Spartan satellite transmitted its position to listeners on the ground as well. But had it not crashed after about 17 hours, it is possible that several hundred other amateur radio operators would have used it.
You think Mars is tough? (Score:5, Funny)
Thick sulfuric acid atmosphere?
Gigantic storms?
Temperatures that will melt aluminium?
Ahh, I need to stop. I'm getting flashbacks of my ex-gf.
My dad was on the Viking project... (Score:4, Insightful)
Things to consider... (Score:3, Informative)
Before we continue to crucify programmers, we need to remember how hard it is to really get to Mars, from a purely spacefaring perspective.
From my experiences flying to Mars in Orbiter [orbitersim.com] space flight simulator (FREE!), several problems become apparent:
Mars is a fantastically difficult target to reach for two main reasons. It has very little gravity, and very little atmosphere.
If you shoot for something big, like Jupiter, you find that it is hard not to miss it. It's gravity well is so massive that navigational errors en route are relatively insignificant. Mars doesn't help you very much in this regard. An Earth to Mars flight has to be dead on.
When you get there, you are likely going to want to use the atmosphere to do at least part of the braking maneuver to get into Mars orbit (as most modern probes do). The problem is that Mars has a very thin atmosphere. Think about the sheet of paper analogies with Earth re-entry. Earth's atmosphere goes MUCH farther into space than does Mars'. You have to get dangerously close to the surface (within 50 miles) to effectively aerobrake using Mars' atmosphere. So with Mars, you are more talking about a near-ephemeral gossamer thin 1 cell thick membrane you have to hit the edge of rather than a nice, thick piece of paper.
Failure (Score:3, Insightful)
Problem is the statistics are biased (Score:5, Informative)
Take their early record, before Mars 1 got to Mars, they had had a series of attempts. Two, known to the West as Mars1960 A and B reached Earth orbit then disintegrated.
Mars1962 A exploded in orbit at the height of the Cuban Missile Crisis - briefly causing a panic with the Americans thinking a missile attack was underway. Fortunately the computers soon told them that doomsday had been averted.
Next, was a partial success - Mars 1. Which smashed the record for deep-space communications with Earth across a distance of 106 million kilometres. Unfortunately it failed just before reaching Mars.
Mars1962 B exploded in Earth orbit and didn't appear in the Soviet record.
November 1964 saw the launch of Zond 2, a highly advanced probe using ion thrusters to perform stabilisation and orientation tasks. It may have also been the first probe to carry a lander. It died a long and lingering death before sweeping past Mars at only 1400 km altitude. (By this time the US had got their first Mars probe to the planet in working order, Mariner 4 took 22 pictures of the planet from 10 000 km. (Its sister ship, Mariner 3 had failed en-route)).
Neither side went to Mars in the next launch window, but 1969 was a busy year. Three attempts for the Soviet Union, including at least one lander. Mars 1969A exploded in flight as did Mars 1969B. Mars 1969C was removed from the pad after cracks developed in the relatively new Proton rocket design. (Cracking in the Proton was also a major reason for the failure of the Soviet Union to send a manned mission around the Moon during 1969). The US had a twin success with Mariners 5 and 6 flying past Mars.
On to 1971 and a pair of launches for the US, Mariner 8 ended up in the Atlantic, Mariner 9 went on to become one of the most successful missions ever and the first probe to orbit Mars. For the Soviets - mixed results again. Their first mission reached Earth orbit, but went no further and was named Kosmos 419. But then both Mars 2 and 3 left Earth orbit. They each comprised of a lander and an orbiter. The two craft jettisoned the lander before entering Martian orbit - just as the planet entered an intense dust storm with raging winds and almost total blackout.
Mars 2's lander was apparently DOA, it remained silent and does not appear to have returned any data. It was however the first craft to hit (not land on) Mars. Mars 3's lander was more successful. It entered the atmosphere, deployed parachutes and landed on rockets. It deployed its antenna and began to transmit the first picture from the Martian surface. Sadly, just 20 seconds later the transmission stopped. The Soviets said that the lander's parachutes had been caught by the storm and pulled it over.
Mars 2 and Mars 3 orbiters remained on-line and performed experiments on the Martian atmosphere and took photos of the surface. So I would call both missions a partial success and Mars 3 almost a triumph.
The next window was 1973 and the Soviets planned no less than 4 missions to Mars. Mars 4 and Mars 5 would be orbital missions, studying the planet much like Mariner 9, but also serving as telecoms relays for the Mars 6 and Mars 7 heavy landers.
Incredibly, bearing in mind the past track record of the Soviets, all four missions reached Mars in working order. Then everything went wrong. Mars 4's main engine failed and the probe did not enter orbit, it relayed images of the planet as it swept past into solar orbit. Mars 5 was next and was the only unqualified success of the year; it was the first craft to return colour images of Mars.
The two landers then arrived, Mars 7 first, it deployed the lander, but an attitude problem meant that the lander actually missed the planet entirely! Mars 6 was more lucky, the probe entered the Martian atmosphere, took readings all the way down and went dead ab
Well-placed typo (Score:3, Funny)
But in the article:
That was just too perfect.
There's been a paradigm shift (Score:4, Interesting)
Here's the problem as I see it: As software and hardware have become more complicated, there's a need to increase testing. Instead, in order to meet NASA's new budgetary requirements, funding in general, and specifically for testing, has gone down. So, it's not possible to completely test all of the hardware AND software, as it should be.
As an analogy: If we were talking about commercial airliners; these probes would never be certified to fly.
I'm not putting all the blame on NASA here; although, it is apparent to me that they need to start reporting what it's actually going to cost. Having said that, Congress is equally complicit; they need to come to the realization that it's expensive to do work outside the atmosphere (they apparently don't understand this...)
Orbital Mechanics a contributing factor (Score:3, Insightful)
Re:The ancient n-body system... (Score:3, Interesting)
However much you may disagree, simple Newtonian dynamics and is all it takes to get a space probe from A to B in the vast majority of cases. It's a well-understood problem domain.
Dragging in stuff like chaotic long-term behavior of n-body systems, while an interesting fact in itself and worthy of study, has very little to do with the engineering
Re:It's physics, dudes. (Score:3, Interesting)
Your comment about manned vs unmanned makes absolutely no sense. One could buy a hundred or a thousand unmanned planetary missions for what a single manned mission would cost, and there would still be no guarantee that the manned mission would succeed. Yet we could easily afford to have many of those unmanned
Re:It's the programming language, stupid! (Score:3, Interesting)
A quote from a recent Newspaper article [theage.com.au]: