12 ms·

Flight QF72: What happens when automation leaves pilots powerless?

130 points by korethr 9y ago

korethr 9y ago
Note to mods: I modified the title slightly, as the original was too long. I dropped the word 'pycho' from 'psycho automation' as I felt it had the least impact of any word to substitute or drop from the title.
robbiep 9y ago
Read this last weekend on the beach. Interesting. That poor bastard who put the life jacket around his neck at 30,000 feet and inflated it...
- codys 9y ago
  To be fair, all the safety briefings I've seen tell you not to do that. ("Do not inflate while inside the airplane" is the line, I believe).
  - knz 9y ago
    Most people assume that's just a precaution to make it easier to move around the cabin and not a choking hazard!
    - fphhotchips 9y ago
      Massive part of the reason is because if the airplane ditches into the water, the life jacket can make it very difficult for you to escape [1]. https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_961 https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_961
      - robbiep 9y ago
        I assume that the pressure differential between sea level and 30,000 feet is going to change how inflated it gets as well
korethr 9y ago
Also found these, the official investigation reports from the incident. https://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspx https://www.atsb.gov.au/publications/investigation_reports/2...
- turbohedgehog 9y ago
  That's disconcerting that they still don't know for sure what caused this issue and if it could happen again.
  - korethr 9y ago
    It is disconcerting. I do take some heart in the fact that there's thousands of safe operational hours on the flight computers in question. That said, I'd hope that behind the scenes, there's some engineers pouring over data and test units to find exactly why it happened and what needs to be fixed to ensure it can never happen again.
    - dtech 9y ago
      They did that for the investigation and couldn't find any probable cause. At some point you have to admit defeat and accept that the cause will not be found.
  - zkms 9y ago
    We don't know for sure what caused the ADIRU to start outputting the current altitude numbers but tagged as angle of attack values but this shouldn't have caused an in-flight upset. A spike in AOA from 2.1 degrees to 50.625 degrees and back in 3 seconds is not physically possible, and indeed, the flight computers are capable of detecting and ignoring such flagrantly erroneous data, even if the ADIRU's built-in-test-equipment hasn't announced an ADIRU failure. However, the code that detected anomalous changes in ADIRU data output was a simplistic filter that was vulnerable to a very specific timing of erroneous spikes. It could not handle spikes that were 1.2 seconds (an arbitrary parameter of the filter) apart, and, well, this specific ADIRU failure happened to send erroneous data with that exact timing. The flight computer thus thought that 50.625 degrees was a valid AOA measurement, and reacted accordingly -- by commanding a pitch down with the elevators to avoid the "stall" it thought it was experiencing. The only issue that hasn't been addressed in the report (which is good reading, https://www.atsb.gov.au/media/3532398/ao2008070.pdf https://www.atsb.gov.au/media/3532398/ao2008070.pdf) is that the angle-of-attack value is not directly displayed to the pilots on their flight displays. AOA is measured by the 3 ADIRUs and is one of the most crucial measurements used by the flight computers and their control laws -- after all, whether the wing is stalled or not is a direct function of AOA! AOA value is also critical to upset / loss-of-control / stall recovery but without an AoA instrument, the pilot needs to infer it from other instrument values -- which is nontrivial and also depends on instruments that might be malfunctioning. Hiding the most crucial air data parameter from the pilots (who are expected to take over when the computers or the air data sensors act up) is a bad design decision. Sullenberger agrees, "We have to infer angle of attack indirectly by referencing speed. That makes stall recognition and recovery that much more difficult. For more than half a century, we've had the capability to display Angle of Attack in the cockpits of most jet transports, one of the most critical parameters, yet we choose not to do it.": http://www.safetyinengineering.com/FileUploads/Situation%20awareness%20and%20HMI_1369663651_2.pdf http://www.safetyinengineering.com/FileUploads/Situation%20a... . This was a recommendation in the AF447 report as well, " It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required." Displaying AOA in the flight displays might have helped in this incident as well. Had the pilots seen indicated AOA values spiking immediately preceding the uncommanded pitch-downs, diagnosis and corrective action (which might have included disabling the offending ADIRU) would have been much easier.
dtech 9y ago
Jesus, that article contains an ungodly amount of annoying padding. TLDR; Plane makes two steep dives within 3 minutes without apparent mechanical failure or pilot intervention, injuring a number of passengers. Plain manages a safe emergency landing. Dives were initiated by a flight computer, which could override pilot input, reacting to faulty data. No one died, but some persons have lasting physical damage.
- johansch 9y ago
  Yeah, that was annoying to read. https://en.wikipedia.org/wiki/Qantas_Flight_72 https://en.wikipedia.org/wiki/Qantas_Flight_72 Root cause: a fault with one of the plane's three "Air Data Inertial Reference Units": https://en.wikipedia.org/wiki/Air_data_inertial_reference_unit https://en.wikipedia.org/wiki/Air_data_inertial_reference_un... This error condition then exposed a bug in the aircraft's software which caused the dives.
