Archived Pages from 20th Century!!



Computer-Related Incidents and Accidents with Commercial Airplanes

compiled by Peter Ladkin

[email protected]

Latest edition 14 August 1996
Changes since 20 April 1996

Contents

Introduction

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.

General Information

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 material.
sci.aeronautics.airliners
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 Federal Aviation 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 commercial carriers.

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 publications page.

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.

Recommended Standards 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 for RISKS-16.16 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 Problems
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, 1996.
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
The Measurement 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 papers
The X-31 and A320 Warsaw Crashes: Whodunnit? by Peter Ladkin,
A Model for a Causal Logic for Requirements Engineering, by Jonathan Moffett, Jon Hall, Andrew Coombes and John McDermid, and
Reasons 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.

Nancy Leveson 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 Research Project.

Other recent published academic research on applications of formal methods to aviation includes

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 note).

A Comment on the American Airlines B757 Accident in Cali
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 press.

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 burned.

The Accident Report from the Polish authorities is reproduced here without Appendix or figures.

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 comments are:
Lufthansa in Warsaw by Peter Ladkin;
More News... by Peter Ladkin;
Re: Lufthansa Airbus ... by Udo Voges;
Lufthansa Warsaw Crash--A Clarification by Peter Ladkin;

More and more technical literature is discussing this accident for one reason or another.
The X-31 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.
A 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.
Reasons 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 are:
A330 crash: Press Release by Peter Mellor;
Re: A330 crash by Curtis Jackson and Peter Ladkin;
A Correction ... by Peter Ladkin;
A330 crash investigation .... by Erik Hollnagel;
Some comments .... 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.

A340 shenanigans 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 conclusions.

An edited abbreviation of AAIB Aircraft Accident Report 2/95 published in Aerospace, April 1995, the monthly of the Royal Aeronautical Society, London.

Computer-Related 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.

A synopsis 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:
China Airlines 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;
Airbus A3(0?)0 deductions by Phil Overy;
Further Discussion by Mary Shafer, Robert Dorsett, Phil Overy and Wesley Kaplow;
Further Discussion 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 memory.
A Space Shuttle Control Incident
1981
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 reprinted here.

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.

Miscellany

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 Summary... 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 seriously.....

Here's wishing everyone safe flying.
Peter Ladkin

Back to Top

Peter Ladkin, 1995-11-12