From: henry@spsystems.net   
      
   In article <1105058011.390447.191060@z14g2000cwz.googlegroups.com>,   
   greg.ewing@gmail.com  wrote:   
   >Aerospace software has  a totaly different culture. Testing takes up   
   >huge amounts of time, using a much more complete set of debug tools   
   >that are not usally used in plain software.   
      
   Depends on *which* aerospace software it is.  The software for the MOST   
   astronomy satellite doesn't get anywhere near such elaborate attention.   
   But then, the software basically can't do anything to break MOST.  And   
   no, that's not an accident -- we worked hard to make sure of that!   
      
   For example, on a typical satellite, loss of attitude control is a   
   terrible emergency, because it means the solar arrays are no longer   
   pointed at the Sun and you've only got (at most) a few hours until the   
   batteries are drained.  Spacecraft have died that way.  For the same   
   reason, rapid acquisition of Sun pointing immediately after launch is   
   extremely critical.   
      
   MOST was in a random tumble for a month after launch, while some other   
   problems were solved.  Nobody worried.  The spacecraft has solar arrays   
   on all six sides -- not enough for full power, but enough for crucial   
   functions (main computer and radio receivers).  And when the batteries   
   approach empty, the power system hardware switches off everything except   
   crucial functions.  (It tries to switch off everything, but there are   
   no power switches on the computer and the receivers.)  There is no   
   attitude in which the spacecraft doesn't have a positive power balance.   
      
   The result is software that's *far* cheaper to develop.  Also a more   
   robust spacecraft:  even the inordinately expensive classical process can   
   *and does* make mistakes, which can kill spacecraft.  MOST is essentially   
   unkillable.  (Credit where due:  we got this approach from the Amsat   
   people, who do the amateur-radio satellites.)   
      
   You couldn't quite do that for things with time-critical functions, like   
   aircraft and launchers.  Even there, though, it would be interesting to   
   see how far you *could* get in designing the total system to survive   
   imperfect software, rather than assuming the software must be perfect and   
   will be made so regardless of cost.   
   --   
   "Think outside the box -- the box isn't our friend."    |   Henry Spencer   
                                   -- George Herbert       | henry@spsystems.net   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)