| Index Home About Search for Google's copy of this article Index Home About Newsgroups: comp.risks X-issue: 7.67 Date: Tue, 25 Oct 88 00:55:22 EDT From: attcan!utzoo!henry@uunet.UU.NET Subject: Airbus A320 in service The 3 Sept issue of Flight International has a feature article about early operational experience with the A320. Apparently everyone has been rather surprised that many of its teething problems have little to do with the electronics. Spare parts, in particular, have been somewhat of a problem. One thing the airlines are quite happy with is the Centralized Fault Display System, which keeps a running log of all in-flight problems for scrutiny by the maintenance crews. Both British Airways and Air France plan to link the CFDS to a communications system, so that faults can be reported from the air and spare parts can be waiting when the aircraft lands. At present, the written engineering log is still the official and legal record of in-flight problems, but after some more experience with CFDS this may be reconsidered. There are still occasional bugs in the CFDS software, but things are getting fixed. The airlines say that CFDS has been a major factor in keeping a new airliner running unusually well. The fly-by-wire flight controls have behaved perfectly. The engine-control computers likewise have a flawless record, although at one point Air France replaced a number of them due to what seems to have been a misunderstanding about the location of some problems. Power spikes caused by the cutover from ground to onboard power have been a headache, as they tend to trigger bad-power-supply detectors in the computers. These problems invariably happen on the ground, not in flight. Work is underway on fixing them. Many of the computers affected are in very minor control roles; a particular trouble spot has been the microcomputer-controlled vacuum toilets chosen by Air France. The biggest problem for both airlines is a set of design and manufacturing flaws in the air-conditioning units, combined with shortage of spares. Computers are not involved in this one. Both airlines have a low opinion of the software in the Cabin Intercommu- nication Data System, which controls cabin lights, signs, speakers, and entertainment. Both agree that the idea of the system is good and want to see it operational, but the suppliers simply did not have production- quality software ready in time. "A kid could have written the software for the CIDS", says BA, but in fact the current [3 Sept] software simply does not work and BA has been bypassing it almost entirely. The main problem is frequent intermittent manlfunctions. Spare flight computers are still being carried on each flight, but this is routine for major no-go items on new airliners. Airbus says that there is now enough experience to justify dispatching an A320 with one of its seven flight-control computers dead; the original rule required all to be functioning. Airbus is still working on "tidying up" the flight-control software's responses to situations where the aircraft has gone outside the normal flight envelope involuntarily, e.g. from collision damage or sudden severe turbulence. Assorted "nice to have" features are also being implemented now that the schedule pressure has relaxed. The only change in Air France operating procedures since the airshow crash has been a firm policy that airshow appearances will not carry passengers henceforth. The wreckage is being studied for lessons to be learned; the Flight article observes that a crash into a mature forest killed only three out of 136 people. Of note are signs that the floor-level emergency lighting system may not have turned on properly, and the failure of the hand-held megaphone's mounting bracket at rather less than its rated 9G. The 24 Sept issue reports that the pilot of the airshow crash has been fired, with the copilot's status yet to be decided. A recent report by the French civil aviation authorities contains the first independent confirmation that the accident was caused by pilot error. (The pilots' union, of course, contests this.) The report recommends an eight-year suspension of the pilot's licence, and a two-month licence suspension for the copilot. "Officials familiar with the flight recorder evidence say that despite the pilots' assertion that the aircraft was slow in responding to the controls, the flight control computers probably prevented a worse disaster by keeping the aeroplane unstalled when the pilots realized too late that they were about to crash." Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu Search for Google's copy of this article Newsgroups: comp.risks X-issue: 7.71 Date: Sun, 6 Nov 88 02:08:09 EST From: attcan!utzoo!henry@uunet.UU.NET Subject: Re: A320 update >Henry Spencer's recent article on the A320's first six months in >service states that the fly-by-wire system has "behaved perfectly." >It should be noted, however, that the article he was referring >to clearly pointed out that there were failures of the primary >flight guidance computer, which were rectified by backup systems. Hardware failures, dealt with by backup systems, happen even in non- computerized aircraft. With substantial frequency, in fact. This did not seem worth mentioning. As nearly as I can tell from that article, and the later ones, there have been no major *software* problems in the flight-control software... which is what everyone was worried about. Hardware failures are to be expected. >I find Ziegler's rationale for the failures of the A320 somewhat >disturbing. With only a handful of airplanes in service, for any >significant percentage of in-flight or on-ground failures to occur, >and then say it should be compared to the massive fleets of existing >aircraft, is to obfuscate the issue. How so? Note that he is citing *percentages of flights* delayed, not absolute counts; fleet size is irrelevant except insofar as statistics over a small fleet are less precise than over a large fleet. His comments about media attention are more dubious in this regard, since occasional failures in a small fleet are indeed more significant than the same failures-per-day rate would be in a large fleet, but even there I think he's got a point: if ten 747s fail per day, nobody cares, but if an A320 fails once every two weeks, it's a scandal. >His confidence in the A320's backup electrical systems is also rather >odd, considering the airplane's susceptibility to transient controls, >and his company's failure to provide even a mediocre cabin lighting >control system. Notice that the transient problems are (as far as I've heard) all in non-critical support systems, and the cabin-lighting-control problem is with a subcontractor, presumably not the same people who did the main electrical system. Agreed that Airbus is responsible in the end, but the implication that these problems spill over into more critical systems seems unjustified. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry Search for Google's copy of this article Newsgroups: comp.risks X-issue: 9.75 Date: Thu, 15 Mar 90 14:52:31 EST From: henry@zoo.toronto.edu Subject: Re: Airbus Crash: Reports from the Indian Press > A technical committee armed with comprehensive terms of reference > began a probe into the whole Airbus affair last week. ... Interestingly enough, it looks like somebody in authority at least suspected that the results would be embarrassing to the airline (i.e. mismaintenance or pilot error rather than technical problems). Normally, in such an accident investigation, the airworthiness authorities of the aircraft's country of origin i.e., the people who first certified the thing as flyable are involved, and the manufacturer is at least kept informed. Aviation Week reports that India refused European airworthiness authorities' request to participate, and also refused information requests from them and from Airbus Industrie. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu Search for Google's copy of this article Newsgroups: comp.risks X-issue: 9.79 Date: Mon, 2 Apr 90 00:06:35 EDT From: henry@zoo.toronto.edu Subject: Indian A320 crash One of the bigger problems in assessing the A320 is that almost everyone has vested interests to protect. Most European aircraft manufacturers are involved in building it, so they (and their governments) want it to be a commercial success. Their US competitors (and their government) would prefer it to be a commercial failure. Pilots' unions often oppose it because it is a 2-man-crew aircraft replacing 3-man-crew planes. And so on. The relevance of this to the Indian crash is that India, lacking its own facilities for reading modern crash recorders, sent the A320's recorder to Canada for analysis. They chose Canada specifically because it has no vested interest in the A320! Incidentally, the latest word in Flight International (21 March issue) is that informal reports admittedly thirdhand claim the approach was being flown at an excessively low speed, 106 knots as against a recommended speed of about 130 at that point, just before the crash. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu Search for Google's copy of this article Newsgroups: comp.risks X-issue: 9.82 Date: Thu, 19 Apr 90 00:23:29 EDT From: henry@zoo.toronto.edu Subject: A320 news The latest A320, um, news, from Flight International 14 March... As most readers know, the official conclusion of the inquiry into the first A320 crash (the airshow at Habsheim in 1988) was pilot error: they were flying too low and too slowly with engines at very low power, and increased power too late to avert the crash. This was corroborated, in detail, by the flight data recorder and cockpit voice recorder. The pilots have recently been charging that the FDR and CVR recordings were tampered with by the investigators. The last straw, apparently, came when the pilots' lawyer asked India's prime minister to keep the French investigators away from data on the Bangalore crash on grounds that they might tamper with it too... The French Minister of Transport, his Director of Civil Aviation, and the head of the accident-investigation office are suing the pilots for libel. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry Search for Google's copy of this article Newsgroups: comp.risks X-issue: 10.04 Date: Sun, 3 Jun 90 23:58:50 EDT From: henry@zoo.toronto.edu Subject: Glass cockpits (A320, etc.) The April 30 issue of Aviation Week has a couple of interesting small items about computerized airliners and "glass cockpits". The first is a news item: Airbus Industrie is considering alterations to the A320's flight software to help guard against "overconfidence syndrome", which they consider a significant factor in the Habsheim and Bangalore crashes. One possible change is upgrading the automatic throttle management of the "alpha floor" protection mode to guard against descents with inadequate thrust. "Alpha floor" already runs the throttles up automatically in emergencies like encounters with serious windshear or maneuvers to avoid collisions. Says Bernard Ziegler (Airbus VP Engineering): "The alpha floor was never designed to save a crew that had been improperly managing a normal approach, but we now are thinking of modifying it to serve as one more safeguard. Such a modification will not make it a 100% safeguard, but it could offer an additional safety margin." The second is a background piece on the poor state of research in glass-cockpit human factors (for example, NASA Ames, a major center of work on such things, has no simulator representative of modern cockpits). Hart A. Langer (United Airlines VP flight operations) says that flight-management-system CRTs act as "cockpit vacuum cleaners they suck eyeballs and fingertips right into them. I have given check rides on these aircraft and seen four eyeballs and ten fingertips caught in two [displays] at the same time. This is bad enough at cruise altitude, but it can be lethal in the low-altitude terminal area..." Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry Search for Google's copy of this article Newsgroups: comp.risks X-issue: 10.49 Date: Wed, 10 Oct 90 12:39:31 EDT From: henry@zoo.toronto.edu Subject: Re: Equinox on A320 (UK Channel 4, Sun., 30th Sep) >- The DFDR recording stops 4 seconds *prior* to impact with the trees. (Davis > added that, in his entire career, he had *never* come across a similar > instantaneous stoppage of a recorder.) Is it possible that Davis is not familiar with *digital* flight recorders? I've seen some commentary on such an issue in the aviation press recently: the underlying problem is that some (all?) digital flight recorders buffer incoming data in semiconductor memory, which loses its contents on power failure. The airworthiness authorities are starting to be seriously displeased with the potential for loss of crucial data, and there are mutterings about requiring non-volatile memory. I don't know for sure that this accounts for the above claim, but it certainly sounds like the right sort of symptoms. (Would a simple explanation like this go unconsidered? Quite possibly, especially in the context of a media story whose basic slant is "dirty work at the crossroads". As I've commented before, there is a problem with the A320 business in that almost all participants have axes to grind and it is very difficult to get a balanced view. The media are not exempt from this, since sensation sells and boring truth doesn't.) Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry Search for Google's copy of this article Date: Fri, 16 Aug 91 13:01:03 CDT From: rdd@cactus.org (Robert Dorsett) Subject: A320 revisited [This is a re-worked sci.aeronautics reply to a comp.sys.mac.programmer post. It's somewhat relevant in its RISKS-of-RISKS aspects...] And Mr. Finnegan wrote: >The Airbus suffers from what many software safety experts consider a major >design problem - it uses redundant flight computers and a polling computer >to pick the 'majority' answer to each input (I forget the technical term >for this theory it's been way too long since I've been immersed in stuff >like this in school/industry). This system is used because some CS people >think polling can replace stringent software testing - if 5 s/w teams all >write code to the same spec and test just a little, the polling computer (if >it is calibrated properly - another issue) statistically should be able to >deduce the proper answer and weed out any incorrect input. Needless to say >many experts aren't convinced. The A320 flight control system is comprised of five computers: two elevator and aileron computers (ELAC) and three spoiler and elevator computers (SEC). The computers use diverse software and hardware implementations: the ELACS are based on the 68000 and Pascal, the SEC's on the 80186 and C. At any one time, there is *one* and only one "hot" computer, and one standby computer. Each computer is actually a combination of two "channels," one microprocessor driving each channel. One such channel is a "command" channel; the other is a "monitor" channel. Each is responsible for guaranteeing the output of the other. The command channel was written in a high-level language; the monitor channel was written in assembler. The ELACS are the higher-level computers, providing all the functionality as- sociated with the complete FBW pilot interface (there are four distinct direct- control flight modes the A320 can be in). ELAC1 is the primary computer. Graceful degradation is accomplished, going from ELAC1 to ELAC2 to SEC1 and so forth. The SEC computers provide a "direct" control law, in which sidestick deflection more or less correlates to control surface movement. SEC3 only controls roll. The pilots can also command switching from one computer to another. Various means (checksums, range tests, time-outs, etc) are used to determine computer robustness. If the checks fail, the computer takes itself off-line. SEC and ELAC development teams were isolated, and prevented from communicating with one another. This was intended to prevent teams from "contaminating" each others' code with common approaches. Any problems theoretically will only arise from the *specification,* although it's entirely probable that each team opted for similar approaches to solving problems. The software and hardware verification regime was performed in accordance to EUROCAE/ED-12A. This is virtually identical to RTCA/DO-178A. The overall system design is fault-tolerant. Considering the need for hardware and software diversity, I really can't see a credible way of implementing this thing, other than a loosely-coupled, asynchronous networkwhich precludes anything much more sophisticated than polling by client services. In general, the A320 Electronic Flight Control System (EFCS) is a bit too complex to be condemned by a broad statement that it uses "polling." The A320 does not use a "judging" computer such as you describe; clients are partially responsible for minor things such as parity or range checking on the single inputs from the currently active flight control computer. What you seemed to be indicating is more akin to how the *Space Shuttle* works, i.e., having a "majority rules" system of verifying hardware integrity. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = I suppose I should put a big caveat on all my gripes about the A320 over the past three years: yes, I do think the airplane is unsafe. But no, I do not believe that slipshod work went into its design and construction. There is much to suggest that the design of the A320 EFCS represented a quality control system unprecedented in the industry, and which utilized the best techniques of the time. One might quibble with some isolated aspect of it, but the overall approach was sound. My major problem with the *reliability* aspect of the system is Airbus's claim of being able to satisfy the "one catastrophic failure every million hours" clause for flight control systems in the Federal Aviation Regulations. Airbus can't prove it. Moreover, the FAA requirement for the 1e-9 figure explicitly does *not* apply to flight control *software*, even though it applies to flight control *systems*. Draw your own conclusions. There is also sufficient cause to doubt even our best software engineering techniques. This is an issue that many people like to ignore, assuming that, of course we can produce "perfect" software; if it doesn't work, then somebody must have screwed up. NOT true. IMHO, this sort of thing doesn't belong in a civilian airlineryet. Airbus proudly points to its revolutionary airplane, but *revolutionary* anythings are rarely well-understood. Related effects of their decision to use FBW namely, in the form of the pilot interfacewill cause other problems. But Airbus set a precedent, and created a marketing force in the process. Now, other companies have to raise the stakes, too, or risk losing market share. Airbus is extending the A320 EFCS model to include the A330 and A340; Boeing's developing a "tower" (geographically localized hardware) system for the 777. Lastly, there *is* a lot wrong with the A320. But I'm also noticing a lot of scapegoat-bashing going on. The A320's problems are fairly well defined, and need to be corrected. Let's NOT assign our favorite software-engineering pet peeve, arbitrarily, to such a large and accessable target. I'm not addressing this to you in particular, Greg; it's become pretty frequent over the past few months. Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd [References available on request.] Search for Google's copy of this article Date: Mon, 3 Feb 92 21:45:25 CST From: rdd@cactus.org (Robert Dorsett) Subject: Contribution on A320 FMSs It's apparent that some people don't have a clear idea of how the A320's automation is set up. This has been a problem with net discussions for the past couple of years, but it's not getting any better. There have been numerous comments attributing what are clearly flight management problems to the electronic flight control system (FBW): given the notoriety of the A320 (and its FBW) in the academic community, it has been assumed that other problems are unique to it. Many are not. Following is an attempt to explain what flight management on the A320 is, how it differs from FBW, and how it compares to other airplanes (such as the 757). Issues pertaining to the Strasbourg crash appear about 2/3 through. A glossary for the (necessary) alphabet soup follows at the end. Manufacturers each tend to use their own proprietary jargon; in light of that, I've tried to keep the discussion as generic as possible. First, the physical concept of "autopilot" is obsolete on the A320. Instead, Airbus uses a "Flight Management and Guidance System" (FMGS). A more generic term for this is a flight management *system* (FMS). Note the emphasis on *system*. An FMS is a way to accomplish four major goals: o Control the flight path of an airplane, in four dimensions, from takeoff to landing. o Make sure that this is done as profitably as possible. o Provide high-level services to flight displays and other systems. o Eliminate many of the "book-keeping" roles in the operations environment, traditionally performed by a flight engineer. An FMS has many components, the most important of which are: 1. A Flight Management Computer (FMC). This does all the thinking. It derives data from many sources, such as air data computers. On the A320, many input services are partially integrated into the FMS proper. An A320 has two FMCs. 2. Inertial Reference System (IRS) units. These are what Inertial Navigation Systems (INSs) have evolved into; when combined with an FMC, they lead to more features, and are more reliable. They provide position information to the FMC. The FMC has the capability of automatically tuning in VORs and DMEs and verifying the aircraft location, thus correcting for en route precession error in the IRS. There are three IRSs on the A320. 3. A Control Data Unit (CDU). This lets the pilot enter a variety of abstract data, such as the flight number, what the intended route of flight is, preferred cruising altitudes, navaids and fixes to use, etc. The FMC is able to relate all this to an internal database of airports and navaids, and provide a number of convenient features. Using thisas well as features which amount to being a glorified performance calculator the pilot can sketch out a relatively profitable trip. There are normally two CDUs on the A320, one for each pilot. As the first of many asides, at least one recent poster has implied that the FMS interface is similar to that of an INS, which it isn't. The pilot generally does not deal with lat/long numbers, so the potential for a KAL 007 sort of mismanagement is minimal: he deals with gate numbers and four-digit ICAO mnemonics for the airport at hand (but mistakes are still quite common). Some airlines have card readers that feed everything in automatically: the pilot need only verify the flight plan. This process, too, is different from the INS. The user does not normally view the navigation product of the FMS through lat/long readouts on the CDU. Instead, a navigation display shows a plan view of aircraft position, in a variety of scales and formats. The use of the CDU is required when any changes to various types of abstract data are made. 4. A Flight Control Unit (FCU). This is what confuses a lot of people. The FCU is where the autopilot interface used to be in older airplanes, such as the 747-200. It looks a lot like it as well. It is used for selecting short-term features of the FMS, especially heading hold, altitude capture, rate of descent, and autothrottle. The FCU's similarity to an old-fashioned autopilot interface is intentional, but, again, it's just an interface to the FMS. This concept is extended to other input devices in the cockpit. The frequency selectors on the radio panels, for instance, serve as user-friendly input mechanisms for the FMS. Autopilots (until the advent of FMSs) traditionally have been structured around the pilot commanding short-term actions, which the autopilot then faithfully executed. This frees the pilot to adopt a more supervisory role: he can deal with ATC, systems, track weather better, etc. It is also generally less fatiguing than hand-flying. Airbus classifies traditional autopilot management as "selected" control. FMSs also provide such short-term capability (via the FCU). But the FMS can be set to meet all the waypoints and clearance altitudes *automatically*, without any significant interaction needed from the pilots on the CDU or FCU. Airbus classifies this as "managed" control. In effect, with a properly set-up FMS, the pilot can plan a flight from takeoff to landing. After lining up the airplane on the runway, he can just turn loose the FMS, which then flies the airplane, requiring minimal crew interaction. The system can then take the airplane through a category III landing (700 feet runway visual range). Of course, air traffic control is rarely so obliging, so en route modifications must be made to the stored flight plan. This is all done with the presumption that the FMS will figure out and use the absolutely cheapest way to fly the airplane. Even a 1% waste of fuel can cost an airline tens of millions of dollars a year. The main problem with "profitability" is that ATC is not geared to handle FMS-equipped airplanes, and its actions soak up a lot of the "saved" money. It is not clear whether this situation will change in our lifetimes. FMSs are here to stay: but the design of interfaces are a major point of contention among many pilots. Mention "automation," and they don't think EICAS or FBW: they think FMS. While many features have been added at the hardware level in the last ten years, the CDU interface has changed hardly at all. A significant criticismand the most persistentis that, since any changes to an airplane's clearance (the route of flight ATC has approved for it) require changes to the internal flight plan, and since this requires use of the CDU, thus leading to a heads-down posture, safety can be affected: the pilots are not able to practice "see and avoid." In addition, it requires a SIGNIFICANT refocusing of one's attention and attitude, from flying the airplane, to dealing with an unfriendly user interface. It therefore helps put pilots even further out of the loop. This increases workload, but workload can increase even more in terminal environments, where frequent changes to clearances are common (a terminal environment is the airspace where aircraft are being routed to or from a nearby airport). Many airlines have restricted CDU use under 18,000'; still more under 10,000'. In such cases, the airplane is flown with the FCU, or, occasionally, even by hand (!). Balanced against the CDU interface problem is the high degree of "situational awareness" the overall system provides, when one isn't fiddling with the CDU. The FMS provides a number of output services, including navigation information:, the FMCs are the heart of navigation services. One can therefore look at one's navigation display, and see a graphic spatial representation of heading, track (calculated path across the ground), nearby alternate airports, where one will be when one completes a climb or descent, what VORs the airplane is using, where the fixes are, etc. This sort of thing is pretty popular with pilots. But the quality of the derived data products is dependent on the quality of data in the system: thus, there's a tendency to try to keep as much of the display "valid" as possible, which lends to excessive CDU interaction. On the issue of "authority," it is important to note that the pilot must explicitly requests FMS services. The FMS is "on" all the time; but it only *controls* the airplane when the pilot wants it. Whether executing a stored flight plan, or selecting short-term features, the PILOT holds the ultimate authority over the operation of the system. If, after the FMS is engaged, it performs unsatisfactorily, the pilot can just "click it off" (disengage it). There are at least three ways to accomplish this (a switch on the sidestick, buttons on the FCU, or, as a very rare last resort, a circuit breaker). After disengagement, the pilot simply flies "manual" (although "manual" in the A320 is still filtered by numerous computers, and still an artificial construct). The capacity to disconnect assumes the pilot is "in the loop," and is aware that a problem (whatever its cause) exists, to the point of applying corrective action in time. Cockpit interruptions, heads-down postures (CDU interaction or systems diagnostics), fatigue, or checklists can affect this capability. Another factor is the WILLINGNESS to disconnect: a significant problem is that pilots tend to wait too long before clicking off a system; they can become over-dependent on automation. It is unlikely that faults in FMS design could logically migrate to the FBW computers, or vice versa, barring *possibly* a significant electrical system failure. There are elaborate safeguards to protect against completely off-the-wall instructions, but a more insidious, higher-level (but erroneous) command within parameters would simply be quietly executed by the receiving system. It is impossible, as one person recently suggested on sci.aeronautics, for the *FBW* to "freeze" the airplane into some arbitrary navigation maneuver, such as a holding pattern (that tale, repeated at least twice in the last couple of years, is taking on the form of an Urban Legend). The important point to note about all of this is that the FMS has NOTHING WHATSOEVER TO DO WITH FLY-BY-WIRE. It is at least a couple of levels "higher," from the systems integration perspective, than the FBW service. FMSs are used in virtually all modern airliners, such as the 757, 767, 737, MD-11, MD-80, A310, A300-600, and, yes, the A320. Pick an airliner manufactured since 1982, and it'll probably have a cockpit designed around an FMS control concept, regardless of whether it has glass displays, FBW, or both. Of particular interest, recently, has been the A320 FMSs "vertical navigation" functionality. In what follows, "autopilot" should be regarded as a synonym for "FCU," with the understanding that it's just a high-level interface to the FMS, using a subset of FMS features, and can be "clicked off." A few people have been saying things like "altitude can't be set on the autopilot." That is incorrect. The A320's altitude selector is located on the right side of the FCU. Not only can the user set the altitude to fly, but can also set the rate of climb that the airplane should fly at in order to achieve it. The latter can be achieved three ways: 1. By pressing an "Expedite" button, located under the altitude-selector window. This will make the airplane reach the desired altitude as FAST as possible, using either maximum climb attitude and climb thrust, or flight-idle and maximum airspeed. (With the following two modes, one can either select a capture altitude, or let the airplane fly "free." The distinguishing feature between the modes is a simple push-button.) 2. By simply dialing a value into the vertical-speed selector. For example, if one wishes to fly 3000 feet per minute up, the user just dials in 3000 fpm. 3. By flying a flight path angle (FPA). This is an angle the airplane's flight path will make with the ground. The intended use of this feature is rather obscure (other advanced aircraft do not support it), but apparently one application is for use in conjunction with nonprecision approaches to airports. A non-precision approach is one that does not include vertical guidance: the airplane is vectored in a manner such that it reaches a "final approach fix" pointed in the right direction relative to some sort of navigation aid, then flies down to a minimum descent altitude. It then flies toward the airport until it sees it, and can land visually, or is compelled to try again (or divert to an alternate). An ILS, in comparison, provides vertical guidance from the final approach fix down to the ground, even in very marginal visibility. A normal ILS (or visual) approach angle is 3.0 degrees; a non-precision approach is too complex to categorize briefly. The point has to be made, though, that FPA is one of the strangest features in the A320: the airspace system isn't really set up to let the pilots use it effectively. On the A320, in a rather dubious interface, the FPA mode and vertical-speed mode share the same selector. The way vertical speed is set is to dial in a TWO-digit number. So 30 = 3000 feet per minute up; -30 = 3000 fpm down. There is no additional feedbacklike a couple of extra zeroes to indicate one's dialing in "3000." The SAME selector, and the SAME indicator, are used to set "flight path angle." So 30 would then equal a flight-path command of 3.0 degrees down. The difference between the two modes, as said before, is the push of a button, and an easy-to-overlook decimal point. The A320 uses a liquid-crystal display, with fixed numeric elements, to display all of the FCU indicators. So, say one wishes to fly a 3.0 degree flight path. This is the normal slant range between a "final approach fix" and an airport. This would give one a descent from 700 to 900 feet per minute, and the computer would automatically adjust the aircraft's attitude to maintain a glide path, if the pilot lowers flaps, commands a change in airspeed, etc. But there's a clear potential for disaster if this mode is *confused* with "vertical speed" mode. How significant is this? If one is 3000' above the ground, and sets a 3.0 degree flight path, one would contact with the ground in four minutes. If one accidentally engages vertical speed mode, instead, one will contact in sixty seconds. All this is a tad bit simplified, to relate it to normal "straight-in" approach angles: the let-down portion of a non-precision approach would require an even steeper angle (4.0 degrees), with similar consequences should modes be confused. I am interpreting union comments on the Strasbourg crash as suggesting this type of mode confusion may have contributed to the crash. In this case, the FPA mode may have been used in response to an enroute descent air traffic control clearance. When the airplane crashed, it was descending at some 2300' per second, according to one source. The angle of descent between the two transition points the airplane was cleared to fly was 2.28 degrees (from 9000' to 5000', over 19 statute (?) miles). Similar theories about the FPA mode abounded after the Bangalore crash, but proved unfounded (instead, a more complex pattern of FMS mismanagement emerged). The British pilots' union, though, early on cited the poor interface as one that needed to be improved, in a report dated July 1988, a few months after the airplane was introduced into service: "4.2. Glareshield Flight Control Unit. Despite the LCD labelling on the FCU, and the FMA annunciation on the PFD, it is still possible for pilots to commence an approach in the wrong vertical mode, i.e., vertical speed rather than flight path angle. Under pressure, the tendency is merely to look at the figures one is selecting, and the figures themselves look almost identical in both modes. The selection of FPA merely adds a decimal point. I have seen a non-precision approach commenced with the selection of 3000 fpm instead of 3.0 and the result was quite exciting. The FCU figures in FPA mode should be made to look quite different - e.g. the figure after the decimal point in small font." An important point is that automatic control of the airplane can lead to a mismanaged energy state, just as manual control can. The FBW protections in the A320 are designed to provide high-speed, loaded, and slow-speed protections. It does nothing to stop the pilot from managing the airplane in such a manner that it gets dangerously close to an obstruction (the ground) without enough energyor even too much energyto pull out of danger. This is what Airbus claimed happened with the crashes at Habsheim and Bangalore, with the pilots flying manually and dealing with the FCU, respectively. Airbus's Bernard Ziegler's "black holes": energy states the airplane could not recover from. Airbus is faced with the contradictory problems of "protecting" against gross incompetence (safety issues which IT defined as problems, and which its marketing people ran away with), without being able to "protect" from the types of mismanagement their own extreme, and unrealistic, protections appear to engender. Far from changing its interface, it long ago froze it, for use in its newest aircraft, the A330 and A340, thus assuring commonality in trainingand theoretically ensuring a market share among airlines who have bought heavily into the A320. But I digress. :-) If nothing else, I hope I've made the point that FBW is NOT equivalent to flight management. FBW computers are relatively simple and straight-forward in design and purpose: FMSs are fairly complex software/hardware packages. The correct functioning of them is important (especially when used in certain ways), but not as ESSENTIAL as the FBW system. In addition, note that the A320's automation includes many more services than just FMS-derived and FBW: there are various mechanisms to display and control systems information, warning and caution computers, etc. It's also important to note that the A320's cockpit design concept (with the exception of sidesticks and throttle management) is fairly close to that of other airplanes in production or development at this time (747-400, 777, MD-11, etc). FMS is not unique to the A320, although its actual integrated environment (as with all the airframe vendors) is proprietary and unique. Irritating Jargon: ATC Air Traffic Control autothrottle A mechanism for controlling aircraft speed from the autopilot. CDU Control Data Unit DME Distance Measuring Equipment/station. EICAS Engine Indication and Crew Alerting System. FBW Fly by Wire. FCU Flight Control Unit. fix A geographic point, designated by the FAA as a reference point. Used in navigation and routing by ATC. FMC Flight Management Computer. FMGS Flight Management and Guidance System. FMS Flight Management System. IFR Instrument Flight Rules. ICAO International Civil Aviation Organization. ILS Instrument Landing System. INS Inertial Navigation System. IRS Inertial Reference System. KAL Korean Airlines. PFD Primary Flight Display VOR VHF Omni Range. Robert Dorsett rdd@cactus.org UUCP: ...cs.utexas.edu!cactus.org!rdd Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: rdd@cactus.org (Robert Dorsett) Subject: Seeking pointers on switch design. Date: Tue, 24 Nov 92 05:15:42 CST I'm looking for pointers to articles on the human-factors ramifications of switch design. I've noticed an interesting difference between Airbus and Boeing switch philosophy. Boeing seems to build the "on" state into the switch. It might be a white bar, indicating a closed circuit or open valve on a placarded systems a subdued "on" function description, with an "engage" bar, etc. But the philosophy seems to be: "default" state == off (dark indicator), pilot action to turn it on (white indicator), operational state = on (white indicator) until pilot turns it off again or an abnormal state occurs (colored indicator, annunciator). This doesn't violate the "dark cockpit" philosophy, since only one color (white) is used for selects, and abnormal states are clearly detectable. Airbus (in the A320, and presumably the A340 and A330), on the other hand, seems to use smart-logic to default to an "on" state which is completely dark. The switches, when pressed, then show an *abnormal* state, like turning a fuel pump off. Nearly all of the switches also have a "failure" state-flag, showing an amber or red fault message. There are also systems with "mixed" switch formats. For instance, since a fuel pump state is normally on, a switch, when pressed, turns it off and indicates an off state. But crossfeed valve switches, when pressed, show an "ON," followed by "OPEN," state, which seems more "positive." So the Airbus philosophy seems to be: initialize switch states at boot time (on, no indicator), pilot action to turn it off (illuminated, abnormal state), operational state = dark until pilot triggers a disconnect. Seems to me that Boeing's the correct approach: a thou-shalt-not, drilled into me at an early point, was never to use double-negatives to prompt user actions ("Do you not want to save the file? Y/N") . An action should ideally be expressed in *positive* terms. And the interface should be consistent across all systems and within systems. On the other hand, Airbus' design can be rationalized in that if the computers do *all* routine management, as they do, then bringing the pilots in the loop at initial start-up is an invitation for error: in this model, pilot involve- ment is an *abnormal* event, and signs of that involvement should be highlighted. This raises interesting implications of the pilots being out of the loop TOO long, perhaps never dealing with a system or mentally "reviewing" that system for several flights, as would be the case with more "hands-on" initialization and management. This could be the reason behind Airbus's pre-flight "walk-through," in which each switch illuminates in sequence, requiring the pilot to depress it to extinguish the light. Comments? References? - Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: palmer@icat.larc.nasa.gov (Michael T. Palmer) Subject: Re: Flight envelope protections Date: 04 Dec 92 22:30:33 PST rdd@cactus.org (Robert Dorsett) writes: >palmer@icat.larc.nasa.gov (Michael T. Palmer) wrote: >> This has some serious consequences. For example, in the China Airlines >> B-747 incident 300 nm northwest of San Francisco in 1985 (NTSB/AAR-86-03), >> the crew was forced to overstress (and structurally damage) > ^^^^^^ >That might be overstating the case a bit. :-) The NTSB report suggests >they didn't have a clue how to recover from the spiral, once they entered >it, lacking military aerobatic training and being completely disoriented. I >don't believe the report distinguishes the tailplane's damage as being >incidental or intentional. Agreed. I didn't mean to imply necessarily that they KNEW they needed to overstress the airframe, and it is *possible* that this occurred during control inputs that did not actually contribute to the recovery. It's been awhile since I read that report, and I didn't have it handy to refer to. >> crew recovered control with about 10,000 ft of altitude left (from an >> original high-altitude cruise). It is very likely that if the aircraft >> had prevented the crew from initiating control commands that would lead >> to aircraft damage, the aircraft (and passengers) would have been lost. >Your point's well taken, and the risks are certainly worth considering. But >allow me to play devil's advocate, for a minute, without diluting your argu- >ment, and suggest that the EFCS would have prevented an A3[2-4]0 from getting >into the unusual attitude to begin with. The protections are both aerodynamic >and input-filtering (and configuration-evaluating, and...). In the China >Air incident, the flip-over was caused by a "dumb" autopilot/autothrottle >design configuration oversight, following an engine abnormality. If a similar >event had occurred on an A3[2-4]0, the EFCS would probably have limited both >the authority of the FMS to put the airplane into the steep bank, *and* would >have provided maximum corrective action, using opposing controls, to keep the >airplane in the prescribed operating envelope. Well... given the recent post here about the A310 in Moscow going 88 degrees nose-up, I'm not sure that I agree that the Airbus EFCS would necessarily prevent the aircraft from attaining "unusual" attitudes. In fact, it was the "smarts" of the A310 autopilot that actually contributed to that incident. As that poster also mentioned, though, I would like VERY MUCH to see more documentation and a fuller description of exactly what happened. >This is from the Federal Register 54:17, January 27, 1989, pages 3989 and >3996: >P. 3989, the oh-so-enlightening, explanatory commentary: > "The second commenter believes that the flightcrew must be aware of any > failure conditions which affect the structural capability of the > airplane, whether or not a compensating procedure exists. The FAA does > not concur with this comment. It is not necessary for the flight crew > to be aware of a failure in the active control system during the flight > on which the failure occurs if there is no available corrective > action; however, the airplane should not be exposed to the failure > condition for an extended period of time. The flightcrew must > therefore be alerted to the failure condition prior to the next flight." Oh, I get it! Just because a condition exists that may affect OTHER choices I make about how to respond to OTHER occurrences during that flight, that doesn't mean that I have the right to know what is going on with my aircraft. Hmm, seems reasonable... NOT! >This is from the FAA, the agency in charge of establishing airworthiness and >certification practices in the United States! In reality, the A320 likely >*does* provide enough feedback: but the FAA, apparently unnecessarily, has >certainly opened the door for the practice to be introduced in subsequent >types. I agree completely. I work in the Human/Automation Integration Branch in the Flight Management Division at NASA Langley. We have worked for some time examining the complicated interrelationships between events that lead to accidents, and have even constructed software prototypes that try to determine these relationships and make them more explicit. What really scares us is the prevalent attitude of many in the industry that they can anticipate ALL the "important" ways that things will interact, and provide procedures for dealing with them. And whenever you point to an example of how they failed and how that lead to an accident, they respond "Oh, but we've already fixed that." Sure. But what about the NEXT one that you haven't "fixed" yet!?! By the way, the charter of our organization (as if you couldn't tell from what I've said so far) is NOT to solve problems in the cockpit by increasing the amount of automation. Rather, we seek to propose better ways of using the capabilities of both the automation and the flight crew, which may even mean rethinking many of the traditional tasks that automation is used for now. And we do NOT see the "pilot as manager" scenario as being necessarily ideal. Humans tend to make lousy system monitors. Ask the Nuclear people. Human-machine systems work best when the humans are actively *involved*. >> If nothing else, I hope I have brought up some topics that deserve >> discussion among readers of this newsgroup. After all, aren't we the >> ones in positions to influence our industry (all in our own way, of >> course)? >Especially in software, of particular relevance to the net. A lot (if not >most) of the people writing this code4M on the A320, 10M+ on the >A330 and A340are *not* aero engineers: just programmers, ostensibly with >CS backgrounds (a more frightening thought I can't imagine! :-)), performing >under strictly governed, structured, controlled environments: to specif- >ication. >Airbus even mentioned the "CS" types it brought in from "outside" to >buttress a comment on its quality-control practices, in an article, as if >to make the point that mere engineers weren't writing this stuff: the >"pros" are doing it. :-) Yeah, we know what we're doing, SURE... :-) Ummm... this point came up in a Newsweek article (now THERE'S an accurate and unbiased source of information!) about digital flight control systems. They were shocked that programmers, not pilots, were writing the software. I feel at least somewhat qualified to address this issue, since my undergrad is Aerospace Engineering, my master's is Computer Science, and I'm working on the Ph.D. in Human-Machine Systems. Pilots and engineers tend to be experts in specifying how things should happen. My experience with their programming ability is that they tend to not be aware of most of the advances in Computer Science that have occurred over the past 25 years. The result is poorly designed and implemented code that takes Herculean efforts to get working properly and maintain. On the other hand, programmers do not necessarily make good system designers... they tend to think in terms of how things will be implemented (and the limitations of that implementation) rather than in terms of what the system MUST be able to do. I have met only a few people who can combine both talents, to become very good system designers AND software designers. These people have the ability to hear what the pilots and engineers say, and translate that into a total system design, including software design, that meets the requirements and can be implemented. At THIS point, the actual programmers become involved. If changes need to be made due to, say, hardware limitations, then these can be incorporated by either a requirements OR an implementation change. So, I don't think you should be afraid that CS people are writing the code. In fact, you should be glad that they are. You just need to make sure that they are filling in the pieces of a software design that was put together by a competent person like I described above. >Robert Dorsett >rdd@cactus.org >...cs.utexas.edu!cactus.org!rdd I hope I get to meet you at a conference sometime soon! It's great to see that other people are grappling with the same issues. Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681 Voice: 804-864-2044, FAX: 804-864-7793, Email: m.t.palmer@larc.nasa.gov PGP 2.0 Public Key now available Consider it an envelope for your e-mail Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: palmer@icat.larc.nasa.gov (Michael T. Palmer) Subject: Re: Airbus safety (was Re: TWAs Status) Date: 11 Dec 92 17:42:30 PST rdd@cactus.org (Robert Dorsett) writes: >Seriously, this is a tremendously conservative industry. What isn't broken, >doesn't get fixed. However, when a better mouse-trap is invented, it is >almost always adopted, universally. The fact that no other manufacturer >is rushing to repeat Airbus' example suggests the arbitrariness of the >use of the sidesticks: if there were even minor operational or material >advantages in using them (and modified control laws) as interfaces to the >EFCS, you could bet your last dollar every other manufacturer would be doing >so, not least as the result of airline demand. We don't see that. >This isn't one of them. We aren't operating in a vacuum: NASA, as one >example, has been running a lot of research (over, and over) over the >last 20 years, addressing precisely these issues: the Airbus >implementation is arguably on the weaker of a variety of choices >available. My contacts at Boeing agree - Boeing Flight Deck Research has been looking at sidestick controllers for a long time. They have decided that until they develop an airplane that is flown *differently* they will continue to use the column/yoke arrangement. Now, what I mean by differently really refers to switching from ATTITUDE control laws to VELOCITY VECTOR control laws. Mr Dorsett is correct; NASA Langley has decades of experience with sidestick controllers in our B-737 aircraft (it has TWO cockpits - standard in front, and an aft research cab from which you can fly the entire flight profile including landing). The sidestick control has been shown to be best when commanding velocity vector changes instead of attitude changes. This is an interesting way of using automation to ease the burden on the pilot while allowing him to also remain in the loop, since the automation configures the control surfaces to maintain the commanded direction of flight, but the pilot still "flies" the airplane (when not in full-autopilot). The velocity vector control-stick steering mode is by far the mode of choice of the pilots we bring in for experiments. Based on the work here and their own efforts, Boeing has decided that until they build a velocity vector airplane (hint: High-Speed Civil Transport) they will not provide a totally different way to fly an airplane designed with attitude control laws in mind. Please note that I am neither a Boeing employee nor spokesman, and I neither (officially) recommend nor approve of actions taken by them. All the info provided here (about Boeing's position) was provided to me personally by Boeing employees, though, so I have no reason to doubt it. It would be nice if some of you lurking Boeing people jumped in to correct any mistakes I have made. :-) Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681 Voice: 804-864-2044, FAX: 804-864-7793, Email: m.t.palmer@larc.nasa.gov PGP 2.0 Public Key now available Consider it an envelope for your e-mail Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: palmer@icat.larc.nasa.gov (Michael T. Palmer) Subject: Re: Airbus safety (was Re: TWAs Status) Date: 11 Dec 92 17:42:32 PST rdd@cactus.org (Robert Dorsett) writes: >I would also note that in fighter aircraft, there isn't the issue of >two-pilot "peers" having to quickly and instinctively figure out who is >flying the airplane. On the A320, there is no interconnect between the >sidesticks: the captain can command a full-left in an emergency evasive >maneuver, the F/O full-right, and the net result will be an algebraically >added "zero." I believe this is incorrect, though I don't have the documentation here right now. My understanding is that whenever one of the sticks reaches a critical percentage of deflection (say, 75%), it becomes automatically the selected input device. At this point, the other control stick is ignored. So it's a race. Whoever slams their stick to the stops first wins, and the only way for the other crewmember to override is to physically attack the winner. Neat, huh? I'm not sure how sub-critical deflections are handled - they may indeed be algebraically summed. If any Airbus people can provide the straight scoop, I'd appreciate it. In the sidestick implementations used at NASA, the sticks are interconnected ("logically", really, since they are hydraulically back-driven) so that, like in current cockpits, whoever is strongest (i.e., most scared-to-death) wins. Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681 Voice: 804-864-2044, FAX: 804-864-7793, Email: m.t.palmer@larc.nasa.gov PGP 2.0 Public Key now available Consider it an envelope for your e-mail Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: rdd@cactus.org (Robert Dorsett) Subject: Errata (Re: A320 sidestick description + references) Date: 15 Dec 92 00:13:24 PST I thought I had caught most of these, but someone pointed them out: 1. A "daN" is a deca Newton, or 2.248 lbs. Airbus's main redeeming feature is that it's gone SI. 2. The "thumb-override" design means the guy with the *slowest* thumb will win, in the final estimation, not the fastest. Then again, if we really did have a thumb-war, the next guy would be fast to hit it again; I believe that's what I was thinking when I originally wrote the sentence. Apologies for any confusion this caused. 3. The comments on the necessity of applying back-stick in a turn were ambiguous. I was using as an example a situation of an airplane, straight and level. Suppose you're in a conventional airplane. You want to turn. You'd turn the wheel. This causes the airplane to bank. However, this decreases the net lift vector, which means the airplane will also descend. To counteract this effect, you'd apply slight back-stick, to command up- elevator, thus a greater angle of attack, thus more lift, to maintain level flight in the turn. It's all very coordinated, very natural. On the A320, one would simply use the stick to command a yaw. The system automagically applies the appropriate elevator correction to maintain the ancipated flight-path. If the pilot were to command any pitch-up, the airplane would CLIMB in the turn. This takes place in "Normal" law, the default flight mode. This is not "normal" as in "conventional": that's the "Direct" law, which is also the landing mode, so as to allow the pilot to handle a cross-wind landing and flare properly. If there are any more ways I can make this more confusing, please let me know. :-) - Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Newsgroups: sci.aeronautics.airliners From: rdd@rascal.ics.utexas.edu (Robert Dorsett) Subject: Pilot attitudes on A320 (RE: A320 cockpit visit) Date: 17 Jun 93 23:51:35 PDT > It is very strange, I've spoke with people who do not fly A320, they do not >like it, I've spoke with people who fly it, they are found of it ! I cannot >understand that. I've a theory on this. Four components: 1. Anyone remember MacEvangelism? The sales and marketing effort for the Macintosh, taken on a slightly "religious" bent. Airbus shares a similar culture, in almost every aspect of production and operations. It *isn't* limited to the marketing people. Engineers, pilots, training, all reflect this. Airbus is proud of its technology, and explicitly makes a big deal of it, for the purpose of differentiating its products. This is actually a fairly sharp tact, since *most* airlines aren't "Airbus airlines," and that single entry into the fleet has to make a significant, favorable impression. What better way than characterizing the traditional, safe, conservative competition as technical Luddites? 2. I suspect the first couple of crashes may be partially attributable to this er, over-enthusiasm. Aeroformation's training program is called VACBI, Video-Audio-Computer-*Based* Instruction. It can be likened to brainwashing: very intensive, one-on-one interaction with the computer: answer the right questions the right way enough times, and you become a Believer. It goes beyond "traditional" teaching techniques. Well, a clear problem with the early software was that it emphasized the gee-whiz features of the systems, at the detriment of basic airmanship and operational philosophies needed to maintain safe flight. After the second plane augured in, Airbus issued plaintive warnings to pilots to fly the airplane the "old fashioned way," and not to maneuver anywhere near the protections, since by default that means one is in a low-energy category to begin with, and may not have sufficient maneuvering capability, to avoid pesky obstacles, like golf courses. Yet even now, as Andy's Mexicana visit article clearly shows, pilots are still flying well into the envelope. There's no excuse for this. 3. Pilots aren't the smartest creatures in the world. Every two or three months in AIRLINE PILOT, the ALPA rag, one sees "letters to the editor" from A320 pilots. These invariably boil down to "gee, it flies great, so why's everyone criticising the airplane?" Sort of like the attitudes of DC-10 pilots: "gee, it flies great, so why's everyone criticising the airplane?" :-) Hey, it makes their landings look good! Flies like a fighter! All that rubbish. The ramifications of an airplane design possibly being responsible for an unnecessary crash every few years doesn't seem to rate very highly among these people. Another significant component of this is that a LOT of pilots, bless them, confuse FBW with glass. Thus, a pilot might upgrade to an A320 from a DC-9, see all the glass, and think it's WONDERFUL, and attribute the existence of glass to the FBW system. This hasn't a great deal to do with the A320's contribution to technology, though, and "glass" predated the A320 by seven years or so. 4. The "Can Do" mentality. Pilots tend to be gadget hounds: they WANT to fly the shiniest, newest airplane on the block, and, once in it, WILL make it work. After you fly a few trips and it doesn't kill you, you become a bit more trusting. This relates to training: *total* immersion: forget everything you've learned, and focus on the new airplane, "make it work." Military pilots, for instance, are legendary in disparaging equipment they're *not* flying. When they transition, though, they HAVE to make it work, or suffer the consequences. It's common to see them become "instant converts." Many pilots are frank about this. I suspect the same psychology is at work, here. Is this sort of "admiration" and "devotion" "real"? Yeah, probably. And I have an ethical dilemma when discussing this sort of thing with pilots: is it wise to undermine their confidence in a system which they HAVE to make work? *My* experience has been similar to the others: A320 pilots luuuuuuuuv their airplanes. Yet when I've probed a little bit, I've usually uncovered some pretty spectacular problems, which they're "working around" to do their job, or otherwise compensating for. I also usually find a dichotomy of intense fondness for the glass, but a real preference for older airplanes, like the 727. "If only they were more glassy..." Whatever the reason, the FACT remains that there have been three A320 crashes, in as many years. No other aircraft of similar technological vintage757/767, A310, A300-600, 747-400can claim the same. It is very puzzling that, considering the "glassy" similarities among these air- planes, there haven't been more problems, fleet-wise. Perhaps one difference is that on the other airplanes, pilots are more in the loop, on their toeswhereas with the A320/330/340, one is in that blasted *cocoon*, and taught to BELIEVE! Then again, there is evidence that from a cockpit-workload perspective, older, conventional cockpits, with simpler flight controls, may be safer and have lower workload in emergency situations. See Wiener et. al., "The Impact of Cockpit Automation on Crew Coordination and Communication," released November 1991 as NASA CR 177587. As an old pilot once told me: "NO airplane is safe." All things con- sidered, I'd rather have a pilot with a healthy grain of skepticism for the gee-whiz features, and make this a general requirement for the breed. Perhaps if more pilots were skeptical, manufacturers would be less likely to be "innovative" for poorly based functional or practical reasons. It's telling that Airbus has extended the old maxim "trust your instruments" to "believe in your airplane." Blind faith has no place in an effective safety culture. Robert Dorsett Internet: rdd@rascal.ics.utexas.edu UUCP: ...cs.utexas.edu!rascal.ics.utexas.edu!rdd Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article Search for Google's copy of this article ... About | |
|