_acme 9y ago
Similarly, Captain Sullenberger said that in respect of US Airways Flight 1549, computer-imposed limits prevented him from achieving the optimum landing flare for the ditching, which would have softened the impact.
ams6110 9y ago
No system, human or mechanical or computer, is perfect. Human pilots have crashed more airplanes and are more likely to crash airplanes than automated systems. Human pilots have also saved airplanes when the systems fail. For the foreseeable future, it's probably best to have both, but nothing in life can ever be perfectly safe.
- wahern 9y ago
  Is there a site somewhere that attempts to catalog 1) instances where the flight computer prevented an incident due to pilot error 2) instances where the flight computer caused an incident I understand it's not always (if ever) so black & white, and I'm sure there's a better way to break things down. But it'd be interesting to read something that attempts to keep some kind of score.
  - colechristensen 9y ago
    It's a question that can't really be answered. It's sort of like asking about 1) instances where your alarm clock prevented you from being late to work 2) instances where your alarm clock failed to wake you up How could you possibly determine how often your alarm clock prevented you from being late? You can certainly tell how often it fails to do it's job, but you can't determine how often it's success is necessary because there aren't any near misses to detect. With no control group there can be no comparison. You could count incidents which the flight computer is helpful, but you cannot count incidents that never happened in the first place because of the flight computer.
    - wahern 9y ago
      OTOH, Airbus and Boeing use different systems. Some alarm clocks kick you out of bed, shower you, and drive you to work. Other alarm clocks just pull the covers off and poor cold water on you, but still require you to do the rest. So you could analyze instances where the latter proved insufficient and try to guess whether the former would have been sufficient. The bigger problem is probably that there just aren't enough useful extreme incidents to be draw any conclusions. Or maybe there are. That's why I'm most curious if anybody has even tried. All I ever hear is that air safety has increased along with an increase in computerization. But that tells me very little. Everything about the aircraft and its ground support has been getting better, not to mention the training of the humans.
nikcub 9y ago
Happen to another Qantas flight in the area, QF71 - hence the theory about the high-power VHF transmission station in the area being responsible: https://en.wikipedia.org/wiki/Naval_Communication_Station_Harold_E._Holt#Aircraft_interference_controversy https://en.wikipedia.org/wiki/Naval_Communication_Station_Ha...
- harshbutfair 9y ago
  I think the second event you're thinking of was a Malaysia Airlines flight from Perth to Kuala Lumpur. https://www.atsb.gov.au/publications/investigation_reports/2005/AAIR/aair200503722.aspx https://www.atsb.gov.au/publications/investigation_reports/2...
  - madeofpalk 9y ago
    No, there was an incident several months later with QF71 flying the same route in the opposite direction. https://en.m.wikipedia.org/wiki/Qantas_Flight_72 https://en.m.wikipedia.org/wiki/Qantas_Flight_72 See the subheading in the Final Report section
    - madeofpalk 9y ago
      direct link: https://en.wikipedia.org/wiki/Qantas_Flight_72#Subsequent_Qantas_Flight_71_incident https://en.wikipedia.org/wiki/Qantas_Flight_72#Subsequent_Qa...
sceew 9y ago
Aren't we always going to have two pilots? a captain in case the computers fail, another in case the captain fails. Automation (airpilot) has already been around...?
outworlder 9y ago
> His reasoning is simple: how can the plane stall and over-speed at the same time? It can. It's called the "coffin corner".
- noir_lord 9y ago
  Hadn't heard of that, read the Wikipedia article, fascinating.
- rzzzwilson 9y ago
  I remember reading comments by a U-2 pilot that turns had to be very shallow at height due to the possibility of the inside wing stalling and/or the outside wing entering mach buffet. !
- mikevin 9y ago
  Link[1] for those who want to know more. [1] https://en.wikipedia.org/wiki/Coffin_corner_(aerodynamics) https://en.wikipedia.org/wiki/Coffin_corner_(aerodynamics)
amluto 9y ago
As I understand it, Boeing planes physically move the cockpit controls to reflect computer control inputs. Would that approach have made a difference in this event?
- mjevans 9y ago
  Maybe, surely more so if the pilots resisting that intended change in control were given priority. I very much like how the redundant sticks are /forced/ to stay in sync. What's done to one IS done to the other as well. That's a critical safety feature in the human interface. I think a complete human over-ride of 'higher level' functions (disable the auto-pilot) should require 'two keys' like in War Games (with the nuke silo). The lower level systems still have to exist, and there should be a way of troubleshooting (graphs probably) their inputs and outputs over time.
  - hlandau 9y ago
    IIRC, Boeing 777s (which are FBW) will automatically disengage the autopilot if you start forcing the stick to a different position. The flight envelope protections are implemented by adding a physical resistance to the stick, but can be overridden by using force, which seems a highly intuitive and deferential implementation. It certainly seems a lot more responsible than Airbus's design, both for the above reasons and for the mechanical linkage you mention.
cbanek 9y ago
They mention it once in the article, but this has basically been true since fly-by-wire, which was quite a while ago. While it may seem timely to blame automation for this one, you could just as easily blame faulty sensors (like the iced up sensors they mention) or faulty mechanicals, such as pumps, hydraulics, wiring, electrical shorts, etc. The sad thing is, as we go faster (both in terms of speed and technology), things will only get more complex. We're also far past the point where human pilots and crew might be able to do something about it. Let's say it wasn't fly-by-wire, and it was hydraulics tied to the stick. If you lost power, you still probably wouldn't be able to move the stick, or it wouldn't do anything. Either way you are in deep trouble. The real solution is redundancy. They mention the triple flight computers in the Airbus, but in the end, there will always be possible problems of all types. In computers, there are also hardware (not software bugs) errors that may occur at any time. One of the things devs love to joke about is heisenbugs. If you have debugged these, and only found them on one machine, it's probably your memory doing a bit-flip. Solar radiation can do that, especially at higher altitudes. Just because we're behind our magnetic field doesn't make it go away, and at higher altitudes you do have a slightly higher error rate. Now we're just back to byzantine general territory where you have to figure out which one is lying. Again, coming down to probability that you didn't lose two at the same time. While it's easy to say that the system should have just done "the right thing" - when you learn more about how the system works, and how complicated it is, you realize how hard that is. And problems in handling errors or trouble are some of the hardest to find, and have the most damaging consequences. Spacecraft (manned or otherwise) have these exact same problems. (Source: I've worked on aerospace systems) https://en.wikipedia.org/wiki/Fly-by-wire https://en.wikipedia.org/wiki/Fly-by-wire
- caf 9y ago
  ...you could just as easily blame faulty sensors... Well, no - faulty sensors are an inevitability, so the automation needs to be able to continue to function effectively in that eventuality. Which is, of course, a well-understood part of the design space.
  - cbanek 9y ago
    Everything is an inevitability, that's the problem with the design space. We haven't yet invented some perfect machine that will handle everything. But there are functional and realistic limits to how well you can perform under certain failure scenarios. You might have to increase weight to add more sensors and wiring. That logic to reconcile more sensors will be more complex, and possibly prone to error itself. Added complexity against failure doesn't necessarily increase safety, as much as we always wish it would.
