ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
More on Shuttle destruct systems The Challenger [non]accident Redundancy Galileo Plutonium power VDT's and birth defects in mice ORCON dissemination constraint on RISKS 1.43 Info on RISKS (comp.risks)
More on Shuttle destruct systems
This morning I talked to my successor at the Cape, who was in the Range Safety
area during the launch. I've got a few things to report and some questions to
answer from previous issues. I found out that the Range Safety Officer
commanded the destruction of the SRBs approximately 20 sec after the main
explosion, as they were careening wildly away from the site. Both SRBs did
explode on command. The mood at the Cape is described as "devastated",
especially among those who went outside to watch live. My successor also
reported that Range Safety had been officially cleared as of yesterday,
with respect to any responsibility for the accident; but that they expected
*much* closer scrutiny than before (which is, of course, perfectly fine.)
Interestingly, many of the media and a large percentage of the general public
were not aware of the existence of the destruct system.
The latest theory I have heard contains a "leak" in one of the SRBs resulting
in a 6000 C jet of flame cutting into the tank and igniting its fuel.
Now, individual responses:
> From: John Carpenter
> As I read the article [by Martin Moore in RISKS-1.43,] it occurred to me
> that as we discuss the risks of the destruct system we could be creating
> another risk by revealing the nature of it's operation...
> If the destruct system is public information, I would like to know why,
> If it isn't, it certainly has no place on the net.
Your point is well taken, and I did have some misgivings about posting the
original article; not because I was revealing anything I shouldn't, but
because I have no wish to be drawn into a national media controversy. Hence
the restrictions on dissemination of the article. None of the information in
the article was classified, and all of it was publicly available; and NASA is
very good about providing access to any information that isn't classified.
As to *why* it is public information...I think Neumann's response in 1-45
sums this up pretty well. Also, if it's not public, then the question that
will be raised is "what are they hiding?"
Incidentally, my successor told me that there is an article in this morning's
(1/31) Orlando Sentinel about the destruct system, at about the same level
of detail as my article in 1-43. Would some Central Florida reader be kind
enough to send me a summary or a copy of that article?
> From: Jeff Siegal <JBS%DEEP-THOUGHT@mit-eddie.MIT.EDU>
> Is there someone who knows enough about the security at NASA/KSC to be
> able to estimate the difficulty that a malicious party would have in
> getting getting physical access to the shuttle/SRB/MFT prior to the launch?
I'm not a physical security expert, but I believe that it would be
extraordinarily difficult to get physical access to the shuttle itself at
any time. Regarding the possibility raised by Kyle of a rifle shot, NASA
maintains a "clear zone" 1.5 miles (I think) in radius around the shuttle when
it is on the pad. This includes the closing of a public beach while the
shuttle is on the pad, invariably causing complaints from some local citizens.
> From: b-davis@utah-cs.ARPA (Brad Davis)
> It also brings up an important question. If the hardware system is
> redundant, what about the software system? Is the same software running
> on all of the redundant hardware systems or are there more than one
> software packages developed. If there is only one software package then
> if one system fails due to a software failure then the other systems'
> software may fail since the same conditions may still be in effect.
Each member of a redundant set runs the same software (obviously, computers
with different functions run different software). The danger you note is a
real one; however, I believe the best solution is to make each piece of
software as robust and fail-safe as possible. Consider that if redundant
computers were running different software, you could have a failure of
computer A and switchover to computer B without being able to reliably predict
what computer B was doing at that instant! The whole idea of redundancy is
that if a tool breaks in my hand, I want to be able to slap another one of the
same kind of tool into my hand and not miss a beat. What your point leads to
is to have additional tools for cases where the first one doesn't apply; this
is a good idea, but it actually falls under the heading of "robustness" rather
than "redundancy."
mjm
Re: Possible triggering of the self-destruct mechanism & (non)accident