Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
>From: desj@brahms.berkeley.edu (David desJardins)
>[T]he destruction of the SRBs...is a human rather than a computer error.
It was certainly a human action but I do not agree that it was an error.
That we now — long after the fact — would like to retrieve the boosters
is unfortunate; but had they not been destroyed they would either have
ended up in the drink anyway (possibly much further away from the Cape and in
much deeper water, making the recovery even more difficult than it is) or they
would have endangered a land area.
> NASA admits that the SRBs were not in fact endangering anything at the time
> that they were destroyed...there must be an almost irresistible temptation
> for the range safety officer to do the "safe" thing.
First, the destruct decision does not come from NASA; it comes from the Air
Force. Second, there is no "temptation" involved; the range safety officer
MUST DO the safe thing based on the information available in real time. He
did so. For more on the information available to the RSO, see below.
> Perhaps this is the inevitable result of having humans making
> these decisions (error on the side of safety).
Would you prefer error on the side of non-safety? Or are you advocating the
use of computers to make the actual destruct decision? If the latter, you
will have a hard time getting anyone to fly the vehicle! Also, in the
Challenger case, a computer would have made the same decision to destroy the
SRBs. While I was at the Cape, there was some investigation into the
possibility of automating the destruct decision; it was decided that even if
it were safe and reliable, it could only be used on unmanned launches. Since
the number of unmanned launches would decrease dramatically in the coming
years, an automatic destruct decision system would not be cost-effective.
> I'm not sure that anything can really be done about this, except to
> provide extensive training and an adequate supply of information on which
> to base the actual decisions. Do the range safety officers have access
> to real-time flight-path projections and similar information that would
> allow them to make intelligent decisions?
The RSO's do receive *extensive* training. Being an RSO is a full-time job,
not an extra duty; the RSO's are either Air Force officers or high-grade
civil servants (incidentally, I was once encouraged by some of the RSO's to
apply for an opening in their number. I am REALLY glad I decided not to!).
Their training includes realistic launch simulations in which various
things go wrong. The problems include not only wild trajectories but
equipment and people problems; during the simulations, one of the RSOs is in
charge of setting up the problems. They perform this duty on a rotating basis
and it is quite competitive. In addition to the real-time training, there is
"office" training in which they study the effects of various missiles,
possible debris footprints, etc.
Regarding flight projections: tracking data are gathered from a variety of
sources, including radars, inertial guidance telemetry, and optical trackers
(mainly used very early in flight when radars are ineffective due to
multipath.) The tracking data is fed to the Central Computer (redundant Cyber
740s) where through various filtering and checking the two "best" sources are
chosen, and used to determine the vehicle's position and velocity, and to
compute from them the Instantaneous Impact Point (IIP), which is the point at
which the vehicle would impact if thrust were to terminate at that instant.
The RSO has a lot of information displayed on his consoles: the primary and
alternate position, velocity, and IIP, real-time telemetry from the vehicle
(e.g., engine chamber pressures), live video coverage, and others. The RSO
uses this information (plus comm links to the Flight Director in Houston on a
manned launch) to make his decisions. The present position itself is not
critical; it is the IIP that determines when an area is endangered. The RSO
has displays of the nearby land masses, with "destruct lines" drawn some
distance out to sea; if an IIP crosses a destruct line, the land area is
endangered and the missile should be destroyed. Also, if a vehicle is
obviously wild (such as an orphaned SRB) it should be destroyed while still in
a safe area *before* it can endanger the land mass! This is why the RSO's
decision was not an error. As I understand it, although the SRB had not yet
crossed the destruct line, it had curved back toward the coast and would have
crossed the line in a few seconds.
From my observations, I evolved my own rough rules-of-thumb for destroying a
missile. These are purely my personal observations, they're not official,
and they're pretty general, so please don't nitpick at them.
----
IF (missile is unmanned) THEN
IF (IIP crosses destruct line) OR (missile is obviously out of control)
OR (missile is out of communications for a length of time sufficient
to endanger any area from its last known position) OR (pad disaster occurs
— e.g., vehicle falls over after ignition) THEN
Destroy the missile.
ELSE IF (missile is manned) THEN
IF ((IIP crosses destruct line) AND (Houston reports the flight crew is
*not* in control of the vehicle)) OR (pad disaster occurs) THEN
Destroy the missile.
END IF
----
SRBs flying by themselves are certainly unmanned and obviously out of control.
Sorry about the length of this message, but I'm getting a little tired of
hearing people second-guess the RSO's decision. The RSO in question is one of
the most intelligent and capable individuals I have ever known; he made the
correct decision based on the real-time information, and that's what he is
supposed to do. One SRB was heading toward the coast, and even though it
had not yet crossed the destruct line, the risk to the population was
significant (and increasing). He unquestionably made the right decision based
on the information at the time.
Martin Moore
Disclaimer: I disclaim everything.
The recent discussion of computer clocks showing the wrong time has reminded me of a related problem — clock synchronization on computers. For example, I will sometimes receive a message from someone on another host on campus where the "time received" on my host will be earlier than the "time sent" on his machine! Granted, clock synchronization with electronic mail isn't really that critical, but I can think of a lot of other applications where having clocks out of sync with each other would be totally unacceptable.
The CP-6 operating system has an interesting integrity check for
timestamp setting. On a warm or cold boot the operator is asked for the
date and time. This is compared with the timestamp on the last error
log entry. If the 'new' timestamp is earlier than the error log entry
or is more than nine hours later then a timewarp error is reported and
confirmation is requested. If the operator chooses to reject the time
he entered he can make a correction.
There are two problems with this system. First, if a new system is
being built there are no error log files. I think the base time stamp
(1978-01-01 00:00) is used in this case. Second, it is possible for
there to have been no error recorded in a nine hour period. This
actually happened to us a couple of times, so we now write a dummy error
log entry every four hours. I am thinking of stepping this up to once
per hour in case the system is down at exactly 00:00 or 04:00 or ...
This system has its drawbacks, but helps to reduce the risks of
setting an unreasonable timestamp at system startup.
/jc
[SINCE MY GUESS IS THAT MOST OF YOU ARE NOT READING
SOFT-ENG@XX.LCS.MIT.EDU, IT SEEMED WORTH INCLUDING
THIS HERE. PGN]
The following is a "summary" of a talk given by Danny Cohen of ISI. Dr. Cohen
is chair of the SDI Organization (SDIO) and a member of the "Eastport Group", a
panel on computing in support of battle management:
The Eastport Group panel was appointed to devise an appropriate
computational/communication response to the SDI battle management computing
problem and make recommendations for a research and technology development
program to implement the response.
The panel concluded that computing resources and battle management
software for a strategic defense system are within the capabilities of the
hardware and software technologies that could be developed within the next
several years.
However, the anticipated complexity of the battle management software
and the necessity to test, simulate, modify, and evolve the system make
battle management and command, control, and communication (BM/C3) the
paramount strategic defense problem.
Software technology is developing against inflexible limits in the
complexity and reliability that can be achieved. The tradeoffs necessary
to make the software task tractable are in the system architecture. The
"applique approach" of designing the system first and then writing the
software to control it is the wrong approach is the wrong approach for SDI.
System architecture and battle management must be developed together. This
was suggested in an earlier report on SDI known as teh Fletcher Report.
One promising class of system architectures for a strategic defense system
are those that are less dependent on tight coordination that what is implied
by the Fletcher Report. The advantages of this type of architecture include
robustness, simplicity, and the ability to infer the performance of full-
scale deployment by evaluating the performance of small parts of the system.
The panel prefers an unconventional architecture that simplifies the soft-
ware development and testing tasks over reliance on radical software develop-
ment approaches and the risk that reliable software could not be developed
by the "applique approach" at any cost.
1) I did not personally see this, but I was told that Symbolics briefly introduced a new feature in their mail program with the current release of the operating system. It was a new header line that a sender could use to include graphics as part of the mail message. This was implemented by having the header line include a lisp expression that would be evaluated (executed) when the receiving mailer loaded the message for display. Somebody pointed out the other possible ways in which an arbitrary piece of executed code in a mail message could be used, and that feature was dropped very quickly. 2) This is not quite on the same level as the above problem, or the old control character in the message trick, but the following message appeared in my mailbox some 5 or 6 times over the course of a couple of days. It's relevant to RISKS as yet another real life example of "nothing can go wrong... go wrong... go wrong..." The message was sent to a net distribution list: [begin edited forwarded message:] To: info-gnu@PREP.AI.MIT.EDU, info-gnu-emacs@PREP.AI.MIT.EDU Subject: Duplicate messages 1) Apologies from the chief gnu list maintainer. 2) For a variety of reasons, this happens intermittenly on prep, an MIT AI Lab machine the lists are hosted on. For a variety of reasons, there is little that the GNU staff can do about it, at this time. 3) Thanx for your patience. [End of edited forwarded message] Sidney Markowitz <sidney%oz@mit-mc.arpa>
From ucdavis!uucp Tue Mar 18 22:41:20 1986
Date: Tue, 18 Mar 86 22:17:29 pst
Mail failed. Letter returned to sender.
>From seismo!harvard!think!mit-eddie!genrad!panda!talcott!maynard!campbell
Tue Mar 18 21:30:28 1986 remote from lll-crg
[...AS USUAL, I DELETED THE ROUTING, ALTHOUGH IT WAS EXCITING...]
Date: Tue, 18 Mar 86 17:36:01 EST
To: ucdavis!ucbvax!sri-csl.arpa!
Subject: Why would anyone want to computerize voting?
Why would anyone want to computerize voting? Doing so only increases the
risk of fraud, by reducing the number of people involved in the process.
("The best deterrent to crime — witnesses.") Elections don't happen often
enough that saving money can count for much — in fact, I believe around
here ballot counters are unpaid volunteers. Rapidity of the count? Who
cares whether the results are known in two hours or two days?
Sounds like yet another scheme (remember "computer literacy"?) to enrich
computer companies at the public's expense.
[There are of course lots of reasons for automating. But PLEASE,
let's not get a flurry of messages answering that one here. This
is just another fine example of a more complicated solution
introducing new vulnerabilities and different risks. PGN]
Larry Campbell The Boston Software Works, Inc.
ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street
UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
On the subject of the bill-denomination-determining in Canada, there is a
method that I noticed is in use in Israel when I was there recently: on
every denomination of shekel notes there is a unique raised pattern of lines
for the use of the sight-impaired and to aid in annoying counterfeiters.
For example, on the five-shekel note there are three dots formed of these
lines, each about 4 mm in diameter, and on the 500 shekel note there is an
oval shape made of the raised lines about 12 mm long and 4 mm wide.
The biggest benefits of this system, in addition to making counterfeiting
harder, are that is is cheap, there is no computer 'denomination reader' to
have vandalized, and that the blind persons who use this service wouldn't
have to go out and find one of these silly machines...
Atrocity Joelll
JOELLL%Umass.Bitnet@wiscvm.wisc.edu
[One must carefully examine the code of raised symbols to see how
easily a lower denomination can be changed into a higher
denomination. In Braille, for example, it is easy to change a
TWO into a ONE (assuming the fingers do not detect a rough
flattened spot) and a ONE into a TWO (by raising an extra spot).
By the way, there are situations in which one might wish to make
a higher denomination appear as a lower denomination... fooling
a blind customs official with Altered Braille? PGN]
Please report problems with the web pages to the maintainer