back to article Boeing 737 pilots battled confused safety system that plunged aircraft to their deaths – black box

With investigations continuing into the cause of Lion Air flight 610's deadly crash into the Java Sea, experts are scrutinizing the plane's automated control system. Early data from the doomed plane's flight recorder suggests that for much of its 11-minute flight on October 29, the pilots were struggling with the craft's …

  1. disk iops
    FAIL

    Hey software, get the fuck out of the way!

    The pilots are either competent or they aren't. there is NO reason whatsoever for software written by blithering idiots to override and countermand the pilot. He is GOD. If he is an imperfect, distracted, negligent god, then sucks to be you for the passengers but this was a clear case of software elevating itself above the meat.

    Programmers, fuck off! Sensors are fallable - it's fine to chime and red light, even buzz/alarm when something sure looks wrong but do NOT interfere.

  2. Remy Redert

    Re: Hey software, get the fuck out of the way!

    But this wasn't the software's fault. It never is. It was the designer who allowed a single faulty sensor to put the software into a dangerous state. This is an aircraft control system and it should have existed at least in duplicate, with multiple separate sensor inputs to insure that the system is always right and that if a situation ever comes to pass where it cannot be certain it is right, then it will cede control completely to the pilots

  3. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    It looks like Boeing has started to ape Airbus in that the computer has the ultimate say when it comes to the flight controls. The logic is that on average computers make less mistakes than humans. Unfortunately this line of reasoning fails to take into account of the fact that all software contains bugs because it's written by humans.

  4. Marketing Hack Silver badge
    IT Angle

    Re: Hey software, get the fuck out of the way!

    It's a very bad idea to have software making decisions based on the output of a single sensor. Didn't we learn that several years ago when the pitot tubes on that Airbus airliner out of Brazil iced up and that caused the plane to assume that it was stalling, and that forced a crash into the South Atlantic with no survivors?

    If you are going to give software the ability to countermand the flight crew, then you need to have fault-tolerant redundant sensing systems in place to make sure that the systems on the plane have accurate information. Otherwise you arrive at the horrific logical end of "garbage in, garbage out".

  5. Remy Redert

    Re: Hey software, get the fuck out of the way!

    That was an Airbus and the software reacted correctly. It decided that the airspeed information it was getting from the various sensors was conflicting, so it switched from normal law (where it controls the airplane and the pilots are allowed to tell it where to go) to alternate law 2 (aka "I don't know any more, you're up pilots").

    The pilots then proceeded to over-correct for a slight roll caused by the autopilot switching off, pulled the nose up, got a brief stall warning when the angle of attack sensors indicated something was up and then proceeded to put the plane into a stall so deep the computer considered the measurements of the alpha sensors to be impossible, so it did nothing and assumed the pilots were doing the right thing.

    The software (and software designers) in this case did everything right and the pilots proceeded to crash the plane. Had the system switched back to normal law when the airspeed readings came back (about a minute after the failure, but before the stall), the airplane would never have stalled. But because of safety reasons, the pilots would have had to switch the plane back into normal mode themselves once they verified the problem that triggered the switch had been resolved.

  6. Updraft102 Silver badge

    Re: Hey software, get the fuck out of the way!

    Until this incident, I would have said that's why I like Boeing more than Airbus. Boeing's philosophy was supposed to be as you say... assist the pilot, but never usurp his authority. The Airbus philosophy is that since pilot error is a/the cause of most crashes, it's going to overrule the pilot if it thinks he is in error. This incident seems an example of the Airbus philosophy, not the supposed Boeing one.

  7. Denarius Silver badge

    Re: Hey software, get the fuck out of the way!

    Re Airbus crash south Atlantic. AFAIRC from chats around airfields and a few public documents this incident also showed defects in pilot flight currency in directly handling aircraft. Similar incidents had happened to other airlines whose crews flew recreationally. Those crews looked at all instrument data such as indicated airspeed, angle of attack and engine power settings. They correctly concluded airspeed data was wildly wrong and flew their aircraft accordingly. Airbus were notified of the airspeed pitot tendency to ice up. In the crash incident the crew failed to realise a full stall happening because of a strong belief in all IFR pilots that one trusts instruments ahead of anything else, thus failing to assess all data.

    If Boeing has drunk its version of AI KoolAid in it control system, then I will have to think about seaborne travel more positively.

  8. eldakka Silver badge

    Re: Hey software, get the fuck out of the way!

    The Airbus philosophy is that since pilot error is a/the cause of most crashes, it's going to overrule the pilot if it thinks he is in error.

    In the case cited above, the Airbus aircraft recognised it had no idea what was happening, so it gave full control to the pilots, it did not overrule the pilots. Therefore Airbus does recognise that it may, at times, be best to leave it to the pilots. It's default mode is to stop the pilots from doing anything stupid (too tight a turn, to steep a climb/dive, etc.) but that can be disabled by either circumstances where the aircraft recognises that it's got NFI, or by manually switching to alternate law 2.

    I believe (from memory, could be wrong) the issue was multi-fold:

    1) confusing and contradictory indicators;

    2) issues with cockpit layout and information feed to pilots (e.g. alarms being set off by angle-of-attack sensors, but that information, the angle-of-attack, not being available on pilot instrumentation);

    3) that each sidestick was independent of the other, so that one pilot doesn't know what position the other pilot has their sidestick in, resulting in the 2 pilots providing conflicting control input, but neither of them knowing what the other was doing to know that there was conflicting control input.

    4) management issues, whereby clear, concise instructions weren't being given and/or followed by all pilots, e.g. why wasn't it made clear that the pilot in the right-hand seat was now in control and the pilot in the left-hand seat must remove their hands from the flight controls (sidestick) to prevent contradictory control input (tho the fact that this was happening should have been reported by the aircraft, e.g. mechanically (or electrically/haptic-feedback-type) link the 2 sticks).

    It really had nothing to do with the software overruling the pilots. There were many other issues with Airbus's software and cockpit layout/information feed to the pilots, but overruling the pilots wasn't one of them in this case.

  9. Malcolm Weir Silver badge

    Re: Hey software, get the fuck out of the way!

    Actually, the issue here is that the pilots were not properly trained on the MCAS -- Boeing added that system to the 737MAX but didn't make a big deal about it (or indeed any deal about it) -- so much so that other 737MAX pilot groups are furious! That's "furious" as in writing letters to the FAA about it... The three big unions representing 737 operators in the US (Southwest, American and United) have all responded with anger towards Boeing.

    The issue is that *if* you know about MCAS, you can defeat it's "help". If you don't, you have no idea why your airplane is constantly trying to put it's nose down.

    All indications are that Lion Air's pilots (and those of Southwest, American and United) did not know, and have not been trained on or practiced with MCAS, let alone MCAS failure modes.

  10. sanmigueelbeer Silver badge

    Re: Hey software, get the fuck out of the way!

    It was the designer who allowed a single faulty sensor to put the software into a dangerous state.

    Go HERE.

    Look at the two lines for the Angle of Attack (AoA) sensors. One is for the left and one is for the right. Notice that the lines are separated? At any given time, the AoA sensors should never be separate. They're meant to be redundant so the readings are meant to be the same.

    There are actually two faults to this unfortunate events, they are:

    1. One of the Angle of Attack sensor was faulty. The AoA sensor feeds information to the FMS and one of the systems, MCAS, reads from this.

    2. The MCAS was an "undocumented feature" introduced by Boeing which a lot of airlines were not familiar of.

    For unknown reason, after take-off the MCAS was reading to input from the AoA sensor and immediately took action for the one that had the worst reading. For the next few minutes, the both pilots were battling with the MCAS to keep the plane from crashing until it was no longer possible.

    It's a very bad idea to have software making decisions based on the output of a single sensor.

    Imagine you flying at night across ocean and into a thunderstorm. It is very hard to determine which way is up or down or what angle is the plane's nose pointed. This is what the MCAS, with the help of the AoA, is meant to do.

    But the root cause to the crash was a faulty AoA sensor. The fault of the two pilots was that they were unaware of the MCAS and they were unable to disable it. With previous flight, one of the flight crew disabled the MCAS and was able to gain control of the a/c.

  11. David Leigh 1

    Re: Hey software, get the fuck out of the way!

    ddfsdfd

  12. David Leigh 1

    Re: Hey software, get the fuck out of the way!

    FYI pitots = HARDWARE, not SOFTWARE.

  13. Neil Barnes Silver badge

    Re: Hey software, get the fuck out of the way!

    I rather think the biggest error on AF447 was the two pilots not knowing what each was doing; one of those sticks should have overridden the other (I don't claim to know how to implement this!)

    I'm glad I was on that plane on its flight down to Brazil and not the return flight that night...

  14. Andre Carneiro

    Re: Hey software, get the fuck out of the way!

    Whenever the two side stick receive a command, there is a very loud DUAL INPUT aural and visual warning on the FMA.

    The end result of the command to the plane is the sum of the vectors of both inputs (so a full “pitch down” input would effectively nullify a “full pitch up input”).

    Moreover, there is a SidestIck Priority button which, when pressed, disables the other one, gives a loud PRIORITY LEFT/RIGHT aural warning and a visual warning on the console of the pilot who lost priority. This is in case a stick fails and starts sending weird inputs.

  15. Andre Carneiro

    Re: Hey software, get the fuck out of the way!

    Also.... The issue with that particular AF flight was multifactorial (as these things often are) and started before the actual event (as these things often do).

    In a very very quick summary, there were significant training issues. Losing Air Data at high altitude is serious but it's fairly trivial to maintain level flight using Thrust and Attitude (pitch up measurement) alone. There are tables for that in the manual: ""For this thrust, at this weight, with this pitch, this plane will fly at approximately this altitude and continue doing so").

    The choice of route (straight through a thunderstorm from which other planes had deviated) was probably a determinant factor and indicated the complacency of the pilots and the over confidence in the superiority of the technology (the last point being driven home by the fact that the copilot had a full nose up input on the stick for most of the incident which is a schoolboy error when dealing with a stall, because he assumed the alpha-protections would keep the plane from stalling). That the Captain was absent from the flight deck when the plane entered the storm cell again may suggest complacency or a lack of awareness of the risk.

    It was all very sad and it is easy to analyse with the retrospectoscope but ultimately the software did exactly what it should do and the plane should not have come down.

    Then again I wasn't there and the barrage of inconsistent warnings and failures would probably have overwhelmed me as well.

  16. Graham Triggs

    Re: Hey software, get the fuck out of the way!

    Whilst I would agree that this is probably a system too far, maybe your anger is a little misplaced.

    It's not the programmers who thought they were god.

    It's not the programmers who decided to have this system.

    The programmers have simply done their job to implement a protection routine based on the inputs that it is given. And in all likelihood it is the data rather than the algorithm that generated the problem.

    That they did, that the system was installed in the aircraft is a management decision.

  17. Voland's right hand Silver badge

    Re: Hey software, get the fuck out of the way!

    I am sorry Dave, I am afraid I can't do that.

    On a more serious note, "Switch to Manual" should mean "Switch to F*cking Manual".

  18. Graham Triggs

    Re: Hey software, get the fuck out of the way!

    "Until this incident, I would have said that's why I like Boeing more than Airbus. Boeing's philosophy was supposed to be as you say... assist the pilot, but never usurp his authority. The Airbus philosophy is that since pilot error is a/the cause of most crashes, it's going to overrule the pilot if it thinks he is in error. This incident seems an example of the Airbus philosophy, not the supposed Boeing one."

    I may be wrong here, but my impression is that even with Airbus, it is human part that causes virtually all failures. Admittedly, sometimes that is down to bad interface design, where the human thinks they are doing one thing, but are actually telling the software something else.

    And whilst we could say that because this incident was caused by a faulty sensor, and that a faulty sensor should not be allowed to override a pilot's input, pilots are still depending on what the plane is telling them. If the software can get bad data, so can the pilot - and there are crashes where the pilot has been given the wrong altitude, airspeed, etc.

    We have to be realistic here - the software is pretty reliable within its operating parameters. And some of the cases where a pilot might be able to react on instinct, e.g. flying in bad weather, maybe there could be better decisions to be made to not put a plane in that kind of risk.

    Whilst we worry about the reliability of the software, think of the incidents that could be prevented. If you can (mostly) rely on a plane flying and landing itself, detecting and avoiding any obstructions, you can afford to lock the controls to the biometrics of the pilots prior to take-off, knowing that if anything happens to them - or simply there is a failure to read the biometrics - it is the plane that will get itself to safety It would significantly impact the possibilities for hijackers.

    But however good the software can be, pilots are necessary. Maybe the unexpected situation is unavoidable. Maybe you are running low on fuel and need to land at an airport where guidance systems for an automated landing are malfunctioning. You need a human element to deal with passenger emergencies. With 100s of people on board, you need to cover these possibilities.

  19. MacroRodent Silver badge

    Re: Hey software, get the fuck out of the way!

    Sounds like that angle of attack sensor should be triplicated. How else can the software decide which sensor is bad, if both produce plausible values (one being wrong, but not impossibly so).

    - And the same for goes for all other safety-critical sensors.

  20. Prst. V.Jeltz Silver badge

    Re: Hey software, get the fuck out of the way! Can it?

    What does "Switch to Manual!!" actually mean?

    Is it possible for software to "Get the fuck out the way?"

    It isnt on my car - a 28 year old sports car - it still has a little computer running software deciding how much fuel to put in and which / when spark plug to fire , and when it fucks up , as it has a few times locomotion ceases.

    My cay at least has a throttle cable - most dont these days , and neither do these planes.

  21. rg287

    Re: Hey software, get the fuck out of the way!

    In the case cited above, the Airbus aircraft recognised it had no idea what was happening, so it gave full control to the pilots, it did not overrule the pilots.

    Yeah, AF447 saw a significant chain reaction of errors, some down to human factors, some down to cockpit design. It really epitomises that complex systems can fail in complex ways, even when sparked off by a seemingly simple root fault (like a pitot tube icing over).

    - The autopilot correctly realised it was getting unreliable data and correctly switched to alternate law.

    - The co-pilot had lost situational awareness and thought they were in a dive, pitching up and placing the aircraft into a stall.

    - The pilot attempted to correct the stall condition, but this was where a combination of human factor and cockpit design created a fatal error condition.

    1. Cockpit cooperation and communication broke down - the pilot was unaware that the copilot was trying to correct what they perceived as a dive condition

    2. Because the airbus sidesticks are not mechanically linked and there was apparently inadequate indication of conflicting inputs, the pilot was unable to perceive this from his controls and did not understand that this was the reason why the aircraft was failing to react to a nose-down input on his stick.

    On a Boeing, the linked yokes would have led to at least one half of the cockpit asking "WTF are you doing?" to the other because they would have been physically fighting against each other.

    Ironically, an MCAS system (separate to the autopilot, which had already quit) may also have prevented the co-pilot pitching up into a hard stall condition.

  22. rg287

    Re: Hey software, get the fuck out of the way!

    I rather think the biggest error on AF447 was the two pilots not knowing what each was doing; one of those sticks should have overridden the other (I don't claim to know how to implement this!)

    The main thing is not to override (though there is a feature for one stick to take priority in the event a stick goes faulty) but to warn when dual, conflicting inputs are received.

    Boeing does this with linked yokes - if the other side of the cockpit is pushing forward, you'll receive physical tactile feedback of that if you're trying to pull back. The Airbus sticks do not provide linked force feedback.

  23. zaax

    Re: Hey software, get the fuck out of the way!

    Is that not what the artificial horizon is for?

  24. Destroy All Monsters Silver badge
    WTF?

    Re: Hey software, get the fuck out of the way!

    Programmers, fuck off!

    Someone in here has no clue how such systems are designed, implemented and rolled out.

    Get to Amazon and read books.

  25. error 13

    Re: Hey software, get the fuck out of the way!

    I believe there is a rather simple system for this - each stick has a red button called something like priority control. Push it and hold it and you get exclusive control. Why the captain didn't push the button will forever be a mystery

  26. Symon Silver badge
    Coat

    Re: Hey software, get the fuck out of the way!

    Re Denarius :- "I will have to think about seaborne travel more positively."

    https://www.dw.com/en/why-are-ferry-accidents-common-in-indonesia/a-44403800

    I think you'll find that you're better off avoiding travelling in Indonesia. Altogether.

    p.s. https://youtu.be/0wxp-NxJny8?t=81

  27. SW10

    Re: Hey software, get the fuck out of the way!

    Looks like your aircraft is stalling. Would you like some help?

    [ Yes ] [Cancel]

  28. dvvdvv

    Re: Hey software, get the fuck out of the way!

    Multiple redundant do fail, too. In one prominent case, two of the three AOA sensors failed on an A321, which made the safety system to ignore the only sensor that was working and trim the airplane into a dive. The correct mitigating action was to disable the misbehaving system, and that was exactly what the crew of that A321 did. And that's what the crew of the penultimate fight of the crashed Boeing did, too. Everybody lived.

  29. dvvdvv

    Re: Hey software, get the fuck out of the way!

    Bullshit. The pilot always has the ultimate say, be it Airbus or Boeing.

  30. dvvdvv

    Re: Hey software, get the fuck out of the way!

    Another bullshit. The software didn't force AF447 into the ocean — the software correctly detected that it couldn't make decisions based on the malfunctioning sensors and put itself out of the loop, making it very clear to the pilots. It was the pilots who dropped the plane into the ocean.

  31. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    "But this wasn't the software's fault. It never is. It was the designer who allowed a single faulty sensor to put the software into a dangerous state."

    Having worked on safety critical systems - we developed state machines to identify, pretty much, every possible output . This safety system should have had redundancy and additional sensors to check.

  32. tim 13

    Re: Hey software, get the fuck out of the way!

    What happens if they both press it?

  33. I ain't Spartacus Gold badge

    Re: Hey software, get the fuck out of the way!

    As I understand it the two-inputs alarm did ring. But the pilots were too distracted by other alarms to notice. I think too many designers forget how much information the human can take in, and put too much on screens. It's still easier to read an analogue altitude dial quickly than a digital one - I think because the analogue one is effectively a picture - whereas you have to process the numbers and think about them with a digital one.

    The same is true with the sidesticks. Why have a buzzer and a warning to tell you that someone else has hands one. It's fine in normal flight, but what if all brain cells are currently busy processing other warning data? At that point the physical action of having the stick pulling in another direction is telling you directly what's going on. Simplicity is best.

    Remember that Quantas A380 that went all roller-coaster a few years ago, and kept going through multi-thousand foot dives and climbs? The crew had to put the plane into one of the more manual flight modes to correct it. I think the copilot had something like 1,000 warning messages in 5 minutes. No human can take in that data. He spent the first minute or two just scrolling through his screen acknowledging warning bells to shut them up and there was no way to work through that much info to come to any diagnosis of the problem.

    You can train pilots in sims to take in more data, but I'm always struck by those Air Crash documentaries just how many alarms the pilots are subjected to. And they're distracting. Once confusion sets in I feel they actually make recovering from the confusion harder - even where there might actually be time.

  34. defiler Silver badge

    Re: Hey software, get the fuck out of the way!

    What happens if they both press it?

    I'd like to hope that the Captain has priority then. After all, it's the Captain's aircraft. Which seat the Captain sits in can vary between airlines, but once the plane is set up for an airline it shouldn't need changed until it changes hands.

    That's how I would do it, anyway... All opinion. I'm the guy sitting in the back.

  35. e_is_real_i_isnt

    Re: Hey software, get the fuck out of the way!

    The worst part was that the Airbus also silenced the stall warning when the AoA was out of range high - this caused the co-pilot to pull back on the stick whenever the nose came down, because that shut off the stall warning that would return when the AoA came back within range.

  36. dvvdvv

    Re: Hey software, get the fuck out of the way!

    You don't really need any special MCAS training — a runaway trim is a runaway trim no matter what the cause is. And dealing with a runaway trim is a well-established and relatively simple procedure.

  37. TomChaton

    Re: Hey software, get the fuck out of the way!

    "Programmers, fuck off!"

    You first.

    We'll be right behind you on Ark Fleet Ship C.

  38. ridley

    Re: Hey software, get the fuck out of the way!

    IIRC one of the sticks DID override the other. The co-pilot was pulling back on the stick the whole way down from 35000+ feet until they nearly hit the sea, but by then it was too late.

    https://www.youtube.com/watch?v=XAom93qwoN0

    Watch 42 minutes in.

  39. Someone Else Silver badge
    Facepalm

    Re: Hey software, get the fuck out of the way!

    If you are going to give software the ability to countermand the flight crew, then you need to have fault-tolerant redundant sensing systems in place to make sure that the systems on the plane have accurate information.

    Or... you simply do not give the software the ability to irrevocably countermand the flight crew. Period.

  40. nariman
    Boffin

    Re: Hey software, get the fuck out of the way!

    Yes, quite.

    I mean, I haven't worked in safety critical systems design, just kernel software and real-time systems in general, but one of the first questions during say a design review for a safety critical system might be "what if the inputs are total rubbish".

    I mean we go to such extreme lengths for web forms.

    If a subsystem has the capability to override the pilot and cause death (i.e. nosedive the plane, which seems to be the primary purpose of the sytem, in effect) then surely it has to be n-modular redundant and voting and all that high brow aerospace/aviation gubbins?

    No?

    So reawakening some of my degree from a long lost part of my brain it seems like the IEC 61508 standard has an automotive flavour "ISO_26262" (which I am using here to prove that there is at least a pretty obvious step at which this should have been identified as an issue). Clearly the aviation standards will be more exacting (right?).

    https://en.wikipedia.org/wiki/ISO_26262#Parts_3-7:_Safety_Life_Cycle

    Bullet point number two (after "identify the item and its requirements"):

    "A comprehensive set of hazardous events are identified for the item."

    Is "bogus input from a single sensor with no validation" not a "hazardous event" given that the direct consequence is nosediving?

    Hindisight etc. Icon for sarcasm.

  41. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    "there is NO reason whatsoever for software written by blithering idiots to override and countermand the pilot."

    The problem is a little more subtle than a lot of news articles are spewing (and it's that sublety that made it so deadly.)

    The software never "overrode" the pilots. MCAS is designed as an assist. It trimmed nose down at an inappropriate time, certainly, due to a bad sensor. But the pilots were able to trim the nose back up easily. In fact, MCAS gets "out of the way" as soon as a pilot makes a trim adjustment and stays out of the way... for five seconds. Then it tries again. It's trying to help.

    The tragic flight was a game of back-and-forth. MCAS trimmed down. Pilot trimmed up. Wait five seconds. Repeat 20+ times. Then, for some reason, they didn't. MCAS served the ball, but the pilots didn't return it. We don't know why.

    The pilots could have disabled all electric trim and adjusted it with the manual trim wheels. This is exactly what the previous flight on this exact airplane did. We still don't know why these pilots didn't do that.

    The condition they faced is called a "runaway stabilizer" and turning off electric trim is part of the checklist on how to deal with it. The issue is that a typical runaway stabilizer is *continuous*, but MCAS does that whole "wait 5 seconds" bit which was undoubtedly confusing. There's still a lot of missing information here.

  42. Ian Johnston Silver badge

    Re: Hey software, get the fuck out of the way!

    The AoA reading seem near identical until the final dive and crash. Was the plane spinning then? Once there is significant side slip, all bets about equal ... well, anything, really ... on both sides are off.

  43. Andre Carneiro

    Re: Hey software, get the fuck out of the way!

    If they both press it, whomever pressed it last will have the side stick priority.

    If the priority button remains pressed for more than 45 seconds, then the other stick will he disabled for the remainder of the flight.

  44. Daniel 18

    Re: Hey software, get the fuck out of the way!

    "The worst part was that the Airbus also silenced the stall warning when the AoA was out of range high - this caused the co-pilot to pull back on the stick whenever the nose came down, because that shut off the stall warning that would return when the AoA came back within range."

    More irony here. The system was designed to avoid information overload by muting bad or irrelevant data - and the pilot was misinterpreting that.

  45. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    "Or... you simply do not give the software the ability to irrevocably countermand the flight crew. Period."

    Unfortunately, I've read quite a few air accident reports where investigators concluded that one way the aircraft could have been saved was to have turned control back over to the autopilot.

  46. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    If the priority button remains pressed for more than 45 seconds, then the other stick will he disabled for the remainder of the flight.

    -----------------------------------------------------------------------------------------------------------

    That's not good.

  47. eldakka Silver badge
    WTF?

    Re: Hey software, get the fuck out of the way!

    Look at the two lines for the Angle of Attack (AoA) sensors. One is for the left and one is for the right. Notice that the lines are separated? At any given time, the AoA sensors should never be separate. They're meant to be redundant so the readings are meant to be the same.

    You can't really have an effective redundant system with only 2 lines, you need 3. If one sensor fails with 2 lines, then which one is the faulty one? You can't reliably identify a single-sensor failure if you only have 2 sensors. With 3, you can detect a single-sensor failure. Of course, 2 sensor failures are then possible, but the chances of that are orders of magnitude less than single-sensor failures, and the sort of thing that'd make 2 (or more), widely-dispersed sensors fail is likely to be fatal to the aircraft anyway.

    Any critical sensor systems should be triply redundant, not dual, at least in larger (bigger than dash-8's) passenger aircraft. After all, we are talking about more than a hundred lives (more than 500 in the largest aircraft models) per aircraft in these cases.

  48. Anonymous Coward
    Anonymous Coward

    Re: Hey software, get the fuck out of the way!

    I have heard the various official and unofficial reports about the Air France crash, and I I am not a conspiracy theorist however I suggest that the pitot tube icing was a cause of the incorrect instrumentation reading, and that the icing was picked up by flying too close to a thunderhead...which as you get closer to the equator can top out as high as 60,000 feet.

    The airplane 'pancaked in' as the result of hitting the water in a flat spin, the spin resulting from a stall. Not having flown an Airbus 340 or 350, I can't say what the pilot assisted procedure is to recover from a spin, but it would require the fully committed action of someone who had considerable flying ability and experience and knowledge of the state of the aircraft and could apply it within a 3 and 1/2 minute descent window from the point of recognition. There is no glide in a spin and a recovery would likely have taken 10,000 feet of altitude or more for spin recovery and required full power with the aircraft pointed nose down in order for the aircraft to begin flying again which would have consumed additional precious altitude at a faster rate than terminal velocity.

    The captain was returning from Brazil with his wife onboard and was not at the controls or on the flight deck when the plane encountered the icing (icing, which is a manageable occurrence). The left seat pilot was an experienced 'type' pilot with almost no experience flying through the horsey latitudes while the right seat had a new pilot to 'type' with many hours flying trans-equatorial. It was a moonless night, with no visual reference (over water), and the non-equatorial pilot flew too close to a thunderhead he was avoiding which led to the icing. Normally you would fly around the thunderheads guided by visual reference or radar, with equatorial thunderheads being of the type that have unique characteristics because of their sheer height. The right seat pilot would have had the knowledge of this uniqueness however he was not the pilot in command.

    These planes are built to be able to fly into and through rough weather but for some reason the icing was unexpected.

    The captain arrived on the flightdeck at some point in the 'enter into stall', 'stall', or entry into the spin (he detected an unusual change in aircraft or engine pitch perhaps, the remnants of the autopilot system before kicking over to manual).

    A spin without visual reference doesn't feel much different than straight and level flight although the electrical based systems such as the INS would have been reflecting the mayhem and toppling. No one was in a position to confidently summarize and positively control the aircraft to exit the spin by deploying spoilers, landing gear, or a hard counter rudder while pushing the nose over applying full power to attempt to get the lift required for the machine to start flying because none of the crew were in the right places, or had the right experience to be sitting where they were sitting.

    I hear this flight referenced all the time for the published reasons in this string. IMHO this was an organizational error (on duty captains flying with their spouses) on overnight flights especially when crossing the horsey latitudes, the bad luck of that combination of skills and experience (or lack of experience) on the flight deck at that stage of the flight, a dark and moonless night flying over water not providing any visual reference, and an iced pitot tube which delayed and prevented any present pilot from recognizing the actual state of flight and taking decisive action to stop the spin was the real cause.

    While I agree that the software on the Java Air flight was faulty or interpreting faulty data, the 737 Max does differ from the other 737 series probably due to the need to monitor lift (angle of attack) more carefully due to the length of the longitudinal axis, weight capacity and probably ooth. What this means is that an experienced pilot on type would have to have learned about the critical differences between this model and the rest of the 737 models, and learn about the unique recovery procedures (pull the fuse) of the Max.

    The pilots should have been forced to learn about the new procedure and been given the information of the critical-ality of the angle of attack on this model. It has not been determined whether or not this took place.

    Pulling a fuse to save an aircraft and the souls on-board does seem pretty Mickey Mouse though.

    The first thing which I thought of when I heard the report of the crash, although the poor maintenance record of the airline formed the bulk of the initial news article's reason for the crash, was the potential failure of a Neo engine which is an available power plant on this aircraft. This is a new aircraft jet engine which uses a gearing system in order to move a greater number of very thin fan blades at a higher rate of speed using less fuel (per pound of thrust). There have been problems with this engine but when it works it provides an relative economic panacea for the airline.

    A safe angle of attack is achieved (and determined) by airflow which is a function of thrust when taking off, climbing and at altitude, and a function of altitude when descending. Maybe the size and weight of the aircraft precipitated the systems modification, maybe the new engine, but in any event this system was new, critical, and persistent.

    IMHO no aircraft of this type should crash at 800 hours without any reason short of sabotage. The reason for the unfortunate crash may turn out to be attributed to a combination of mechanical and pilot error with a contributing factor being poor maintenance practices. It is a certainty that Boeing will change the responsible hardware and software system quietly over time.

  49. Steve Channell

    Re: Hey software, get the fuck out of the way!

    There Is a simple procedure that works in this case: throttle out (foot on the gas). Pilots don't like throttling out because it uses lots of fuel and causes stress on the engines... All of Which is recorded for performance review.

  50. Andre Carneiro

    Re: Hey software, get the fuck out of the way!

    “If the priority button remains pressed for more than 45 seconds, then the other stick will he disabled for the remainder of the flight.

    -----------------------------------------------------------------------------------------------------------

    That's not good.”

    Why not?

    If you have a faulty stick it makes sense to disable it rather than constantly taking priority every few seconds and risk an unexpected random input at a critical time, IMHO.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018