Conference noted::hackers_v1

201.0. "Shuttle Destruct System" by REX::MINOW () Thu Jan 30 1986 00:01

HACKERS is the closest thing to a "Software Engineering" notesfile.
The enclosed message, from Risks Digest with permission, is, sadly,
appropriate.  I might add that today's news said that the destruct
system was used to destroy the solid-fuel rockets after the shuttle
explosion.

Martin.
From:	RHEA::DECWRL::"RISKS@SRI-CSL.ARPA" "RISKS FORUM    (Peter G. Neumann, Coordinator)" 29-JAN-1986 15:04
To:	RISKS-LIST@SRI-CSL.ARPA
Subj:	RISKS-1.43

RISKS-LIST: RISKS-FORUM Digest,  Wednesday, 29 Jan 1986  Volume 1 : Issue 43

           FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS 
          sponsored by the ACM, Peter G. Neumann, moderator
Contents:
  Reliability of Shuttle Destruct System (Martin J. Moore) (LONG MESSAGE)
 [[Omitted from this posting:
  Challenger lost (and note on self-destruct mechanism) (Earle S. Kyle, jr.)
  Challenger ICING !!! (Werner Uhrig)
  Big Brother, again (Col. G. L. Sicherman)
 ]](MM)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious.  Diversity is welcome. 
(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.)
(Back issues Vol 1 Issue n stored in SRI-CSL:<RISKS>RISKS-1.n.)

----------------------------------------------------------------------

Date: 28 Jan 86 14:06:00 CDT
From: "MARTIN J. MOORE" <mooremj@eglin-vax>
Subject: Reliability of Shuttle Destruct System [LONG]
To: "risks" <risks@sri-csl>
Reply-To: "MARTIN J. MOORE" <mooremj@eglin-vax>

Copyright (c) 1986 Martin J. Moore          [COMMENT: READERS -- PLEASE OBSERVE
                                             THE RESTRICTIONS ON THIS MESSAGE
                                             AT THE END OF THE MESSAGE.  PGN]

> From: Peter G. Neumann <Neumann@SRI-CSL.ARPA>
> For those of you who haven't heard, the Challenger blew up this morning...
> One unvoiced concern from the RISKS point of view is the presence on each
> shuttle of a semi-automatic self-destruct mechanism.  Hopefully that
> mechanism cannot be accidentally triggered.  [COMMENT: I did not intend
                                              to imply that as the cause --
                                              only to raise concern about the
                                              safety of such mechanisms.  PGN]

Peter, I assume that you are talking about the Range Safety Command Destruct
System, which is used to destroy errant missiles launched from Cape Canaveral. 
From 1980 to 1983 I was the lead programmer/analyst on the ground portions of
that system, and I am the primary author of the software which translates the
closing of destruct switches into the RF destruct signals sent to the vehicle.
I think I can address the question of whether the system can be accidentally
triggered; worrying about that gave me nightmares off and on for months
while I was on the project.  I'd like to tell you a little about the system
and why I think the answer is No.  Note that my information is now three years
old, and some details may have changed; there may also be minor errors in 
detail due to lapses in my memory, which isn't as good as my computer's!

On board the vehicle, there are five destruct receivers: one on the external 
tank (ET) and two on each of the solid rocket boosters (SRBs).  There is no
receiver or destruct ordnance on the Orbiter; it is effectively just an 
airplane.  The casing of each SRB is mined with HMX, a high explosive; the ET 
contains a small pyrotechnic device which causes its load of liquid hydrogen 
and liquid oxygen to combine and combust.  The receivers and explosives are
connected such that the receipt of four proper ARM sequences followed by 
a proper FIRE sequence by any of the receivers will explode the ordnance.

The ARM sequence and FIRE sequence must come from the ground; they cannot be
generated aboard the vehicle.  These sequences are transmitted on a frequency 
which is reserved, at all times, for this purpose and this purpose alone.
There are several transmitters around the Eastern Test Range which can be used
to transmit the codes.  These transmitters have a power of 10 kw (continuous 
wave).  The ARM and FIRE sequences consist of thirteen tone pairs (different
for each command and changed for each launch).  There are eight possible 
tones, resulting in 28 possible tone pairs; thus, there are (28^13) or
slightly over 6.5E18 correct sequences.

The Range Safety Officer has two switches labeled "ARM" and "DESTRUCT".
When he throws a switch, it generates an interrupt in the central processor
(there are actually two central processors running and receiving all inputs,
but only one is on-line at any time; in case of software or hardware error
the backup is switched in.  And yes, they have different power sources.)
The central program checks for the correct code on each of two different
hardware lines (the correct code is different for each line); if correct,
and all criteria are met to allow the sequence to be sent, the central program
requests the tone pairs for that sequence from another processor.  That 
processor (like everything else in the system, actually redundant processors)
has only one function: to store and deliver those tone pairs.  The processor
resides in a special vault and can only be accessed in order to program the
tone pairs (which are highly classified) before each launch.  The data line
between the central processor and the storage processor is electrically
connected ONLY when the ARM or DESTRUCT switch is actually thrown; this
prevents a wild program from retrieving the tone pairs. 

