I hope the frugal engineering works out for them. In 1990 I spent a semester working at GE AstroSpace as an intern, and one of my tasks was a small role on the Mars Observer(1) probe. It was also a frugal, based on an Earth-orbiting satellite design that was repurposed for a deep-space mission to Mars orbit. It apparently blew up when it got there, likely due to a failure in the fuel system. That's where I come in.

In early 1990, there was a weight problem with the spacecraft, and the engineers were looking for ways to eliminate mass. I was working with the propulsion team, and my task was to go through all of the blueprints, count components, and document their mass. The team was going to use that to determine which components were redundant (for safety) and how much mass could be eliminated by removing them.

I did my task, and went on to something else so I don't know how the system was modified. But from what I've read about the loss of the spacecraft, a leading theory is that one of the valves in the propulsion system failed and that led to the explosion. The valves were designed to be opened very soon after launch, once the satellite reached Earth orbit; they weren't designed for the deep-freeze of a two-year trip to Mars before being opened. I beleive that not only did the valve malfunction, but its redundant backup had also been removed based, in part, on the task I performed. If there hadn't been a weight problem (which may also have been to frugal engineering to reduce fuel requirements), the explosion might not have happened.

I've never felt any responsibilty; my task was to provide information, not decisions. But it would have been nice if I was involved with a more successful mission.

(1) http://en.wikipedia.org/wiki/Mars_Observer

Thanks for sharing your anecdote!

In fact, ISRO's Moon mission Chandrayaan-1 ended prematurely due to overheating of star sensor and power supply unit (inadequate thermal protection!). They underestimated the amount of radiation from the Sun and that reflected by the Moon, at an orbit of 100km from the Moon[1].

For MOM, ISRO has "hardened" their satellite bus with better thermal protection, larger solar panels, redundant subsystems, redundant fuel lines, FDIR system etc.[2] Hoping for the best :)

[1]http://www.brighthub.com/science/space/articles/48921.aspx

[2]http://www.isro.gov.in/pslv-c25/pdf/pslv-c25-brochure.pdf ("Major Challenges" section)

Cool. Another of my jobs at GE AstroSpace involved writing software to help with the analysis of thermal system modeling. At its heart, thermal modeling is basically the same as one of the approaches for lighting models for 3D graphics: every surface within the spacecraft is radiating and absorbing heat from every other surface that it faces. This is similar to the way every surface in a 3D model visualization is emitting, reflecting, and absorbing various frequencies of light from every other surface it faces in the model.

The math is the same, but in the thermal model you're calculating an equilibrium state to figure out the final temperature of each surface, or cyclic variation in the case of a rotating spacecraft with the sun and other emitting bodies around it. That tells you if temperatures are within the tolerance range of the components over the mission lifetime. If not, you have to add thermal protection and rerun the simulation.

This probably all goes a lot faster today than it did on the 1990's era VAX minicomputer I was using. There's probably real-time visualization now, which I'll bet is pretty cool.

This is very interesting! I wonder if it'll ever come to the point where it'll be cheaper to just do trial and error more often and keep fixing issues than to take the big-design-up-front approach.

I doubt it. Unlike software, the material costs for a spaceflight are substantial and they're mostly/completely unrecoverable. Especially if your trial becomes an error.

[edit] Also, building, launching, and operating spacecraft are a lot more like bridge building and other non-software engineering projects. Each spacecraft may be unique, but they're made up of well-understood parts that go together in well-understood ways using time-testing engineering practices that make simulations and modeling truly useful and big-design-up-front feasible. We don't have much of that in software engineering yet, so trial-and-error is still a necessary tactic.