The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 3 Issue 88

Monday, 27 October 1986

Contents

o SDI, Missing engines, feeping creatureism in consumer products
Roy Smith
o More aircraft instrumentation
John Allred
o Re: Military vs. civilian automatic control systems
Eugene Miya
o Perfection
Douglas Humphrey
o Shipboard anecdotes
Mike McLaughlin
o RISKS UNDIGESTIFIER on UNIX
John Romine
o Info on RISKS (comp.risks)

SDI, Missing engines, feeping creatureism in consumer products

Roy Smith <cmcl2!phri!roy@seismo.CSS.GOV>
Thu, 23 Oct 86 15:28:25 edt
    This message is a potpouri of several random thoughts that I've had
in the past few days.  The first two are apropos to recent topics on RISKS,
the last is new material.

    Re: SDI and unexpected inputs.  I have a friend who works for the
Army Night Vision Lab (I'm not sure that's actually the correct name).
They work on "find the tank in the jungle at night" problems.  He once
described a program that looks for tanks in a battlefield -- the first
thing it does is find the horizon and concentrate on the area below (i.e.
the ground).  My first thought was "what happens when they start dropping
tanks by parachute?"

    Re: Planes loosing engines.  I gather than in many of the cases of
planes having gross defects (i.e. a control surface torn off), the
situation was at least meta-stable until the pilot tried to do something
(i.e. turned off the auto-pilot to take control).  I'm just guessing, but
it seems that a chase plane could take off and intercept the damaged plane
to make a visual inspection of its exterior quickly enough to be of some
use.  Am I being naive to think that this would be 1) practical and 2) of
any use?  Is it done already?

    Re: feeping creatureism.  There is an annoying trend towards
computerizing things that just don't need computerization.  Even worse is
the urge to make things *seem* computerized when the microprocessor in them
does nothing more than scan for switch closures on the control panel and
run a simple timer.  I recently bought an air conditioner -- it doesn't
have a control panel, it has a "command center".  It has the same controls
(on/off, etc) as any other air-conditioner, but the panel is made up to
look like some sort of computerized gizmo.  My new electric dryer is the
same way -- it's got "electronic drying", which means is it has a
thermostat is the exhaust vent just like my mother's old mechanical-timer
model.  Speaking of my mother, she just bought a new car and hasn't figured
out how the radio works yet because the familiar volume and tuning knobs
aren't there any more.

    So, how does all this tie in with COMPUTER RISKS?  Take the dryer;