WalterBright 9y ago
> control over the horizontal tail – 3000 pounds per square inch of pressure that can be moved at the speed of light. Not quite. If I recall correctly the tail will move about 1/2 degree per second. Hardly the speed of light. The elevators are hydraulically operated and can go much faster, but hydraulics don't move at the speed of light, either. The 3000 psi refers to the hydraulic pressure in the system, which has kinda nothing to do with how fast things move. Boeing considered going to a higher pressure to save weight, but rejected the idea because a pinhole leak at such pressures would act like a knife on human skin. Source: I worked on the horizontal tail design of the 757.
- PhantomGremlin 9y ago
  Yeah, that particular sentence really grated on me. I also didn't like: Booooom. A crashing sound tears through the cabin. In a split second, the galley floor disappears beneath Maiava's feet, momentarily giving him a sense of floating in space. I initially thought there was some sort of structural failure of the cabin floor.
  - WalterBright 9y ago
    Most articles written by journalists about technical issues read like the journalist took the facts and ran them through a Mixmaster before printing them. One nice anomaly is the "Aviation Disasters" TV series, which gets the tech right as far as I can tell.
- GICodeWarrior 9y ago
  The wording is technically imprecise in a number of places. The mechanical components certainly can't move at any significant fraction of c, but they may be referring to the electrical fly-by-wire signals controlling them. Still not precisely the speed of light, but close enough if that's what they meant.
