Computer-Related Incidents and Accidents with Commercial
Latest edition 14 August 1996
since 20 April 1996
The world has changed significantly for air travellers in the 1990s.
New generation aircraft, such as the Airbus A319/320/321/330/340 series
and the Boeing B777 are now in service. These aircraft are `fly-by-wire'--
their primary flight control is achieved through computers. The basic maneuvering
commands which a pilot gives to one of these aircraft through the flight
controls is transformed into a series of inputs to a computer, which calculates
how the physical flight controls shall be displaced to achieve a maneuver,
in the context of the current flight environment. While large commercial
air transport aircraft have had hydraulically-aided controls for along
time, and military air forces have been flying their aircraft under computer
control for equally as long, many people including myself believe that
the use of computer primary flight control in commercial transports heralds
a new era, in which scientists concerned with specification and verification
of computer systems, as well as passengers concerned with personal safety,
should renew their interest.
It would be pleasant to say there have been no accidents. Unfortunately,
as with many new types of aircraft, the Airbus A320/A330/A340 series has
had its share. There have been fatal accidents with A320 aircraft in Bangalore,
India; in Habsheim, in Alsace in France; near Strasbourg, also in Alsace
in France; and in Warsaw, Poland. An A330 crashed on a test flight in Toulouse,
killing Airbus's chief test pilot as well as the other crew on board. An
A340 suffered serious problems with its flight management computer system
en route from Tokyo to Heathrow, and further significant problems on approach
to Heathrow. In late 1995 and early 1996, the B757 (not a fly-by-wire aircraft)
suffered its first two fatal accidents in a decade and a half of service.
Even transport aircraft which are not fly-by-wire have nowadays their
share of safety-critical computer-based systems. New-generation flight
management and guidance systems (the so-called `glass cockpit') and Full-Authority
Digital Engine Controls (FADEC) are found on most newly-built aircraft.
I collect here a series of comments and papers referring to recent computer-related
accidents from various experts and not-so-experts. The collection was originally
restricted to fly-by-wire aircraft, but has since broadened to include
other computer-related or maybe-computer-related incidents. This page will
grow with time. I sincerely hope not by much.
- The RISKS Forum
- The incidents, accidents, and analyses reported here have been discussed
in Peter Neumann's RISKS-Digest,
the Forum on Risks to the Public in Computers and Related Systems,
an on-line news journal which has established a reputation as the premier
electronic source for news and discussion of these topics over the last
ten years. This compendium relies heavily on RISKS comments. Thankyou,
Peter, for a very great service. RISKS material is freely available; authors,
the RISKS moderator and the ACM have no connection with my use of this
- Information and links about all aspects of commercial air transport
may be found in the sci.aeronautics.airliners
page maintained by the moderator Karl Swartz.
- The US FAA, NTSB, ASRS at NASA Ames,
and RTCA Inc
- The Federal Aviation Administration
is the US Government organisation responsible for the administration of
all aspects of aviation in the United States. It is a part of the US Department
of Transportation. The FAA develops, for example, certification standards
for commercial transports on which other organisations such as the JAA
(Joint Aviation Authority) in Europe base their regulations. The entire
Regulations are on-line. It is essential to understand these regulations
in order to understand the environment for flight in the US or with US
The US National Transportation Safety
Board (NTSB) is responsible for analysing mishaps and accidents.
The NASA Ames Research Center in Mountain View, California has run for
many years a program called the Aviation
Safety Reporting System (ASRS). Users of the National Aerospace System
are encouraged to report incidents and events which they feel may affect
the safety of flight, or of which knowledge may contribute to flight safety.
The reports are guaranteed to remain anonymous, and immunity from punitive
administrative action is granted under most circumstances to those who
can demonstate that they have reported the relevant safety-related incident
to the ASRS. The result is an unparalleled accumulation of data on safety-related
incidents. These are summarised in the ASRS monthly newsletter, Callback,
and a journal, Directline. On-line copies of recent issues of Callback
(since issue 187, December 1994) and Directline (since issue 5, March 1994)
are available from the ASRS
RTCA is a private, not-for-profit
organization that addresses requirements and technical concepts for aviation.
Products are recommended standards and guidance documents focusing on the
application of electronics technology. RTCA was organized as the Radio
Technical Commission for Aeronautics in 1935. Since then, it has provided
a forum in which government and industry representatives gather to address
aviation issues and to develop consensus-based recommendations. It was
reorganized and incorporated in 1991. Members include approximately 145
United States government and business entities such as: the Federal Aviation
Administration, Department of Commerce, U.S. Coast Guard, NASA; aviation-related
associations; aviation service and equipment suppliers; and approximately
35 International Associates such as Transport Canada, the Chinese Aeronautical
Radio Electronics Research Institute (CARERI), EUROCONTROL, the UK CAA,
Smiths Industries, Sextant and Racal. The Web site includes a broader statement
of what they do.
Documents such as DO-178B Software Considerations in Airborne Systems
and Equipment Certification, DO-197A (Active TCAS I for `commuter'
aircraft), DO-185 (TCAS I and II, including algorithms in pseudocode),
DO-184 (TCAS I Functional Guidelines), as well as the standards for navigation
equipment, windshear detection and thundestorm avoidance equipment are
all available for purchase via the RTCA Web site. A full
list of applicable standards is also available.
- The UK Aircraft Accidents Investigation Branch
- The equivalent organisation to the US NTSB in Britain is the Aircraft
Accidents Investigation Branch (AAIB) of the UK Department of Transport.
All Formal Investigations
of incidents and accidents since 1994, and the monthly Bulletins
since January 1996 are available on-line.
- Overview of the Issues
- I wrote a short Overview
entitled Summary of Safety-Critical Computers in Transport Aircraft
on 15 June 1994 . This is a good place to start if you're not already
expert in the area. It describes the difference between the A320/330/340-series
aircraft, which have `fly-by-wire' primary flight controls, and
the older Airbus A300 and A310 aircraft, which have autopilots and flight
management systems which include computer control, but whose primary flight
controls are `conventional'. Many people have been confused over the difference.
A similar distinction holds between the Boeing B777 and the B757/767 aircraft.
- Flight Deck Automation
- An excellent survey and statistics on flightdeck automation problems
are to be found in Perceived
Human Factors Problems of Flightdeck Automation by Ken Funk,
Beth Lyall and Vic Riley, in which they studied and classified
the conclusions of the accident reports of thirteen transport aircraft
accidents since 1972 in which automation was reported to be a factor. This
is the report of Phase 1 of a project with the US
FAA Human Factors Office (AAR-100).
- Fly-By-Wire Anomalies in Research Aircraft
- John Rushby
has collected some anecdotes about anomalies which appeared during flight
research in USAF and NASA research aircraft, which appear in Anomalies
in Digital Flight Control Systems (DFCS), a part of his forthcoming
book with Cambridge University Press on the use of formal methods.
- The Benefits of Automation in Aircraft
- We should not forget that the reason that automation is used in aircraft
control and navigation is to make flying safer and easier for all concerned.
While this survey concentrates on the risks, there are examples of clear
safety benefits. Nancy Leveson in her Risks
17.21 contribution Good
News For a Change notes some incidents in which the TCAS, the Traffic
Alert and Collision Avoidance System, helped avoid potential accidents.
TCAS is required by the FAA for commercial flights in the USA. Leveson
was a consultant for the FAA on TCAS. Peter Ladkin in Digital
Flight Control Systems help the U.S. Navy (Risks
17.89) notes an article in Flight International on how the U.S. Navy
is speeding up acquisition of digital flight control systems for the F-14
in an effort to reduce loss-of-control accidents. A very visible example
of the potential benefits of increased automation is the loss
of a US Air Force T-43A (a military version of the B737-200) carrying
US Secretary of Commerce Ron Brown near Dubrovnik in Croatia on April 3,
- The Measurement of Risk
- Even though air travel is reckoned by some measures to be very safe,
many people become nervous when they must travel by air. There are probably
many reasons for this, but one which has attracted the attention of aviation
specialists and others is the psychological effect of perceived risk,
the risk as experienced by the participant, rather than as assessed by
the engineer. There seem to be some regularities to the circumstances in
which perceived risk is higher than engineer's-risks. These regularities
are summarised in
of Risk: Community Measures vs. Scientific Measures by Dave Shaw;
Re: The Measurement
of Risk by Peter Mellor;
Re: The Measurement
of Risk by Martin Minow;
Re: The Measurement
of Risk by Robert Walking-Owl;
- Thinking about Causes
- There is yet no general theory, although there is developed procedure,
of how we ascertain causes in accident investigations. The three
and A320 Warsaw Crashes: Whodunnit? by Peter Ladkin,
Model for a Causal Logic for Requirements Engineering, by Jonathan
Moffett, Jon Hall, Andrew Coombes and John McDermid,
and Causes by Peter Ladkin
discuss the notions of reasons and causes with respect to aviation accidents
as steps towards a general theory. These papers use the A320 Warsaw accident
as an example (the references are repeated below).
- Applications of Formal Methods
- In the computer science community, the term Formal Methods denotes
the use of mathematical methods, in particular those of mathematical logic
and universal algebra, in the specification and verification of computational
systems. (Here, the term verification means a formal mathematical
proof that an implementation of a system fulfils its formal specification.
Such proofs can be very hard and are almost always complicated. Therefore,
formal verification is not without its detractors!) Formal methods in current
industrial practice usually means the use of precise languages with a precise
semantics to specify system behavior. It is undeniable that the use of
formal methods aids precision. What is normally questioned is the actual
cost/benefit ratio of using a particular formal method in a particular
project. There is also common acknowledgement that developing formal methods,
including verification, is a hard research area. Research in Formal Methods
has led to Turing awards (the `Nobel prize' of computer science) for Britons
Tony Hoare and Robin Milner, the Dutchman Edsger Dijkstra, and the Americans
Robert Floyd, Dana Scott and John Hopcroft; and the 1991 Current Prize
of the American Mathematical Society Prize in Automated Theorem Proving
for US computer scientists Robert Boyer and J. Strother Moore.
The Formal Methods
and Dependable Systems Group in the Computer
Science Laboratory at SRI International has been pioneering formal
methods for aerospace for a quarter century. Much of their work concerning
SIFT (the first attempt to develop a provably-correct digital flight control
system) in the 70's, and the subsequent development of the logic specification
and proof systems EHDM and PVS, and their application to problems in digital
flight control and avionics, is accessible with the WWW.
Much of SRI's work on formal methods for aviation systems has been supported
by the NASA Langley
Formal Methods Team, who also have publications in this area.
and her group at the University of Washington are applying formal methods
(using RSML, a language for describing state machines suitable for requirements
specification) to the analysis of TCAS II, the Traffic Alert and Collision
Avoidance System, Version II. These papers may be found under the page
for the Safety
Other recent published academic research on applications of formal methods
to aviation includes
of a Technical Description of the Airbus A320 Braking System by Peter
Ladkin, which uses Leslie Lamport's Temporal
Logic of Actions, in particular the Predicate-Action Diagrams (PADs),
to reengineer part of the documentation of the A320 Braking System in the
Flight Crew Operations Manual;
Logic to Manuals by Harold Thimbleby and Peter Ladkin,
which shows how fragments of a user manual may be generated automatically
from specifications describing PADs using software written by Thimbleby.
The example comes from the A320 Braking System description above, and the
paper itself was generated by running some source text through the software,
Model for a Causal Logic for Requirements Engineering, by Jonathan
Moffett, Jon Hall, Andrew Coombes and John McDermid,
referenced above, which discusses the A320 Warsaw
- The Application
Of Petri Nets To Represent And Reason About Human Factors Problems During
Accident Analyses, by Chris
Johnson which discusses the April 1988 BAC1-11/B737 collision at
Gatwick and the January 1989 Kegworth B737 accident.
Epistemics of Accidents by Chris
Johnson which uses epistemic logic to analyse the reason for the
First Officer's verbal slip in the January 1989 B737 Kegworth accident.
The Incidents and Accidents
- The Ariane 5 Failure
4 June 1996
- Synopsis On 4 June 1996 the maiden flight of the Ariane 5 launcher
ended in a failure, about 40 seconds after initiation of the flight sequence.
At an altitude of about 3700 m, the launcher veered off its flight path,
broke up and exploded. The failure was caused by "complete loss of
guidance and attitude information" 30 seconds after liftoff. To quote
the synopsis of the official report: "This loss of information was
due to specification and design errors in the software of the inertial
reference system. The extensive reviews and tests carried out during the
Ariane 5 development programme did not include adequate analysis and testing
of the inertial reference system or of the complete flight control system,
which could have detected the potential failure." Because of this
conclusion, the accident has generated considerable public and private
discussion amongst experts and lay persons. Code was reused from the Ariane
4 guidance system. The Ariane 4 has different flight characteristics in
the first 30 seconds of flight and exception conditions were generated
on both IGS channels of the Ariane 5. Even though the Ariane is not a transport
category airplane, I include it as an instructive example. It suggests
that we have as much or more reason to worry about the `new, improved,
extended Mark 2 version' as about the original version of FBW software.
Henry Petroski, in Design Paradigms: Case Histories of Error and Judgement
in Engineering (Cambridge University Press, 1994) makes this very point
about the history of bridge-building in the nineteenth and twentieth centuries.
Petroski notes that failures often came not from the first, careful, conservative
implementation of a design, but from its extension. The European Space
Agency has provided a summary
of the Ariane accident report as a Press Release, and also the full text
of the Inquiry
Board Report on the Web.
This is not the first time that computers critical to flight control
of an expensive, complex and carefully-engineered system have failed. See
The 1981 Space Shuttle Incident.
- Reports on the Martinair B767 EFIS-loss
incident near Boston, MA
28 May 1996
- Synopsis A Martinair Holland B767-300 on a scheduled flight
from Amsterdam to Orlando, FL, suffered a partial power failure and lost
all EFIS information, which includes all flight and navigation information.
It continued on the electro-mechanical backup displays and diverted to
Boston, where it landed with only partial flight control. Investigators
are trying to find the cause of the failure. The available information
so far is contained in a short
report culled from reports in Flight International and Aviation Week.
- Information on the Birgen Air B757
Accident near Puerto Plata, Dominican Republic
6 February 1996
- Synopsis This is only the second fatal accident to the B757
since introduction into service. The aircraft crashed into the sea minutes
after takeoff. The CVR and FDR were recovered on February 28, and have
yielded good quality recordings. Investigation is continuing.
On February 7, the FAA issued a Press
Release clarifying the role played by the U.S. FAA (Federal Aviation
Administration) and the NTSB (National Transportation Safety Board) in
the investigation. On March 1, a short statement of Factual
Information from a preliminary review of CVR and FDR data was made
available by the NTSB on behalf of the Dominican Republic civil aviation
authorities. On March 18, a longer Press
Release, accompanied by the CVR
transcript, explained further what the FDR and CVR data indicated.
David Learmount in Flight International, 27 March - 2 April 1996, deduced
from the CVR transcript four salient
observations on the crew behavior and I provide a fifth from the B757
Operations Manual B757
Air Data System description and schematic
diagram. To paraphrase Learmount's points, although confusion about
operation of computer-assisted systems (autopilot, warning annunciations)
played a role, this confusion would not have arisen but for inappropriate
pilot decisions and actions. However, a blocked pitot tube and inappropriate
pilot behavior are not the only potential factors under study. The NTSB
has identified a potential improvement in B757/767 operating manual as
a result of further analysis (short
- A Comment on the American Airlines B757 Accident
20 December 1995
- Synopsis The Boeing B757 aircraft is not `fly-by-wire', but
relies on an FMGS and other computer systems for its normal operation.
The accident report has not yet appeared. I dedicate this section to computer
scientist Paris Kanellakis, who perished with his family in the aircraft.
This CFIT (Controlled Flight Into Terrain) accident is the first
accident for a B757 in a decade and a half of service.
The NTSB issued a Press
Release containing factual data, whose text contains the press release
signed by the Head of the Columbian Oficina de Control y Seguridad Aerea.
The two relevant arrival and approach navigation plates are the Cali
VOR/DME/NDB Rwy 19 Instrument Approach Procedure and the Cali
Rozo One Arrival Procedure.
The specialist weekly Flight International included reports
and comment in its January editions. Computer-relevance appears in
the crew's handling of the FGMS in concert with other procedures. However,
they descended below the cleared altitude, and there appear to be other
procedural inadequacies in their flying (see also Wally Roberts's TERPS
Page for a further comment on this). The FAA is conducting a review
of training at AA.
The short paper TERPS
Page for giving me the links.
- The T-43A Accident near Dubrovnik
3 April 1996
- Synopsis A US Air Force T-43A, a military version of the Boeing
B737-200, crashed into terrain while on approach to Dubrovnik airport,
Croatia, in conditions close to or below the published minimums for the
approach. The US military does not normally publically release the results
of its investigations. This
report is culled from published news in the professional and general
It transpires that the aircraft was equipped with only one ADF (Automated
Direction Finder), a navigation device described as `primitive' by certain
Air Force staff (see report). It seems the aircraft was not as well equipped
as normal civilian standards would require, and it flew off course and
hit a mountain while in the last stages of approach (a CFIT, Controlled
Flight into Terrain, accident). One could speculate that more sophisticated
navigation equipment would have helped avoid the accident. This earlier
`speculation' conforms with the report
of the US Air Force Accident Investigation Board.
- The A320 Accident in Warsaw
14 September 1993
- Synopsis A Lufthansa A320 landed at Warsaw airport in a thunderstorm.
The landing appeared to be normal, smooth, even though somewhat fast. The
pilots were unable to activate any of the braking mechanisms (spoilers,
reverse thrust, wheelbrakes) for 9 seconds after `touchdown', at which
point the spoilers and reverse thrust deployed. The wheelbrakes finally
became effective 13 seconds after touchdown. The aircraft was by this time
way too far along the runway to stop before the runway end. It ran off
the end, and over an earth bank near the end of the runway, before stopping.
Both pilots were very experienced A320 operators. The captain was returning
to duty after illness and the first officer was a senior Airbus captain
and training officer, who was monitoring the captain's flying skills on
his return to service. The first officer died in the accident, as did a
passenger who was overcome by smoke and didn't evacuate the aircraft, which
Report from the Polish authorities is reproduced here without Appendix
Clive Leyman has prepared an Engineering
Analysis of the Landing Sequence which analyses the effects of all
the factors on the stopping distance of DLH2904.
Questions from computer scientists and system experts focused on why
the braking systems didn't deploy as expected by the pilots. The RISKS
Warsaw by Peter Ladkin;
by Peter Ladkin;
Airbus ... by Udo Voges;
Crash--A Clarification by Peter Ladkin;
More and more technical literature is discussing this accident for one
reason or another.
and A320 Warsaw Crashes: Whodunnit? by Peter Ladkin discusses
causes and how to try to ensure more complete coverage of causal relations.
The X-31 accident and the Warsaw A320 accident are analysed as examples.
Model for a Causal Logic for Requirements Engineering, by Jonathan
Moffett, Jon Hall, Andrew Coombes and John McDermid
suggests a logical theory of causality for engineering and applies that
to analyse braking in the Warsaw accident.
and Causes by Peter Ladkin discusses those notions in general,
and comments extensively on the proposal of Moffett et al.
- The A330 Flight-Test Accident in Toulouse
30 June 1994
- Synopsis An Airbus A330 aircraft on flight test in Toulouse
crashed while performing an autopilot test during a maximum-performance
go-around (in which the aircraft aborts an approach to landing and climbs
away quicly into a holding pattern). The aircraft rolled sharply, and was
not recovered by Airbus's chief test pilot in time to avoid hitting the
ground. A very sad day.
Questions arose not only as to what the pilots had been doing, but also
how they were aided or hindered by the design of the systems, including
the cockpit interface and the behavior of the aircraft. The RISKS reports
A330 crash: Press
Release by Peter Mellor;
Re: A330 crash
by Curtis Jackson and Peter Ladkin;
... by Peter Ladkin;
A330 crash investigation
.... by Erik Hollnagel;
.... by Peter Ladkin.
- The Tokyo-London A340 FMGS Problem
30 June 1994
- Synopsis This incident attained Page 1 of the British daily
newspaper The Independent when the report was published. The BBC
also reported on it in the news on 15 March 1995. An Airbus A340 aircraft
on a scheduled flight from Tokyo to London experienced intermittent failure
of navigational and flight-status information on one or another of the
EFIS diplays en route to London. When being sequenced for approach to Heathrow,
the airplane displayed an odd reaction to an autopilot command (it went
the `long way round' to capture a heading) and abrupt and undesired manoeuvering
while attempting to capture the ILS (the localiser and glideslope). They
came in on a radar surveillance approach, the pilots having lost faith
in their on-board equipment to assure them a safe approach and landing.
While the incident brought to light some problems with the ILS broadcast
(the aircraft encountered a `false lobe'), the British CAA considered the
problems with the A340 flight management computers severe enough that they
asked the JAA (Joint Aviation Authority, which has major responsibility
for coordinating the certification of civil transports in Europe) if they
were aware of such problems during certification.
The original AAIB incident report, AAIB
Bulletin No: 3/95.
by Les Hatton;
Re: A340 incident
by Peter Ladkin and John Rushby;
A slight change...
by Ric Forrester via Dave Horsfall refers to the same incident.
- The A320 Maintenance Incident at Gatwick
21 February 1995
- Synopsis An A320 operated by Excalibur Airways took off from
Gatwick, and the pilot found he could not turn left, and needed full left
stick to keep the wings level. The airplane immediately returned for landing
and landed safely. The airplane had come out of maintenance and some right-hand
spoilers had been left in maintenance mode, during which they are free-moving.
Reduced upper-wing pressure in flight caused them partially to deploy.
Peter Mellor analyses the official report of the incident and draws some
edited abbreviation of AAIB Aircraft Accident Report 2/95 published
in Aerospace, April 1995, the monthly of the Royal Aeronautical
Factors in Incident to A320 G-KMAM, Gatwick on 26 August 1993,
by Peter Mellor.
- The A300 Crash in Nagoya
26 April 1994
- Synopsis A China Airlines A300 (a non-`fly-by-wire' Airbus)
crashed on landing at Nagoya in Japan. It turns out that the pilot flying
had decided to discontinue the landing (`go-around') but did not disconnect
the autopilot (the A300 Operations Manual explicitly requires the pilot
to disconnect the autopilot in such circumstances). The pilot tried to
force the nose of the airplane down, and the autopilot, in go-around mode,
reacted to the lack of climb by trimming pitch even further up. When the
pilot eventually stopped pushing and decided not to land (again!), the
nose rose sharply, due to the extreme nose-up trim, and the plane stalled
in an extreme nose-high configuration, and hit the ground tail-first. There
were early rumors of unusually high levels of blood alcohol in the pilots'
bodies (more than is expected as a natural by-product of death), and a
complete power failure before the crash, but neither of these figured in
the final report. The question, why the pilot flying did not disconnect
the autopilot as he is required to, probably cannot be answered. As a result
of this accident and other recent incidents and accidents, the US FAA started
to `work with' China Air on its pilot training programs.
and commentary on the final report is based on an article in Aviation
Week and Space Technology, July 29th, 1996 issue. The final report contained
no surprises, based on what was known shortly after the accident.
Early discussion of this accident in RISKS in 1994 led to much discussion
about Airbus aircraft and accident statistics in general:
A300 Crash by Mark Stalzer;
Re: China Air
... by David Wittenberg;
More on the A300
crash ... by Peter Ladkin;
Re: China Airlines
... by John Yesberg;
Re: China Airlines
... by Mark Terribile;
How to feel safer
in an Airbus by Peter Ladkin;
deductions by Phil Overy;
by Mary Shafer, Robert Dorsett, Phil Overy and Wesley
by Robert Dorsett, Peter Ladkin, Wesley Kaplow, Peter
Mellor and Bob Niland;
Summary of Safety-Critical
Computers in Transport Aircraft by Peter Ladkin;
A320 Hull Losses
by Peter Mellor.
- British Midland B737-400 at Kegworth
8 January 1989
- Synopsis A Boeing 737-400 operated by British Midland Airways
Ltd crashed short of East Midlands Aerodrome on an emergency approach with
engine problems. The airplane crashed across the M1 motorway, coming to
rest partly on the motorway embankment. G-OBME left Heathrow Airport at
1952hrs with 118 Passengers destined for Belfast. Climbing through 28,300
feet, a blade in the left (No. 1) engine 1 detached. This resulted in engine
vibration and smoke, and fluctuations in the engine instruments indicating
to the crew a probable fire in one of the two engines. The crew misidentified
the source, throttled engine 2 back and shut it down. As engine 2 closed
down, engine 1 stabilised, falsely confirming to the crew that they had
acted correctly. The aircraft made an emergency diversion to East Midlands
Airport, near Kegworth, Leicestershire, adjacent to the M1. The aircraft
intercepted the Rwy 27 localizer 6nm from the threshold, for an ILS approach.
During final approach, the engine vibrations resumed, leading to a loss
of power and the crew were unable to maintain glideslope. The final report,
AAIB Accident Report 4/90, of which extracts
by Colin Sandall are included here, investigated the digital presentation
of engine status information in the `glass cockpit' 400-series B737.
- A 1985 B747 Incident
19 February 1985
- Synopsis A China Air B747, flying on autopilot high over the
Pacific, suffered an engine failure, followed by loss of control, and entered
an inverted spin at about 40,000 ft. After experienced +6 to -4G on the
way down, it was recovered at 9,000 ft and flown carefully to SFO in a
mildly damaged state. Pilot judgement was faulty in three main respects
(and excellent in one - recovering quickly from the spin when it was possible!).
The major misjudgement was operating the aircraft at an altitude at which
an engine loss would not enable the airplane to continue flying straight-and-level
above stall speed - immediate nose-down was essential for recovery. The
autopilot was not designed to operate in those conditions, and gave different
control inputs which caused the aircraft to enter the inverted spin. The
pilots took some time to determine what was happening. The brief synopsis
of this early computer-related incident is based on my recollection from
- A Space Shuttle Control Incident
- Synopsis After a delay in a space shuttle mission in 1981, the
crew put in some time in the simulator in Houston. They tested a "Transatlantic
abort" sequence, which dumps fuel and leads to a landing in Spain.
The flight control computers "locked up and went catatonic".
It turns out that an exception condition was generated by a `computed GOTO'
(but remember this is assembly, not FORTRAN). The incident was recounted
by Tony Macina and Jack Clemons to Alfred Spector and David Gifford for
the Case Study: The Space Shuttle Primary Computer System, in Communications
of the ACM 27(9), September 1984, pp874-900. The relevant excerpt is
Should we consider the Shuttle to be a transport category airplane?
(Civilians have travelled on it.) Whatever, the incident is instructive,
as well as interesting history.
- Bernard Ziegler
Interview with Der Spiegel
- Airbus Industrie's Technical Director Bernard Ziegler gave an interview
on the Airbus accidents and their import to the German newsweekly Der
Spiegel. A summary of and comment on this interview may be found in
by Peter Ladkin.
- A320 Third-Party Maintenance
- Finally, one should not miss the excellent spoof A320
software goes on "3rd Party" maintenance by Peter Mellor,
who thought it a reasonable story for April 1. Pete had later to explain
the significance of the date to some horrified RISKS readers who took it
Here's wishing everyone safe flying.
Back to Top