When the central program has retrieved the tone pairs, it formats a message
to the currently selected remote transmitter.  As the final step before 
sending the message, the program checks the switch hardware one more time 
to make sure the command is, in fact, requested.  If so, the message is sent
to the site on two modems (with different power supplies and geographically 
diverse communications paths) and, after sending the message, erases the tone 
paris from its memory.  The remote site, until this time, does not know the
tone pairs.  When the site receives and validates the message, it sends a
request for confirmation back to the central processor.  When Central
receives this request, it checks the switch hardware again and retrieves a 
fresh copy of the tone pairs from the storage processor to make sure that the 
site got the correct tone pairs.  If all these checks pass, Central issues
a go-ahead message to the site, which then (if the message is validated) 
actually transmits the sequence to the vehicle.  During this sequence of 
messages, if any message fails, it is retransmitted, with a check of the 
switch hardware before each transmission.

Let's look at some areas that could cause an accidental trigger:

1. Failure of switch hardware.  This would take at least six circuits failing 
   to the "1" state, while 12 others connected to them would have to NOT fail.

2. Central software error.  There is a lot of reliabilty checking, details of
   which are too long to repeat here; but even if there is a hole through it,
   the central program cannot get the tone pairs unless the switch is thrown!

3. Site software error.  Doesn't have the tone pairs until sent by Central.

4. Destruct receiver failure.  I didn't work with this directly (being 
   strictly on the ground side) but everything I've seen makes them look
   very reliable and fail-safe.

5. External sabotage.  A hostile agent would have to (1) steal the tone pairs,
   and (2) overpower our 10 kw CW transmitters which are saturating the
   destruct receivers with a 70 dB margin.  Alternatively, if someone tried
   to overpower the central area, I think they would fail.  Security is TIGHT
   around the central control area;  I don't think I can go into detail without
   upsetting NASA and the Air Force.

7. Internal sabotage.  One thing I did was to imagine that I was a saboteur
   and think of a way that I could program in a Trojan Horse to send a false
   command.  Eventually, the system was such that I could not do it.  NASA
   also hired an independent contractor to perform reliability analyses.
   NOBODY can send a command except the Range Safety Officer when he throws
   the switch.

The Challenger explosion was NOT caused by the Range Safety system, either
intentional or accidental.

I am really sorry about the length of this message, but I wanted to get all of 
that in.  All information contained herein is UNOFFICIAL and furnished for
information purposes only.  It is in no way official information from my
employer (RCA), the U.S. Air Force, NASA, or any other government agency.

Due to the sensitive nature of this incident, this article is not for 
reproduction or retransmittal without the express permission of the author.
Permission is hereby granted to Peter G. Neumann to include this material
in the RISKS electronic mail digest.

                                      Martin J. Moore
                                      mooremj@eglin-vax.arpa

[MARTIN: MANY THANKS FOR THIS EXTRAORDINARY MESSAGE.  
 READERS: PLEASE OBSERVE THE ABOVE CAVEAT SCRUPULOUSLY.  PGNeumann]

From:	REX::MINOW        "Martin Minow, DECtalk Engineering ML3-1/U47 223-9922" 29-JAN-1986 18:20
To:	MINOW
Subj:	sent to mooremj@eglin-vax.arpa and neumann@sri-csl.arpa

Thank you very much for an extremely interesting article.

May I please reprint your message in a Dec-internal "bulletin-board"?
It is read by many software engineers, and can *only* be accessed
by Dec employees and contractors.

By the way, my first job at Dec was a residency at an aircraft
company, doing system-level programming for the data-collection
system for a new plane.  When I started, my host said "we have
only one criteria -- the program must run correctly for 45 minutes,
as we can't back the plane up."  You had a much more difficult task,
and, judging from your article, appear to have done an excellent job.

Martin Minow
minow%rex.dec@decwrl.arpa
(617) 493-9922

Posted:	Wed 29-Jan-1986 18:19 Maynard Time.  Martin Minow MLO3-3/U8, DTN 223-9922
To:	RHEA::DECWRL::"mooremj@eglin-vax.arpa",RHEA::DECWRL::"neumann@sri-csl.arpa"

From:	RHEA::DECWRL::""MARTIN J. MOORE" mooremj@eglin-vax" 29-JAN-1986 20:45
To:	"minow%rex.dec" <minow%rex.dec@decwrl>
Subj:	reprint request

Received: from DECWRL by DEC-RHEA with SMTP; Wed, 29 Jan 86 17:44-PST
Received: from eglin-vax.ARPA by decwrl.DEC.COM (4.22.01/4.7.34)
	id AA02902; Wed, 29 Jan 86 17:43:45 pst
Date: 0  0 00:00:00 CDT
Cc: mooremj@eglin-vax
Message-Id: <8601300143.AA02902@decwrl.DEC.COM>
Reply-To: "MARTIN J. MOORE" <mooremj@eglin-vax>

Mr. Minow,

You have my permission to retransmit my article in RISKS 1-43 to your
bulletin board.  I suggest you add a line saying "Reprinted with permission"
to the text.  Many thanks for your kind compliments.

                                 Martin J. Moore (mooremj@eglin-vax.arpa)
------

	...I got this earlier today. Many of the USENET files are worth
subscrbing to... Though a novice at USENETTING, give it a try. Theres lotsa
good stuff (and good people) out there.

	-John