wahern 9y ago
What I found most interesting was how unnerved the pilot (a bone fide Top Gun graduate) became by his newfound sense of lack of control. It ruined flying for him and effectively ended his career. I would have assumed that coming to terms with a lack of control was one of the first things a fighter pilot would have to learn to deal with. But maybe you can't be a good fighter pilot unless you can fool yourself into thinking you're always in control, and that lack of control is really just a personal failing (didn't train hard enough, not thinking clearly enough, etc). Or maybe with age you just lose the ability to handle that kind of stress. AFAIU the older you get the more likely you are to become overwhelmed by anxiety. Which seemed totally counterintuitive until I watched others get older--including myself--and saw how that works. I guess that was sort of the plot to Top Gun, too. ;)
- pdonis 9y ago
  > I would have assumed that coming to terms with a lack of control was one of the first things a fighter pilot would have to learn to deal with. I think it wasn't just the lack of control; it was the inability to do anything to regain control. My father was a test pilot; there were plenty of times where his airplane did something unexpected and he lost control. But he always had some option for regaining it. (In the last extremity, he could eject--which he actually had to in one test flight. I noticed that the lack of that option in an airliner was mentioned in the article.) Also, this was a situation where, as the pilot said, he could easily have kept control of the plane, if only the plane had let him. But the plane was listening to the computers instead of him. To me, if you're going to have highly trained humans in the cockpit, it doesn't make sense not to give them a last-dicth way of telling the airplane to stop listening to the computers and start listening to them.
  - wahern 9y ago
    > there were plenty of times where his airplane did > something unexpected and he lost control. But he always > had some option for regaining it. (In the last extremity, > he could eject [....]) But that's not really a lack of control. In those cases you're merely being challenged to regain control of the aircraft. You just need to fight harder, think smarter, or exit. In any event you still have control (or at least a sense of control) over your life. I understand why this issue was so unnerving for the pilot. Heck, any passenger could sympathize: it's why flying can be so scary--total and complete lack of control; little to any knowledge about what's happening and why; you're completely at the mercy of somebody else, or nothing at all. So, yeah, I get it. I was just thinking that of all sorts of pilots, a fighter pilot would be the last to be unnerved by losing control; unnerved to the point of not wanting to fly anymore. a) Fighter jets are super powerful and super sophisticated and when something goes wrong there may not even be any time to regain control no matter your training or experience; you're always flying at that envelope where the unexpected can and often does happen, so I just assumed you invariably accept that you're flipping a coin every time you take-off. b) I presume combat is one of those things where you either resolve yourself to a lack of control or realize you're not able to cope and move on to something else (if you can, and assuming you can move on emotionally). But I guess I shouldn't presume a modern fighter pilot (esp. from the 1980s) to have experienced the same sort of peril as someone on the ground during a war. That said, I'm not trying to suggest he lost his mind or something. He responded appropriately in the moment. He was able to let his training and experience dictate his responses. He consciously understands that he was unnerved after the fact because of that lack of control, as opposed to not understanding those feelings and fears. I'm just surprised that those feelings (or at least their severity) were novel to him and changed his perception of flying, not that he was unnerved, per se.
contingencies 9y ago
This was already submitted and discussed at https://news.ycombinator.com/item?id=14336897 https://news.ycombinator.com/item?id=14336897 and https://news.ycombinator.com/item?id=14328294 https://news.ycombinator.com/item?id=14328294. My summary at https://news.ycombinator.com/item?id=14329082 https://news.ycombinator.com/item?id=14329082 is still the most in depth researched as far as I can tell (I actually read a lot of the air safety bureau report). Basically Northrup Grumman's ADIRU units had sporadic software bugs (off by one - typical of software written in needlessly low level languages) and the Airbus control system that combined the output of the three redundant ADIRUs didn't properly deal with the case of failure in one of the three (even if 2/3 agreed with GPS!), didn't provide transparent training and resolution procedures to pilots for this class of situation, and was generally trusting the broken unit instead of the other two or the GPS which were operating fine. Even calling the crisis center of the major airline for assistance on the ground couldn't help resolve the situation. So... problems in both companies, but Airbus is mostly to blame, even if testing could not be expected to tease out all bugs in third party components, primarily because they were not logging issues and resolving them from the millions of flight hours these things already had, and because they had not tested their fly-by-wire system with worst case input, ie. what's the point of redundancy if you trust the broken unit?
- perilunar 9y ago
  Also https://news.ycombinator.com/item?id=14330913 https://news.ycombinator.com/item?id=14330913
- mathgenius 9y ago
  After the Intel FDIV bug [1] they started using formal verification to make sure the cpu's did what they said they would. I don't understand why they don't do the same for these avionic systems. Maybe it's just not worth it to the company. [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
  - flashmob 9y ago
    Would you say that this has limitations and it's not a silver bullet? Eg. What if your software added numbers, formal verification proved that your program was indeed correct because it added the numbers. However, it missed the requirement that you also had to do subtraction, which for some reason was omitted in the specification.
ptero 9y ago
This is unquestionably a very scary situation. Kudos to pilots who got the plane down without loss of life. However painful this state is (broken autopilot, no full human override) I suspect fly by wire actually prevents many more accidents than it causes.
DuckConference 9y ago
Don't the pilots have the option of engaging alternate flight rules in this case? Or is that not how it works?
boznz 9y ago
On the whole I would still prefer well tested software over a human anytime.
cmurf 9y ago
I am a pilot, and my complaint is not the lack of a last ditch emergency manual mode, but that there are numerous modes (or alternate laws) in the software abtraction of fly by wire aircraft, and the plane responds differently to inputs in these different modes, the notification for what mode the system is in has to be inferred, and the pilot is expected to know all of these things. I think it's hubris and incompetence in engineering that a system would be designed this way. And in fact not all of them have these same deficient behaviors, so this is not inherent to fly by wire or automation. It's a choice made by the software abstraction designers. The idea there'd be a mode where advancing a throttle literally does nothing, no increase in power nor a notification that the input received is sensed but isn't going to do what you think it should so that you have a clue in that some other mode is applied, is so totally batshit insane to me. It's a huge betrayal of physics of flight which is something pilots do understand rather well, almost like muscle memory. In a conventional plane, throttle advance always increases power. If that doesn't happen, it's an emergency. In a fly by wire plane if it doesn't happen, it almost certainly means the pilot is confused. And that to me is crap design.
Figs 9y ago
This story reminded me of the adage: "They say that to err is human, but to really fuck up, you need a computer..."
marze 9y ago
What a poor design. Pilots should have a hard "manual control" switch that turns control completely to the pilots. A friend of mine from childhood became a top expert in formal verification, and got a contract many years back to help Airbus perform formal verification on their control software. I don't know many details, but according to my friend's father, he would never fly on an Airbus jet after this experience. A pilot friend told a story of some pilot friends of his who were piloting an Airbus in Canada, many years back, who couldn't get the jet to give control back and get out of a holding pattern to land. They had to wake up engineers in France in the middle of the night, who told them to take a hammer to certain fuses or breakers, and let them regain control. From a UI point of view, the control system and displays in the Airbus are a disaster. For instance, the pilots in the Air France plane that stalled over the pacific couldn't figure out that the plane was stalled for several minutes before it was too late to correct, with all of the displays in front of them.
- hlandau 9y ago
  AFAIK there is such a switch: there are switches to disconnect the primary computers on the overhead panel. If those are disconnected, presumably the aeroplane reverts to direct law and flight envelope protections become inoperative. I might be mistaken though; I'm no pilot and you seem more knowledgable. The article mentions they were able to regain control of the plane by leaving one of the primary computers disabled. (The end of the article itself has a quote from Airbus suggesting there's always supposed to be a way to get full control; presumably this is what they're referring to.) I was surprised that they left the other computers enabled, especially given that the article suggests they were worried whether it would happen again; to me, the obvious thing would be to do would be to disable all primary computers and use direct law. Malfunction of the flight envelope protections seemed the obvious culprit from the moment it was mentioned the sticks were ignoring commands, short of a mechanical failure in the control surfaces themselves. Certainly AF447 has demonstrated that Airbus aircraft are very poorly designed from a user interface perspective. The anecdotes you have about people working at Airbus sound highly interesting and would be worthy of blog posts in themselves. Would your friend ever consider writing about these concerns (anonymously even)? Also, was an accident report ever filed for that holding pattern incident? Can I read about it?
Avalyst 9y ago
Reminds me of SK751 [1] where an automated system prevented the pilots from powering down a broken engine, resulting in both engines failing and the plane crash landing in a field north of Stockholm. [1] https://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_751 https://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_7...

130 points by korethr 9y ago

Note to mods: I modified the title slightly, as the original was too long. I dropped the word 'pycho' from 'psycho automation' as I felt it had the least impact of any word to substitute or drop from the title.

robbiep 9y ago

Read this last weekend on the beach. Interesting. That poor bastard who put the life jacket around his neck at 30,000 feet and inflated it...

codys 9y ago
To be fair, all the safety briefings I've seen tell you not to do that. ("Do not inflate while inside the airplane" is the line, I believe).
- knz 9y ago
  Most people assume that's just a precaution to make it easier to move around the cabin and not a choking hazard!
  - fphhotchips 9y ago
    Massive part of the reason is because if the airplane ditches into the water, the life jacket can make it very difficult for you to escape [1]. https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_961 https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_961
    - robbiep 9y ago
      I assume that the pressure differential between sea level and 30,000 feet is going to change how inflated it gets as well

korethr 9y ago

Also found these, the official investigation reports from the incident. https://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspx https://www.atsb.gov.au/publications/investigation_reports/2...

turbohedgehog 9y ago
That's disconcerting that they still don't know for sure what caused this issue and if it could happen again.
- korethr 9y ago
  It is disconcerting. I do take some heart in the fact that there's thousands of safe operational hours on the flight computers in question. That said, I'd hope that behind the scenes, there's some engineers pouring over data and test units to find exactly why it happened and what needs to be fixed to ensure it can never happen again.
  - dtech 9y ago
    They did that for the investigation and couldn't find any probable cause. At some point you have to admit defeat and accept that the cause will not be found.
- zkms 9y ago
  We don't know for sure what caused the ADIRU to start outputting the current altitude numbers but tagged as angle of attack values but this shouldn't have caused an in-flight upset. A spike in AOA from 2.1 degrees to 50.625 degrees and back in 3 seconds is not physically possible, and indeed, the flight computers are capable of detecting and ignoring such flagrantly erroneous data, even if the ADIRU's built-in-test-equipment hasn't announced an ADIRU failure. However, the code that detected anomalous changes in ADIRU data output was a simplistic filter that was vulnerable to a very specific timing of erroneous spikes. It could not handle spikes that were 1.2 seconds (an arbitrary parameter of the filter) apart, and, well, this specific ADIRU failure happened to send erroneous data with that exact timing. The flight computer thus thought that 50.625 degrees was a valid AOA measurement, and reacted accordingly -- by commanding a pitch down with the elevators to avoid the "stall" it thought it was experiencing. The only issue that hasn't been addressed in the report (which is good reading, https://www.atsb.gov.au/media/3532398/ao2008070.pdf https://www.atsb.gov.au/media/3532398/ao2008070.pdf) is that the angle-of-attack value is not directly displayed to the pilots on their flight displays. AOA is measured by the 3 ADIRUs and is one of the most crucial measurements used by the flight computers and their control laws -- after all, whether the wing is stalled or not is a direct function of AOA! AOA value is also critical to upset / loss-of-control / stall recovery but without an AoA instrument, the pilot needs to infer it from other instrument values -- which is nontrivial and also depends on instruments that might be malfunctioning. Hiding the most crucial air data parameter from the pilots (who are expected to take over when the computers or the air data sensors act up) is a bad design decision. Sullenberger agrees, "We have to infer angle of attack indirectly by referencing speed. That makes stall recognition and recovery that much more difficult. For more than half a century, we've had the capability to display Angle of Attack in the cockpits of most jet transports, one of the most critical parameters, yet we choose not to do it.": http://www.safetyinengineering.com/FileUploads/Situation%20awareness%20and%20HMI_1369663651_2.pdf http://www.safetyinengineering.com/FileUploads/Situation%20a... . This was a recommendation in the AF447 report as well, " It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required." Displaying AOA in the flight displays might have helped in this incident as well. Had the pilots seen indicated AOA values spiking immediately preceding the uncommanded pitch-downs, diagnosis and corrective action (which might have included disabling the offending ADIRU) would have been much easier.

dtech 9y ago

Jesus, that article contains an ungodly amount of annoying padding. TLDR; Plane makes two steep dives within 3 minutes without apparent mechanical failure or pilot intervention, injuring a number of passengers. Plain manages a safe emergency landing. Dives were initiated by a flight computer, which could override pilot input, reacting to faulty data. No one died, but some persons have lasting physical damage.

johansch 9y ago
Yeah, that was annoying to read. https://en.wikipedia.org/wiki/Qantas_Flight_72 https://en.wikipedia.org/wiki/Qantas_Flight_72 Root cause: a fault with one of the plane's three "Air Data Inertial Reference Units": https://en.wikipedia.org/wiki/Air_data_inertial_reference_unit https://en.wikipedia.org/wiki/Air_data_inertial_reference_un... This error condition then exposed a bug in the aircraft's software which caused the dives.

_acme 9y ago

Similarly, Captain Sullenberger said that in respect of US Airways Flight 1549, computer-imposed limits prevented him from achieving the optimum landing flare for the ditching, which would have softened the impact.

ams6110 9y ago

No system, human or mechanical or computer, is perfect. Human pilots have crashed more airplanes and are more likely to crash airplanes than automated systems. Human pilots have also saved airplanes when the systems fail. For the foreseeable future, it's probably best to have both, but nothing in life can ever be perfectly safe.

wahern 9y ago
Is there a site somewhere that attempts to catalog 1) instances where the flight computer prevented an incident due to pilot error 2) instances where the flight computer caused an incident I understand it's not always (if ever) so black & white, and I'm sure there's a better way to break things down. But it'd be interesting to read something that attempts to keep some kind of score.
- colechristensen 9y ago
  It's a question that can't really be answered. It's sort of like asking about 1) instances where your alarm clock prevented you from being late to work 2) instances where your alarm clock failed to wake you up How could you possibly determine how often your alarm clock prevented you from being late? You can certainly tell how often it fails to do it's job, but you can't determine how often it's success is necessary because there aren't any near misses to detect. With no control group there can be no comparison. You could count incidents which the flight computer is helpful, but you cannot count incidents that never happened in the first place because of the flight computer.
  - wahern 9y ago
    OTOH, Airbus and Boeing use different systems. Some alarm clocks kick you out of bed, shower you, and drive you to work. Other alarm clocks just pull the covers off and poor cold water on you, but still require you to do the rest. So you could analyze instances where the latter proved insufficient and try to guess whether the former would have been sufficient. The bigger problem is probably that there just aren't enough useful extreme incidents to be draw any conclusions. Or maybe there are. That's why I'm most curious if anybody has even tried. All I ever hear is that air safety has increased along with an increase in computerization. But that tells me very little. Everything about the aircraft and its ground support has been getting better, not to mention the training of the humans.

