Comment as part of a wider thread by Henry Spencer re writing code for satellites. ome pertinence to other systems. If you don't know Henry Spencer then Google will inform you. On Thu, 8 Jun 2006, Jonathan Goff wrote: > While you do still have to try and predict and mitigate some of the > worst potential failures up front, and some failure modes are > knowable > in advance, it's much nicer when you can just try out the design and > see > if the problem you were thinking about is real. Another example of this... The guys who write the control software for most satellites spend a *lot* of time analyzing and coding automatic fault recovery. "If happens, what should the software do?" There are three problems with this. The first is that it's time-consuming and expensive. The second is that it still misses things. And the third is that it can make the problem worse -- it's not unheard-of to lose spacecraft because automatic fault-recovery code got confused and did the wrong thing. (SOHO was lost that way, although control was eventually regained, and by pure luck there was little damage.) In the development of MOST, we made a point of avoiding all that. The spacecraft is unkillable -- the software cannot damage it. (This took considerable design effort; it was worth it.) So the software makes no attempt at automatic recovery. This is not to say that it never will; for example, the main computer can reboot the attitude-control computer, just in case there's someday a problem which might best be solved by having such reboots done automatically. But there's no code up there now which does that. Such code will be written only if such a problem actually shows up. So we didn't have to spend any time thinking about how to deal automatically with all the emergencies that will never happen. Henry Spencer henry@zoo.utoronto.ca (henry@spsystems.net) -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist