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 4 Issue 56

Thursday, 5 March 1987

Contents

o Computer problems produce false weather warnings
Mike Linnig
o Some postscript notes about Hurricane Iwa
Bob Cunningham
o Tempest Puget
Bill Roman
o Computer Aided Dispatching
James Roche
o Teflon flywheels and safe software
Hal Guthery
o Autoland and Conflict Alert
Alan M. Marcum
o Re: Air Traffic Control, Auto-Land
Amos Shapir
o Re: An aside on the B-1
Henry Spencer
o Plane Crashes
David Purdue
o In defense of drive-by-wire
Mike McLaughlin
o Info on RISKS (comp.risks)

Computer problems produce false weather warnings

Mike Linnig <LINNIG%ti-eg.csnet@RELAY.CS.NET>
Wed, 4 Mar 87 15:16 CDT
From: Ft. Worth Star Telegram, STARTEXT, Mar-4-1987

Computer problems produce false weather warnings

  WASHINGTON (AP) -- The National Weather Service ordered a halt to all test
warnings on its national weather wire Wednesday, until corrections can be
made in new computer programs that have led to several false warnings in
recent days.  "A cease and desist on all drills has been ordered until we
can correct the system," spokeswoman Carolyn DeBona said in a telephone
interview.
  Two false warnings were issued in the Chicago area and others occurred in
Brownsville, Texas; Long Island, N.Y.; and Washington, D.C., said another
Weather Service spokesman, Donald Witten.  And reports of a similar problem
on Tuesday have been received from Dodge City, Kan., officials said.
  Witten said the troubles started after local Weather Service offices were
sent new computer programming discs designed to speed warnings when severe
weather conditions occurred.  The discs include prepared messages, with
local forecasters only required to fill in the names of endangered cities or
counties and provide any necessary localizing information, he said.
  When the meteorologists tried out the new discs, they were supposed to
include the statement "This is Just a Test," but for some reason that phrase
did not get transmitted in several instances, Witten said.  He said Weather
Service programmers are currently analyzing the discs to see where the
problem is located and to correct it, a process that could take a few days.
  In the most widely publicized instance, a tornado warning was issued early
Monday morning stating, incorrectly, that a twister had destroyed the city
of Rockford, Ill., and was headed for Chicago.  The statement was broadcast
on several radio stations in the Chicago area before a correction was issued.
A severe thunderstorm warning -- also false and also without the "test"
disclaimer -- was transmitted at 1:53 p.m. Monday from the Chicago Weather
Service office and also had to be corrected.
  In the Long Island case, the warning from the New York City weather office
occurred the afternoon of Feb. 20 and involved a tornado warning for Nassau
County, N.Y., and two New Jersey counties, according to local news media.
That tornado statement was followed by a message 16 minutes later that said
the original warning had been in error.
  The Brownsville case occurred at 8:41 a.m. Monday and also involved a tornado
warning, according to Weather Service officials.
  In the Washington instance, on Sunday, a severe weather warning was issued at
2:32 p.m.
  In Dodge City, the false bulletin reported a tornado near Medicine Lodge and
moving northeast. Five minutes later, the Weather Service sent a disclaimer
saying the bulletin had been sent by mistake.
  Jim Johnson, a meteorological technican who was on duty when the false
bulletin moved, said he was testing a new computer program used for severe
storms forecasting when the bulletin was accidentally transmitted.
  The warnings are distributed on the agency's "weather wire," a Teletype
circuit that prints out local conditions, forecasts and warnings. Local Weather
Service offices issue their reports on this wire, which is widely used by the
news media, government agencies and others. 


Some postscript notes about Hurricane Iwa

<CUNNINGHAMR%HAW.SDSCNET@nmfecc.arpa>
Thu, 5 Mar 87 08:43:21 PST
To the best of my knowledge, the outage of one of the working GOES satellites
(summer 1983) was from causes which are still unknown, onboard computer being a
possibility. (Do any other RISKS readers have more information on this?)