nikcub 9y ago

Happen to another Qantas flight in the area, QF71 - hence the theory about the high-power VHF transmission station in the area being responsible: https://en.wikipedia.org/wiki/Naval_Communication_Station_Harold_E._Holt#Aircraft_interference_controversy https://en.wikipedia.org/wiki/Naval_Communication_Station_Ha...

harshbutfair 9y ago
I think the second event you're thinking of was a Malaysia Airlines flight from Perth to Kuala Lumpur. https://www.atsb.gov.au/publications/investigation_reports/2005/AAIR/aair200503722.aspx https://www.atsb.gov.au/publications/investigation_reports/2...
- madeofpalk 9y ago
  No, there was an incident several months later with QF71 flying the same route in the opposite direction. https://en.m.wikipedia.org/wiki/Qantas_Flight_72 https://en.m.wikipedia.org/wiki/Qantas_Flight_72 See the subheading in the Final Report section
  - madeofpalk 9y ago
    direct link: https://en.wikipedia.org/wiki/Qantas_Flight_72#Subsequent_Qantas_Flight_71_incident https://en.wikipedia.org/wiki/Qantas_Flight_72#Subsequent_Qa...

sceew 9y ago

Aren't we always going to have two pilots? a captain in case the computers fail, another in case the captain fails. Automation (airpilot) has already been around...?

