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: 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.
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]
*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.
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
<"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]
(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
>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
>...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
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
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