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…
Five New York futures markets went off the air Friday when the communications
line that delivers price quotes to brokers and others around the country
failed. The cause of the failure is unclear as of this writing; exchange
officials blamed AT&T lines, but AT&T said that their lines were working and
that the problem appeared to be at the futures exchange.
And the traders — most of them headed for home, a decision perhaps eased by
the fact that the weather here is gorgeous and it's Friday...
--Steve Bellovin
Another article about the A320 Habsheim crash appeared in the 11-17 April 1990
issue of Flight International. This includes transcripts of the voice and data
recorders of the flight.
Time: seconds part of time; times are from 12:44:27 to 12:45:41.5.
N1: engine low-pressure compression ratio (%)
(a good guide to engine power).
CAS: calibrated air speed, in knots.
V:
A = radio altimeter (heights are in feet)
C = captain
G = ground proximity warning system (GPWS)
N = noises
P = copilot
T = tower
N1 and CAS values are interpolated from a graph in the article. This only
covers the time from 12:45:00 to 12:45:39.
Time N1 CAS V
27 T QNH Habsheim 1012 Fox Echo 984.
C OK.
[QNH is the altimeter pressure setting required to make the
altimeter read 0 at sea level ("altitude"), and QFE is the
setting to make it read 0 at airport ground level ("height").]
31 P Roger. [On radio]
32 C 984 put in 984.
34 P 984 QFE selected.
37 P Good gear is down; flaps 2.
42 C Flaps 3.
45 P Flaps 3.
C That's the airfield; you confirm ?
48 P Affirmative.
51 P You see it LL01, when we get there you're at 1 nautical mile,
that's right.
55 N <Gong> [nosewheel valve, according to crew]
P OK.
G Too low terrain.
00 35 160
04.7 N <Gong> [GPWS cutoff, according to crew]
05 35 150
05.7 A Two hundred.
10 35 150
11 P P....G....
[P....G.... is the airline's flight safety officer]
11.4 A Two hundred.
12 P G.... is going to ... eh.
14 P OK, you're at 100 feet there, watch, watch.
15 35 145
15.3 A One hundred.
19.1 A Forty.
20 35 135
23.6 A Fifty.
25 35 130
26 C OK, I'm OK there, disconnect autothrottle.
[This had already been done].
27.5 A Forty.
30 35 120
32 P Watch out for the pylons ahead, eh, see them ?
33 C Yeah, yeah, don't worry.
34 35 [Throttle position started moving from 0 degrees]
34.5 35 N <Clack, clack, clack> [power lever detents]
35 35 115
35.3 A Thirty.
36 38 [Throttle position reached 45 degrees, where it then remained]
36.2 A Thirty.
37 45 P TOGA/SRS. [Take-off go-around / speed reference system]
38 60
38.3 A Thirty.
39 75 100 P Go around track.
N <Increase in engine speed>
N <Noises of impact in trees>
39.9 C Sh..!
41.5 END OF TAPE
Some other notes from the article:
Air France's approved overfly height is 100 feet, and only if the runway is
suitable for landing. Habsheim's runways are too short to land an A320.
The original plan was to overfly the hard runway, 02. The captain was clearly
having trouble finding the runway; when he finally saw the line of spectators
on the ground, he decided to overfly the grass runway 34R, without telling the
copilot.
The captain was used to major airports, with 2000-3000m runways and 30m high
control towers. Habsheim has a 800m grass strip and a 12m high tower. He may
have been misled by a scale effect; the steep attitude of the plane would have
enhanced this, and could also have made him think he was higher than the trees
(which first struck the rear fuselage).
It was suggested on RISKS that there may have been a software delay in the
engine controls which was not shown by the data recorder. From the voice tape,
it is clear that this is not the case. A CFM56-5 engine takes about 8 seconds
to spool up to full power, and the tapes are also consistent with this. N1
started to increase within half a second of TOGA (take-off go-around) power
being selected, and had reached 85% when the engines began to ingest branches.
Analysis of the soundtrack of a video shot from the control tower agrees with
this, and shows N1 reaching 91% with "massive ingestion of branches and
leaves".
Somewhere around 12:45:39 the captain's sidestick was pulled to full climb
position. At this point the CAS was 110 knots, beginning to respond to engine
thrust, and the height is 30 feet, steady and beginning to increase. Throttles
and sticks are hard against the stops.
The first data recorder transcription suffered a misreading in the region
12:45:24 to 12:45:32, of which 4 seconds was rejected by the data checking
software in the analyser. An example of errors produced was sign inversion of
the aileron positions. The official report states that this "was no doubt due
to an interruption of contact between the reading head and the recorded tape,
caused by a fold in the tape and/or dust. The following recordings, made after
cleaning and smoothing out of the tape, permitted correct reproduction of all
data". This problem has been used as grounds for alleging that the data was
tampered with, but it should be noted that (a) the affected area does not
cover any significant events, and (b) the final transcription is internally
consistent, and is consistent with videos taken by various people and air
traffic control tapes. The voice recorder analysis was made with the crew's
help.
Habsheim weather at 12:50:
wind 330/6 knots;
visibility 8km;
cloud 1/8 Cu at 780m, 7/8 Sc at 1500m.
The weather was unchanged since 12:20, except that the wind direction had
backed from 010.
Clive D.W. Feather, IXI Limited, 62-74 Burleigh Street, Cambridge U.K. CB1 1OJ
>From FLIGHT INTERNATIONAL, April 11, 1990: ``British Airways (BA) Boeing 747-400's have experienced uncommanded inflight closure of all four throttles on six separate flights between 6 October, 1989, and 19 February, "several times" on one of these flights alone, according to formal reports. Several other airlines have suffered the same incident, Northwest reporting it first. ``Boeing believes that it has determined the cause, and appropriate auto-throttle software modifications were made available to operators on 22 February. Initial modifications to all new aircraft were reviewed in early September. Studies continue, however, in association with airlines and the UK Civil Aviation Authority. ``Boeing and BA deny reports of serious unreliability, associated mainly with the 747-400's digital cockpit avionics and computerised systems management. Boeing reports world fleet technical dispatch average in 1990 as 94.5%, and gives a February 1991 target of 98%. BA says that its fleet of seven achieved 100% technical dispatch reliability in the last week of March, and 96.5% for the last three months, quoting this as reasonable for a new type. In most of the events the power levers retarded rapidly to idle, but sometimes the reduction was partial, followed by automatic reset. Pilots reacted by dis- engaging the autothrottle and resetting power manually. ``Boeing began a study of the problem as soon as reports confirmed that a throttle closure on a Northwest 747-400 was not a freak event. The manufac- turer subsequently issued two service bulletins to -400 operators. ``All incidents have occurred in the climb or cruise, and an indicated airspeed (IAS) of more than 280 kt is believed to be fundamental to the event. If continuing experience confirms this, it means that stalling--even clean--is not a risk. Evidence indicates that the event is caused by a spurious signal to the full-authority digital engine control from the stall-management module. The "single word" spurious command says that the undercarriage is down or the flaps are at setting 1, so if the IAS exceeds the maximum speed for these configurations, the autothrottles close to reduce IAS to limiting speed, then reset to maintain it. ``The modification assumes that the fault was in the processing logic of the appropriate unviersal logic card (a printed-circuit software unit), and adopts a standard technique for reducing digital oversensitivity: there is now a delay (a few microseconds) built into the software by requiring it to receive an "eight-word" command before acting. Power spikes or other spurious commands should not produce a reaction. ``So far the latest modification has proved effective. Early corrections, though, had assumed the reaction was associated only with main-gear selection, so although software changes had reduced the incident rate, spurious flap signals continued to set engines to idle. BA has not reported any further events since February.'' Robert Dorsett, Moderator, Aeronautics Mailing List
It's not a passenger-carrying plane, but Boeing's new Condor unmanned (note sexist language) aerial vehicle (UAV) should be of interest to readers of this newsgroup. The Condor is a 10-ton, 200-ft wingspan (greater than that of a 747), high-altitude (66,908 ft), long-duration (2.5 days), twin-engine, piston-powered, autonomous (NOT remotely-piloted) plane. Boeing hopes to find buyers in the military and scientific communities interested in the plane as a sensor platform, at $20 million a pop, not including payload. DARPA has funded some of the development. The plane is "piloted" by two Delco Magic 3 flight control computers, using inertial guidance for navigation, a microwave landing system (MLS) for takeoff and landing, and about 60,000 lines of code, mostly Fortran, with some assembly code. "All of Condor's mission functions from takeoff to landing are stored in its computers at the start of a mission.... Communication links are provided so that the mission program can be altered in flight if necessary for safety or any other reason." It operates autonomously within the air traffic control system (a contradiction in terms, as I see it), which has caused some concern on the part of the FAA. At its cruising altitude, it operates well above commercial traffic, but it takes 4 to 6 hours to get up there or back down. During flight tests, a chase plane was present whenever the Condor was within an airport traffic pattern. The article I read (Aviation Week & Space Technology, 132/6, April 23, 1990, pp. 36 - 38) had no word on what the chase plane's pilot's instruction were in the event of a computer malfunction, or what would happen if something failed when the chase plane wasn't around. Jan Wolitzky, AT&T Bell Labs, Murray Hill, NJ; 201 582-2998 (Affiliation given for identification purposes only)
Now that has some interesting possibilites — If the Social Security Administration still uses Univac/Sperry/Unisys computers, I ought to change my name to @FIN (the end-of-job control card). That would sure drop a large monkey wrench into the works, as there is no way to read a card that starts with those four characters. Well, maybe if you switch the card reader translation mode to EBCDIC or column binary... (Assuming they still use cards, of course, which wouldn't surprise me at all.) There are, of course, other variations if they've switched computers. Mike Van Pelt, Headland Technology,
Several years ago, we split our report-card-printing job into two jobs. Due to the way it was split, one program was 'cloned', rather than modified to determine which set of report cards was to be printed. The fact the both programs had to be kept 'in sync' wasn't clear in the documentation. I suspect that the interface between some of the other procedures involved were also under-documented. Some time after the job was split into two, the university got flooded with calls complaining that some of the GPAs were truncated - 3.95 and 3.13 were both printed as 3.00. The correct GPA could be determined by dividing the quality points by the hours attempted, which were both printed correctly on the report cards. Apparently, some program maintenance affected the two clone programs. One printed GPAs correctly, the other didn't. During analysis, it was determined that the database files were correct, the permanent record reports were correct, and it was only half of the report cards that were printed incorrectly. It was necessary to reprint and remail all of the report cards. Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555
I have been throughly enjoying reading
Darrel Ince
Software Development: Fashioning the Baroque
Oxford University Press, 1988
ISBN 0-19-853757-3
ISBN 0-19-853758-1 (Pbk.)
which includes a chapter entitled "The return of the hacker". The
particular risks discussed in this chapter and of immediate interest
are in the use of spreadsheets by the computer less-than-adequately-literate.
When I mentioned computerized spreadsheets to some of my colleagues,
they replyed with some stories involving incorrect spreadsheet packages and
also more stories of the hacking which occurs in the spreadsheet community.
While the misuse of spreadsheets may be less dramatic than problems
with airplanes and autos, I suspect this spreadsheet hacking may be so
pervasive as to have a noticable and negative impact upon the economies of the
computerized world. (Of course, the widespread and judicious use of
spreadsheet packages certainly has a noticable and positive effect as well.
But on RISKS we concentrate upon the negative impacts.)
I would appreciate the readership of RISKS contributing a wide variety
of stories about spreadsheets. These might include stories about the incorrect
implimentations of constraint programming which appears to occur in
all-too-many of the spreadsheet packages. These stories would also ideally be
about the real-world impacts of trusting the conclusions obtained by the
spreadsheet packages. (If you haven't any stories of your own, please just ask
the tradespeople in the community in which you reside.)
This from News Notes on America-On-Line, April 28, 1990: Seminar Speaker Says India Should Pass Anti-Virus Legislation Those attending a seminar last week in New Delhi urged the Indian government to consider a law to deter people from indiscriminately experimenting with viruses. A report in the Xinhua Chinese news service quoted an Indian scholar identified only as "Mahabala, chairman of the department of electronics committee on computer virus" as saying an alarming trend in the country is that some academics are teaching software engineering by creating viruses for their students to detect. Said Xinhua, "This concept of glorifying viruses designers (is) wholly destructive," adding Mahabala cited a wide variety of viruses affecting computers in India, mainly variations of viruses such as "C-Brain." Mahabala said that, instead of creating viruses as means of copy protection, software designers should come out with access passwords that are difficult to break. --Cliff Stoll cliff@cfa.harvard.edu
Although this looks like a computer/operator glitch up front, it could also be
an example of using the old? cliche "computer error" to cover up some shady
fund raising. There was a case a number of years ago when Philadelphia sent
out thousands of parking tickets also to people who had not even been in the
city. The idea being if even 1% send in the money rather than fight the
ticket, they show a handsome profit. My father received one and took it to the
local AAA office. They were taking them to Harrisburg by the hundreds just
from the NE PA area. Of course, they didn't have computers to blame so
uncovering the scam was pretty easy.
It seems that computers may be capable of providing a good audit trail when
desired but they are also capable of covering their tracks if that is the
desired result.
bill gunshannon
Please report problems with the web pages to the maintainer