outworlder 9y ago

> His reasoning is simple: how can the plane stall and over-speed at the same time? It can. It's called the "coffin corner".

noir_lord 9y ago
Hadn't heard of that, read the Wikipedia article, fascinating.
rzzzwilson 9y ago
I remember reading comments by a U-2 pilot that turns had to be very shallow at height due to the possibility of the inside wing stalling and/or the outside wing entering mach buffet. !
mikevin 9y ago
Link[1] for those who want to know more. [1] https://en.wikipedia.org/wiki/Coffin_corner_(aerodynamics) https://en.wikipedia.org/wiki/Coffin_corner_(aerodynamics)

amluto 9y ago

As I understand it, Boeing planes physically move the cockpit controls to reflect computer control inputs. Would that approach have made a difference in this event?

mjevans 9y ago
Maybe, surely more so if the pilots resisting that intended change in control were given priority. I very much like how the redundant sticks are /forced/ to stay in sync. What's done to one IS done to the other as well. That's a critical safety feature in the human interface. I think a complete human over-ride of 'higher level' functions (disable the auto-pilot) should require 'two keys' like in War Games (with the nuke silo). The lower level systems still have to exist, and there should be a way of troubleshooting (graphs probably) their inputs and outputs over time.
- hlandau 9y ago
  IIRC, Boeing 777s (which are FBW) will automatically disengage the autopilot if you start forcing the stick to a different position. The flight envelope protections are implemented by adding a physical resistance to the stick, but can be overridden by using force, which seems a highly intuitive and deferential implementation. It certainly seems a lot more responsible than Airbus's design, both for the above reasons and for the mechanical linkage you mention.

cbanek 9y ago

They mention it once in the article, but this has basically been true since fly-by-wire, which was quite a while ago. While it may seem timely to blame automation for this one, you could just as easily blame faulty sensors (like the iced up sensors they mention) or faulty mechanicals, such as pumps, hydraulics, wiring, electrical shorts, etc. The sad thing is, as we go faster (both in terms of speed and technology), things will only get more complex. We're also far past the point where human pilots and crew might be able to do something about it. Let's say it wasn't fly-by-wire, and it was hydraulics tied to the stick. If you lost power, you still probably wouldn't be able to move the stick, or it wouldn't do anything. Either way you are in deep trouble. The real solution is redundancy. They mention the triple flight computers in the Airbus, but in the end, there will always be possible problems of all types. In computers, there are also hardware (not software bugs) errors that may occur at any time. One of the things devs love to joke about is heisenbugs. If you have debugged these, and only found them on one machine, it's probably your memory doing a bit-flip. Solar radiation can do that, especially at higher altitudes. Just because we're behind our magnetic field doesn't make it go away, and at higher altitudes you do have a slightly higher error rate. Now we're just back to byzantine general territory where you have to figure out which one is lying. Again, coming down to probability that you didn't lose two at the same time. While it's easy to say that the system should have just done "the right thing" - when you learn more about how the system works, and how complicated it is, you realize how hard that is. And problems in handling errors or trouble are some of the hardest to find, and have the most damaging consequences. Spacecraft (manned or otherwise) have these exact same problems. (Source: I've worked on aerospace systems) https://en.wikipedia.org/wiki/Fly-by-wire https://en.wikipedia.org/wiki/Fly-by-wire