The decision to have the remaining GOES cover just the Atlantic was definitely
an "assumption of risk" on the part of the National Weather Service, based on a
decision that it was more important to accurately hurricanes and other weather
affecting the U.S. east coast. 

After Hurricane Iwa, the NWS had the GOES "cheated" west to be able to just see
the Hawaiian islands, and found they could get some coverage of the central and
western Pacific from a Japanese GOES-like satellite and miscellaneous polar
orbiting satellites.  Most of that info was presumably also available back in
1983...but not used by the NWS at the time of Iwa. 

GOES-7 was finally launched successfully last week and---after many delays and
one splash since 1983---the NWS finally has separate GOES capable of monitoring
weather over both the Atlantic and Pacific oceans, with overlap coverage of
North American. 

However, it is still an open question whether better satellite coverage, giving
a more accurate track of Iwa, would really have had much effect. 

The complete story of the effects of Iwa can (and did in subsequent government
investigations) fill volumes.  A useful case study for anyone interested in
natural disasters in general.  Perhaps also an interesting study of the failure
modes of different types of interdependent systems (EBS, telephone system,
water, sewage, city gas, transportation, food supply) when a major system
(electrical) upon which others depends, fails suddenly. 

For example, some of the "pre-programmed" contingency plans that were activated
weren't appropriate. After the initial serious alert went out on the radio
stations just before noon on Thanksgiving the bus system continued in normal
operation until approximately 2:00pm (during the worst traffic jam in
Honolulu's history), the bus company then activated the only emergency plan
they had, for tsunami/earthquake evacuation. All running buses proceeded to
previously-designated schools in the hills with reinforced concrete buildings.
However, since it was Thanksgiving, the schools were closed, leaving confused
bus riders to walk home from wherever they happened to end up. 

After Iwa, the Civil Defense groups (both state and county) were completely
re-organized, and a emergency radio communications network (yet to be tested
under realistic conditions) has been set up to reduce CD's dependency on both
the telephone system. CD has also added a collection of microcomputers to keep
track of things and beefed up their uninterruptible power supply (UPS) systems.

The major electrical utility, Hawaiian Electric built a new centralized, highly
computerized monitoring and control facility (itself protected by a rather
large UPS) for the electrical grid on the island of Oahu. One of the reasons: a
second failure of the electrical grid 9 months or so after Iwa when a fire
which brought down a transmission line, the resulting surge burned out a key
relay, and isolated the major generators.

Hawaiian Electric now claims that type of failure won't happen because their
new computers "react faster than people".

    [By the way, let me take this opportunity for an erratum.  The contents
    list in RISKS-4.51 should have attributed the original message in this
    sequence as follows:

  Hurricane Iwa and the Hawaii blackout of 1984 
    (Bob Cunningham responding to James Burke, via Matthew P Wiener)

    PGN]


Tempest Puget

Bill Roman <sigma!roman@entropy.ms.washington.edu>
Wed, 4 Mar 87 08:05:54 pst
*RUMOR*

I can't vouch for this personally... but a few years ago I spoke to a
contractor who said he had been approached to write software for the
Issaquah class ferries.  According to him, there were single-chip
microcomputers in the wheel house and in the engine room which communicated
by direct connection of their serial I/O pins.  No buffering.  So, apparently, 
when the captain moves the engine controls on the bridge, the engine
computer is all too likely to reply "what's that Captain, I canna hear ye."

My friend refused the contract.


Computer Aided Dispatching (again)

James Roche <roche@rochester.arpa>
Thu, 5 Mar 87 08:14:20 est
The continuing saga of the Rochester/Monroe County 911 dispatching center
continues. The following was printed in the Saturday 2/28/87 Democrat &
Chronicle:

A 911 computer error sent sheriff's deputies to Hilton instead of
Spencerport yesterday afternoon said Sgt. Paul Hayes of the Monroe County
Sherriff's Department.  A caller to 911 said there was an assault taking
place at 111 West Ave., then hung up, Hayes said.  A computer readout
indicated the call had come from Hilton, but when deputies arrived at 5:25
p.m. they could not find number 111.

The 911 center called back the number on the computer readout, which was
correct, and found that the call had come from West Avenue in Spencerport.
A deputy arrived at the scene at 5:28 p.m. Hayes said.

"Apparently the computer's program is somehow at fault", he said.

The incident was over when police arrived. There were no injuries he said.

Jim Roche  University of Rochester  Computer Science Dept  Rochester, NY 14627
ARPA:    roche@rochester.arpa, UUCP:    rochester!roche 


<"guthery%asc%slb-doll.csnet@relay.cs.net">
Wed, 4 Mar 87 07:40 EDT
          <"ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET>
To:       risks@CSL.SRI.COM
Subject:  Teflon flywheels and safe software

When a computer-based misfortune occurs, we are quick to fault the
last-in-line of the system builders.  Usually this is what is euphemistically 
and disparagingly called the applications programmer.  Only on rare
occassions do we ask if this unfortunate soul could have done any better
given the tools that were available.  Consider ...

Modern computer architectures (the Transputer, for example) sacrifice time
determinism in favor of speed.  Modern computer languages (Ada and Occam,
for example) sacrifice time determinism in the interest of features (Ada) or
provability (Occam).  And yet, the metaphorical mist that surround these
developments (concurrent, multi-tasking, real-time, etc.) invites people to
incorporate them in time deterministic systems like cars and planes.  As if
the applications programmer didn't have enough to worry about, he now has to
build a deterministic system using a non-deterministic language on top of a
non-deterministic machine.

What I'm getting at is that while we all talk about risk reduction, not only
do we not specify and build system components (machines, languages,
theories, test harnesses, diagnostic tools) that let us get ahold of and
engineer risk factors, we encourage, yea verily demand, components that are
ever more slippery.  Then we give these teflon flywheels and greased gears
to the application programmer and expect him to build a nice safe system.

How come my vendor won't tell me the instruction execution times of his
machine? Where are the time specifications for an Ada kernel?  Why are there
no real-time languages?  How come we don't insist on time delay guarantees for 
operating system calls?  Why can't I turn off ALL interrupts?  Why are time
services so impotent?  What exactly is the caching algorithm and how can I
change it?  Why can't I install my own scheduler?  All these and many more.

If we want to really want to build reduced risk systems, then we should start
to define and build reduced-risk parts. I don't believe you can expect the 
painter to be responsible for the structural integrity of the bridge.

   [This a very nice challenge, and one that should be taken seriously.  PGN]


<hplabs!cae780!amdcad!sun!nescorna!marcum@ucbvax.Berkeley.EDU>
Mon, 2 Mar 87 16:11:18 PST
      (Alan M. Marcum)
To: amdcad!CSL.SRI.COM!RISKS
Subject: Autoland and Conflict Alert

First on autoland, there are various commercial planes flying that have an
autoland capability, including the L1011, 767, 757 (this is not an
exhaustive list).  This isn't meant to imply that I approve or disapprove,
simply that the system exists on a fair number of planes.  In fact, the
system was invented in England (CAT IIIC ILS approaches, in the jargon:
ceiling 0', visibility 0 -- the stereotypical English day?), to help with
some of the weather difficulties there.

Regarding Conflict Alert and Mode C transponders, this has been a topic of
hot discussion of late.  One recent comment on RISKS was to the effect
that anyone owning a plane could afford the US$1500 or so to add Mode C.
Many, many planes in the general aviation fleet have no on-board
electrical system whatsoever, much less any transponder.  A large number
of pilots would find an additional $1500 a significant burden.  Folks
squawked about FAA's ELT (Emergency Locator Transmitter) requirement
several years ago, and that was for much less than $1500!

It's unclear how much it would help right now, anyway, to require Mode C
altitude reporting transponders on all planes (here's the competer tie-in,
least you've been concerned).  The current US ATC system (I'm unsure about
that in other countries) would be grossly overloaded if all the planes in
the sky now even had Mode A (position-reporting, without altitude), much
less Mode C.  This is a capacity limit of the computers and the signal
processing equipment.  Yes, they could be upgraded, and are being upgraded
-- at tremendous expense (needed, perhaps), and it will take a long time.
-- 

Alan M. Marcum              Sun Microsystems, Technical Consulting
marcum@nescorna.Sun.COM         Mountain View, California


Re: Air Traffic Control, Auto-Land (RISKS-4.51)

Amos Shapir <decwrl!nsc!nsta!instable.ether!amos@ucbvax.Berkeley.EDU>
Thu, 5 Mar 87 11:34:41 -0200
>I would be equally unhappy being a passenger in an autolanding plane as
>I would be living in a chronic state of "launch-on-warning" nuclear policy...

Yes, automatic anything will have bugs and accidents will happen; however
since we cannot eliminate them altogether, the question should not be whether
automatic systems will cause accidents, but whether the accidents' cost
would be greater os smaller than the cost of accidents in the human systems
they replace. The type of accidents may be different, and some automatic
systems introduce hazards were none were in a parallel human system; but they
also solve many more problems than they introduce.
                                                         Amos Shapir
National Semiconductor (Israel), 6 Maskit st. P.O.B. 3007, Herzlia 46104 Israel
(011-972) 52-522261  amos%nsta@nsc.com 34.48'E 32.10'N


Re: An aside on the B-1

<pyramid!utzoo!henry@hplabs.HP.COM>
Tue, 3 Mar 87 17:07:20 pst
>...You can make aircraft from a few large pieces, or from many small pieces...

Ed Heinemann, famous for designing aircraft that were lighter and cheaper
than anyone else thought possible, was a real fan of big pieces, because a
structure of a given size needs *more* small pieces.  He once said something
along the lines of "when you count the parts in the F-14 wing, it's obvious
why the F-14 is so expensive".  I'd speculate that there is a correlation
with reliability as well, again because of simplicity.  Here we have an
analogy to software in the opposite direction from the one Eugene was
making:  Unix builds things out of little pieces, but it is a big-piece
system in one way because it emphasizes a few unifying principles rather
than a myriad of special cases.
                     Henry Spencer @ U of Toronto Zoology
                     {allegra,ihnp4,decvax,pyramid}!utzoo!henry


Plane Crashes

David Purdue <munnari!csadfa.oz!davidp@seismo.CSS.GOV>
Thu, 26 Feb 87 16:20:45 est
I was told an interesting story last night, and I wonder if anything
has been written about it in mod.risks, or if anyone knows
anything about it (or even if it is true!).

In Europe there was a spate of (F-111?) crashes.  The apparent cause of
these crashes was pilots (1) believing they could fly the plane on their
own without the help of any dumb computer, (2) turning the computer off,
and (3) promptly flying into a mountain.

Any Hints?                  DavidP

Mr. David Purdue       Phone ISD: +61 62 68 8165
Dept. Computer Science         Telex: ADFADM AA62030
University College  ACSNET/CSNET: davidp@csadfa.oz
Aust. Defence Force Academy UUCP: ...!seismo!munnari!csadfa.oz!davidp 
Canberra. ACT. 2600.        ARPA: davidp%csadfa.oz@SEISMO.CSS.GOV
AUSTRALIA              JANET: davidp@oz.csadfa


In defense of drive-by-wire

Mike McLaughlin <mikemcl@nrl-csr>
Thu, 5 Mar 87 09:15:43 est
Numerous contributors have attacked automotive drive-by-wire systems.  
Consider some possible benefits, if implemented correctly: 

- No more drivers speared by the steering column 
- Speed-proportional steering 
- Feedback selectable to match the individual driver's needs 
- Easy to implement special controls for the handicapped 
- Three degrees of freedom for "steering wheel" adjustment and for driver entry

Basically, "drive-by-wire" will allow unlimited freedom to human-engineer
the driver's input to the steering system of the automobile.  I suggest
that we concern ourselves with ensuring that the system is safe and reliable,
instead of reminiscing about the good old days of mechanical steering. 

    - Mike McLaughlin

Please report problems with the web pages to the maintainer

Top