[AR] Re: failure recovery (was Re: Re: Flight Controller Features)

  • From: "Hugh Blair-Smith" <hugh.bs@xxxxxxxxxxx>
  • To: <arocket@xxxxxxxxxxxxx>
  • Date: Mon, 18 Jan 2016 15:11:50 -0500

Hello, I'm a newbie to this list, steered to it by MIT's David Chandler.
I've just published my first book, "Left Brains for the Right Stuff:
Computers, Space, and History" (do I have to put an [AD] flag here just for
mentioning that?). It's based on my Apollo and Space Shuttle work at MIT
Instrumentation/Draper Lab, 1959-1981, and one thing I do there is trace the
understanding of these program alarms from the very first hint of their
possibility as a consequence of Rendezvous Radar configuration.

I had to flip a coin to see whether to post to this thread or the Apollo 11
alarms thread, and I found a particularly stimulating assertion here: "...
the probability that Apollo 11, as flown, would have them during descent was
was actually 100%." My research, in which Don Eyles and the late George
Silver participated, shows that the probability was about 1% if you admit
that the exact instant of powering up the LM systems was a random variable
impossible to control. And I report that the NASA powers involved estimated
the probability as "way too small to worry about" compared to all the other
interesting risks in the project. But certainly our design of the system
software to deal flexibly with any unforeseen contingency was essential to
the mission's success. I'm confident that many who post to these threads
will find my book a useful resource! [/AD]

Hugh Blair-Smith

-----Original Message-----
From: arocket-bounce@xxxxxxxxxxxxx [mailto:arocket-bounce@xxxxxxxxxxxxx] On
Behalf Of Henry Spencer
Sent: Sunday, January 17, 2016 11:20 PM
To: Arocket List
Subject: [AR] failure recovery (was Re: Re: Flight Controller Features)

On Sat, 16 Jan 2016, Norman Yarvin wrote:

...if you really needed a piece of state, that might not be enough; you 
might have to save two copies of it, each with a checksum, and refresh 
them alternately.

Which is actually a rather trivial increment in complexity over having 
just one save area, i.e. you might as well do it if you're saving at all, 
unless the save memory is a very limited resource.

That level of paranoia, worrying about rare subcases of rare cases, is
worth it when one is writing an operating system to be used by
millions of people.  For amateur rockets, not so much: you're not
going to have literally trillions of tries at hitting the ultra-rare
behavior.

Assuming, that is, that you have guessed right about that behavior being 
"ultra-rare".  Usually the problem is not that you drew the ace of spades, 
but that your estimate of the probability was wrong.  Apollo program 
alarms were supposed to be "can't happen" behavior, *never* happening in 
flight, yet the probability that Apollo 11, as flown, would have them 
during descent was actually 100%.

The issue is not whether it makes sense to take precautions against some 
specific bit of supposedly-ultra-rare behavior, but rather, whether it 
makes sense to take generic precautions against surprises, rather than 
just having the software throw up its hands and give up when something 
weird and unexpected happens.  Weird nonsense does happen.  Surprisingly 
often, simple attempts to recover and carry on actually work adequately 
well for most cases, so they are worth a bit of thought and effort.

In fact, generic precautions are what you *want*, not only because the 
individual types of weird nonsense seem so unlikely, but also because 
attempts to automatically *diagnose* the exact problem are notorious for 
making mistakes.  (The problem wasn't an expected one, or the symptoms 
weren't as expected, or the rarely-exercised diagnosis code itself had 
bugs.)  It's not only easier, but also more robust, to just punt all the 
weird nonsense to generic "standardize state and try to resume" code.

How much effort this is worth, is an engineering decision.  But assuming 
that it's zero without even thinking about it is usually a mistake.

Henry


Other related posts:

  1. Home
  2. arocket
  3. Archive
  4. 01-2016