caf 9y ago
...you could just as easily blame faulty sensors... Well, no - faulty sensors are an inevitability, so the automation needs to be able to continue to function effectively in that eventuality. Which is, of course, a well-understood part of the design space.
- cbanek 9y ago
  Everything is an inevitability, that's the problem with the design space. We haven't yet invented some perfect machine that will handle everything. But there are functional and realistic limits to how well you can perform under certain failure scenarios. You might have to increase weight to add more sensors and wiring. That logic to reconcile more sensors will be more complex, and possibly prone to error itself. Added complexity against failure doesn't necessarily increase safety, as much as we always wish it would.

WalterBright 9y ago

> control over the horizontal tail – 3000 pounds per square inch of pressure that can be moved at the speed of light. Not quite. If I recall correctly the tail will move about 1/2 degree per second. Hardly the speed of light. The elevators are hydraulically operated and can go much faster, but hydraulics don't move at the speed of light, either. The 3000 psi refers to the hydraulic pressure in the system, which has kinda nothing to do with how fast things move. Boeing considered going to a higher pressure to save weight, but rejected the idea because a pinhole leak at such pressures would act like a knife on human skin. Source: I worked on the horizontal tail design of the 757.

PhantomGremlin 9y ago
Yeah, that particular sentence really grated on me. I also didn't like: Booooom. A crashing sound tears through the cabin. In a split second, the galley floor disappears beneath Maiava's feet, momentarily giving him a sense of floating in space. I initially thought there was some sort of structural failure of the cabin floor.
- WalterBright 9y ago
  Most articles written by journalists about technical issues read like the journalist took the facts and ran them through a Mixmaster before printing them. One nice anomaly is the "Aviation Disasters" TV series, which gets the tech right as far as I can tell.
GICodeWarrior 9y ago
The wording is technically imprecise in a number of places. The mechanical components certainly can't move at any significant fraction of c, but they may be referring to the electrical fly-by-wire signals controlling them. Still not precisely the speed of light, but close enough if that's what they meant.

wahern 9y ago