by making it appear that there is some kind of computerized system
monitoring and controlling the drying process, the consumer is duped into
believing that his dryer is somehow better than the old ones.  He doesn't
really understand *why* it is better, but since it computerized, it *must*
be better, right?  Likewise with the car radio.  While it may be true that
digitally synthesized tuning is better than mechanical variable capacitors,
(let's not start arguing about *that*) there was nothing wrong with the
user interface (2 knobs to turn, maybe some pre-set pushbuttons).  While
the real advantage of the new radio over the old is the PLL instead of the
variable cap, the *percieved* advantage is the "tune-up/tune-down" buttons
instead of the tuning knob to turn.  In fact, the new-fangled user
interface is no better than the old one, and may in fact be worse.

Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016


more aircraft instrumentation

John Allred <jallred@labs-b.bbn.com>
Mon, 27 Oct 86 10:35:39 EST
Doug Humphrey asks:
   " ...  I am not sure why a pilot would need a video monitor to tell him that
     Number 2 just fell off the wing, ... .  He will no doubt understand this
     by the way the aircraft is acting."

A perfect example of why a pilot could use a monitor is the American Airline
DC-10 crash at O'hare.  The pilots knew they had lost power on the engine.
However, they had no way of knowing that they had physically lost the engine
(because you can't see the engines from the DC-10 cockpit.)  Upon detecting
that they had lost power in one engine, the pilots went exactly by the book -
they changed the airspeed to best-2-engine-climb speed.  Unfortunately, when
the engine fell off the wing, it also ripped out some hydraulic lines in the
wing, which were holding the slats (high lift devices on the leading edge of
the wing) extended.  With the slats retracted, the stall speed of the damaged
wing was *above* best-2-engine-climb speed.  So, one wing stalled, the other
kept generating lift, and the plane rolled over.

It should also be noted that pilots in simulators, when given the exact same
situation, were able to save the aircraft when they knew that they had
physically lost the engine, while pilots that did not know uniformly failed to
save the aircraft.

Doug is correct in stating that a pilot should be able to understand if he's
lost something important.  However, that understanding could come too late, or
in and of itself be fatal.


Re: Military vs. civilian automatic control systems

Eugene Miya <eugene@AMES-NAS.ARPA>
Mon, 27 Oct 86 09:04:33 pst
I basically agree with Will's thesis about missions, but I don't
the difference is that simple (binary).  Two years ago, an F-8 Crusader
(single engine Navy fighter, older) lost power over San Diego.  The
pilot had time to eject, but before doing so, he tried to avoid hitting
buildings in the Serrento Valley area.  (True he might have misjudged
prior to ejection, but the plane did come down in a parking lot
and not the nearby electronics buildings.)  Many pilots have faced this
dilemma in the past: including civilian pilots (do I kill several hundred
people on the ground in addition to the passengers I have just killed?).
I think this also goes for civilian rescue missions.  Ford' Mayeguez (sp)
mission in 1975 cost more Marine lives than civilians rescued.  True
we will never know the real political consequences of not rescueing
(liberals: "we would have negiotated release," conservatives: "they would
have died"), but my point is many of the fundamental types of systems
are no different in the civilian or military sphere, and that there is
overlap (with tricky trade offs) with military operations.

--eugene miya


Perfection

Douglas Humphrey <deh@eneevax.umd.edu>
Mon, 27 Oct 86 02:52:25 EST

To LIN : In response to a message, you state that none of the anti-SDI
         folk ever stated that the software had to be perfect. I have 
         heard constantly in both the widely read (Washington Post) and
         limited (?) distribution industry media (Aviation Leak and 
         Space Mythology) SDI critics that contect that it must be perfect
         or it is useless. I don't beleive this, and I would hope you
         don't either, but saying that the whole must be perfect 
         certainly implies that the parts must be perfect. (Opps. contend..)

         About failure modes in software systems, yes, it is possible to
         design fault tolerant and fault permissive systems. Systems that 
         have a know 'prefered failure mode'. Example, hardened underground
         facilities, I have been told (no references here) are not designed
         to withstand forces equaly throughout the structure. That would mean
         that when the structure finaly failed under load, there would be no 
         reliable way to project where the failure would happen. Better to 
         design with structural over load failure in mind and specificaly
         designate one area as the failure area, and then take withever
         measures one can (air/water tight bulkheads, etc.) in that
         area since you now have a high degree of confidence that the failure
         will happen where you want it, and are ready for it.
         Software can be designed the same way by dealing not only with the 
         quantity (targets) by the quality of targets (destinations) and 
         selectivly 'failing' on those which are the least important.

         I would guess that a catostrophic failure would be the one
         to avoid, even of the system decided that it was time to reboot, 
         clearing target tracking data since some of it was detected as 
         bad. The system might then let through whatever was locked at the
         time of the failure, but at least it would resume defense rather than 
         either crash outright, or get into a position where its target load
         started to effect its real time processing and maybe preventing it
         from reacting well enough to to its job. 

         Hey ! If we get flaming about this much deeper, we should all start 
         submitting bills to SDIO.......

Doug


Shipboard anecdotes [marginally relevant but intersting]

Mike McLaughlin <mikemcl@nrl-csr>
Mon, 27 Oct 86 13:05:11 est
Two anecdotes about shipboard emergencies.  
    In that fire, one sailor did think about what was happening, and
ran aft as fast as his little legs would carry him.  A _giant_ Chief Gunner's
Mate named Mills grabbed him, pointed him back to his battle station, and
said something like "Son, you better get to your battlestation.  When a 
destroyer has a fire in a magazine, you just can't run far enough!"

    In another emergency that was really too complex to explain on
Risks, I _really_ went automatic.  I had far more charge of the situation, 
and far more depended on my own actions.  Simply put, the USS Saratoga was
about to run over us, and we had lost control of our rudders.  I did the
requisite things, and am here to tell about it.  But _during_ the experience
I was "out of body" - Some part of me was floating above and behind me, 
watching me give orders & do things, sort of supervising/monitoring me,
but not interfering.  I have no recollection of the situation from my
body's eyes and ears once the situation developed.  All of my quite 
detailed memory is from that viewpoint floating up in the aft port 
quarter of the pilothouse.  I must have done good, because everybody said so, 
from the skipper down to the real authorities, the mess cooks.  I have to 
conclude that I had been so thoroughly trained that I was operating on a 
learned-reflex basis, leaving my conscious mind free to observe.  I don't
know if we can use that somehow in designing "operator assistants" or not.

    - Mike


RISKS UNDIGESTIFIER

John Romine <jromine@nrtc-gremlin>
Mon, 27 Oct 86 10:24:41 -0800
If you have the MH Message Handler (a user agent for UNIX) you have the
"burst" command which seems to work just fine on Risks digests.  MH is
now distributed as user-contributed software on the 4.3BSD tape, and is
available for anonymous ftp from the host louie.udel.edu.  Also, you can
get a magtape copy for $75 from the University of California, Irvine.
I've included the release announcement below.

/JLR

    A new release of the UCI version of the Rand Message Handling (MH)
    system is available for distribution.  This release of MH is called 

                  MH 6.5

    There are a lot of changes between MH.6 and MH 6.5; a lot of
    performance enhancements were made, there's also a lot of support
    for distributed mail (personal mail and bulletin bboards).

    Here are the details:  

    - MH is in the public-domain
    - MH runs on a number of versions of UNIX (4.[123]BSD, V7, SYS5, and
      related variants, e.g., HPUX) [sorry, no support for SYS3.]
    - MH runs on top of a number of mail transport systems
      (MMDF-{I,II}, SendMail, stand-alone (with UUCP support))

    Although MH is not "supported" per se, it does have a bug-reporting
    address, Bug-MH@ICS.UCI.EDU.  Bug reports (and fixes) are welcome, by
    the way.  There are also two ARPA Internet discussion groups:
    MH-Users@ICS.UCI.EDU and MH-Workers@ICS.UCI.EDU (somewhat analogous in
    charter to Info-UNIX and UNIX-Wizards).  

    There are two ways to get a distribution:

    1.  If you can FTP to the ARPA Internet, use anonymous FTP to
    louie.udel.edu [10.0.0.96] and retrieve the file portal/mh-6.tar.
    This is a tar image (approx 4MB).  The file portal/mh-6.tar.C is
    the tar image after being run through the compact program (approx
    2.3MB).  The file portal/mh-6.tar.Z is the tar image after being run
    through the compress program (approx 1.5MB).

    2.  You can send $75 to the address below.  This covers the cost of
    a magtape, handling, and shipping.  In addition, you'll get a
    laser-printed hard-copy of the entire MH documentation set.  Be sure
    to include your USPS address with your check.  Checks should be made
    payable to 

        Regents of the University of California

    and must be drawn on U.S.  funds.  It's also a good idea (though not
    mandatory) to send a computer mail message to "Bug-MH@ICS.UCI.EDU" when
    you send your check via USPS to ensure minimal turn-around time.
    The distribution address is:  

    Support Group 
    Attn: MH distribution
    Department of Information and Computer Science
    University of California, Irvine
    Irvine, CA  92717

    714/856-7553

    Sadly, if you just want the hard-copies of the documentation, you
    still have to pay the $75.00.  The tar image has the documentation
    source (the manual is in roff format, but the rest are in TeX
    format).  

/mtr

Please report problems with the web pages to the maintainer

Top