What I found most interesting was how unnerved the pilot (a bone fide Top Gun graduate) became by his newfound sense of lack of control. It ruined flying for him and effectively ended his career. I would have assumed that coming to terms with a lack of control was one of the first things a fighter pilot would have to learn to deal with. But maybe you can't be a good fighter pilot unless you can fool yourself into thinking you're always in control, and that lack of control is really just a personal failing (didn't train hard enough, not thinking clearly enough, etc). Or maybe with age you just lose the ability to handle that kind of stress. AFAIU the older you get the more likely you are to become overwhelmed by anxiety. Which seemed totally counterintuitive until I watched others get older--including myself--and saw how that works. I guess that was sort of the plot to Top Gun, too. ;)

pdonis 9y ago
> I would have assumed that coming to terms with a lack of control was one of the first things a fighter pilot would have to learn to deal with. I think it wasn't just the lack of control; it was the inability to do anything to regain control. My father was a test pilot; there were plenty of times where his airplane did something unexpected and he lost control. But he always had some option for regaining it. (In the last extremity, he could eject--which he actually had to in one test flight. I noticed that the lack of that option in an airliner was mentioned in the article.) Also, this was a situation where, as the pilot said, he could easily have kept control of the plane, if only the plane had let him. But the plane was listening to the computers instead of him. To me, if you're going to have highly trained humans in the cockpit, it doesn't make sense not to give them a last-dicth way of telling the airplane to stop listening to the computers and start listening to them.
- wahern 9y ago
  > there were plenty of times where his airplane did > something unexpected and he lost control. But he always > had some option for regaining it. (In the last extremity, > he could eject [....]) But that's not really a lack of control. In those cases you're merely being challenged to regain control of the aircraft. You just need to fight harder, think smarter, or exit. In any event you still have control (or at least a sense of control) over your life. I understand why this issue was so unnerving for the pilot. Heck, any passenger could sympathize: it's why flying can be so scary--total and complete lack of control; little to any knowledge about what's happening and why; you're completely at the mercy of somebody else, or nothing at all. So, yeah, I get it. I was just thinking that of all sorts of pilots, a fighter pilot would be the last to be unnerved by losing control; unnerved to the point of not wanting to fly anymore. a) Fighter jets are super powerful and super sophisticated and when something goes wrong there may not even be any time to regain control no matter your training or experience; you're always flying at that envelope where the unexpected can and often does happen, so I just assumed you invariably accept that you're flipping a coin every time you take-off. b) I presume combat is one of those things where you either resolve yourself to a lack of control or realize you're not able to cope and move on to something else (if you can, and assuming you can move on emotionally). But I guess I shouldn't presume a modern fighter pilot (esp. from the 1980s) to have experienced the same sort of peril as someone on the ground during a war. That said, I'm not trying to suggest he lost his mind or something. He responded appropriately in the moment. He was able to let his training and experience dictate his responses. He consciously understands that he was unnerved after the fact because of that lack of control, as opposed to not understanding those feelings and fears. I'm just surprised that those feelings (or at least their severity) were novel to him and changed his perception of flying, not that he was unnerved, per se.

contingencies 9y ago

This was already submitted and discussed at https://news.ycombinator.com/item?id=14336897 https://news.ycombinator.com/item?id=14336897 and https://news.ycombinator.com/item?id=14328294 https://news.ycombinator.com/item?id=14328294. My summary at https://news.ycombinator.com/item?id=14329082 https://news.ycombinator.com/item?id=14329082 is still the most in depth researched as far as I can tell (I actually read a lot of the air safety bureau report). Basically Northrup Grumman's ADIRU units had sporadic software bugs (off by one - typical of software written in needlessly low level languages) and the Airbus control system that combined the output of the three redundant ADIRUs didn't properly deal with the case of failure in one of the three (even if 2/3 agreed with GPS!), didn't provide transparent training and resolution procedures to pilots for this class of situation, and was generally trusting the broken unit instead of the other two or the GPS which were operating fine. Even calling the crisis center of the major airline for assistance on the ground couldn't help resolve the situation. So... problems in both companies, but Airbus is mostly to blame, even if testing could not be expected to tease out all bugs in third party components, primarily because they were not logging issues and resolving them from the millions of flight hours these things already had, and because they had not tested their fly-by-wire system with worst case input, ie. what's the point of redundancy if you trust the broken unit?

perilunar 9y ago
Also https://news.ycombinator.com/item?id=14330913 https://news.ycombinator.com/item?id=14330913
mathgenius 9y ago
After the Intel FDIV bug [1] they started using formal verification to make sure the cpu's did what they said they would. I don't understand why they don't do the same for these avionic systems. Maybe it's just not worth it to the company. [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
- flashmob 9y ago
  Would you say that this has limitations and it's not a silver bullet? Eg. What if your software added numbers, formal verification proved that your program was indeed correct because it added the numbers. However, it missed the requirement that you also had to do subtraction, which for some reason was omitted in the specification.

ptero 9y ago

This is unquestionably a very scary situation. Kudos to pilots who got the plane down without loss of life. However painful this state is (broken autopilot, no full human override) I suspect fly by wire actually prevents many more accidents than it causes.

DuckConference 9y ago

Don't the pilots have the option of engaging alternate flight rules in this case? Or is that not how it works?

boznz 9y ago

On the whole I would still prefer well tested software over a human anytime.

cmurf 9y ago

I am a pilot, and my complaint is not the lack of a last ditch emergency manual mode, but that there are numerous modes (or alternate laws) in the software abtraction of fly by wire aircraft, and the plane responds differently to inputs in these different modes, the notification for what mode the system is in has to be inferred, and the pilot is expected to know all of these things. I think it's hubris and incompetence in engineering that a system would be designed this way. And in fact not all of them have these same deficient behaviors, so this is not inherent to fly by wire or automation. It's a choice made by the software abstraction designers. The idea there'd be a mode where advancing a throttle literally does nothing, no increase in power nor a notification that the input received is sensed but isn't going to do what you think it should so that you have a clue in that some other mode is applied, is so totally batshit insane to me. It's a huge betrayal of physics of flight which is something pilots do understand rather well, almost like muscle memory. In a conventional plane, throttle advance always increases power. If that doesn't happen, it's an emergency. In a fly by wire plane if it doesn't happen, it almost certainly means the pilot is confused. And that to me is crap design.

Figs 9y ago

This story reminded me of the adage: "They say that to err is human, but to really fuck up, you need a computer..."

marze 9y ago

What a poor design. Pilots should have a hard "manual control" switch that turns control completely to the pilots. A friend of mine from childhood became a top expert in formal verification, and got a contract many years back to help Airbus perform formal verification on their control software. I don't know many details, but according to my friend's father, he would never fly on an Airbus jet after this experience. A pilot friend told a story of some pilot friends of his who were piloting an Airbus in Canada, many years back, who couldn't get the jet to give control back and get out of a holding pattern to land. They had to wake up engineers in France in the middle of the night, who told them to take a hammer to certain fuses or breakers, and let them regain control. From a UI point of view, the control system and displays in the Airbus are a disaster. For instance, the pilots in the Air France plane that stalled over the pacific couldn't figure out that the plane was stalled for several minutes before it was too late to correct, with all of the displays in front of them.

hlandau 9y ago
AFAIK there is such a switch: there are switches to disconnect the primary computers on the overhead panel. If those are disconnected, presumably the aeroplane reverts to direct law and flight envelope protections become inoperative. I might be mistaken though; I'm no pilot and you seem more knowledgable. The article mentions they were able to regain control of the plane by leaving one of the primary computers disabled. (The end of the article itself has a quote from Airbus suggesting there's always supposed to be a way to get full control; presumably this is what they're referring to.) I was surprised that they left the other computers enabled, especially given that the article suggests they were worried whether it would happen again; to me, the obvious thing would be to do would be to disable all primary computers and use direct law. Malfunction of the flight envelope protections seemed the obvious culprit from the moment it was mentioned the sticks were ignoring commands, short of a mechanical failure in the control surfaces themselves. Certainly AF447 has demonstrated that Airbus aircraft are very poorly designed from a user interface perspective. The anecdotes you have about people working at Airbus sound highly interesting and would be worthy of blog posts in themselves. Would your friend ever consider writing about these concerns (anonymously even)? Also, was an accident report ever filed for that holding pattern incident? Can I read about it?

Avalyst 9y ago

Reminds me of SK751 [1] where an automated system prevented the pilots from powering down a broken engine, resulting in both engines failing and the plane crash landing in a field north of Stockholm. [1] https://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_751 https://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_7...