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 …

Page:

  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.

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

      1. sanmigueelbeer

        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.

        1. MacroRodent

          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.

          1. Andre Carneiro

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

            Yes, I’m somewhat perplexed by the lack of a “tie breaker”.

            Again, comparing with the Airbus implementation:

            The Airbus aircraft generally have 3 ADIRUs (Air Data and Inertial Referencing Units), each with its own AoA sensor. And yes, there is a voting system so that a rogue sensor will merely cause a DISAGREE state and is disregarded, rather than something potentially rather more catastrophic.

        2. zaax

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

          Is that not what the artificial horizon is for?

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

        4. eldakka
          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.

          1. Alan Brown Silver badge

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

            "You can't really have an effective redundant system with only 2 lines, you need 3"

            AT LEAST 3 and preferably an odd number, if not prime.

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

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

      4. MrXavia

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

        Surely should have the inputs & processing in triplicate for something like this?

        And there should be an easy way to override it, I mean something clear like a big red covered flip switch that can be turned off!

        Single sensors are fine for toys, but not for a plane carrying passengers!

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

      1. Anonymous Coward
        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".

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

          1. Denarius

            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.

            1. This post has been deleted by its author

              1. Alan Brown Silver badge

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

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

                Not just Indonesia. I wasn't happy to notice that the Plimsoll line had been adjusted several feet upwards on most ferries I used in the Philippines.

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

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

          3. lowwall

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

            You are missing a critical point.

            There were three pilots (one was the original captain who had been recalled from his rest period when the trouble started). Two of the pilots realized what was going on. And one of those pilots did realize what was happening and made the correct (forward) movement with his joystick to lower the nose. But the other pilot's stick was actually controlling. The Airbus controls are fully fly by wire and give no feedback, including no indication that the pilots are making conflicting inputs. The only way to tell there is a conflict is to actually look over at what the other pilot is doing and everyone was too distracted by the aural warnings and odd data coming from the displays. This was the last link in the chain that doomed the flight.

            Here's the last words from the CVR:

            02:13:40 (Bonin) “But I’ve had the stick back the whole time!”

            02:13:42 (Dubois) “No, no, no… Don’t climb… no, no.”

            02:13:43 (Robert) “Descend… Give me the controls… Give me the controls!”

          4. hayseed

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

            Actually, the Airbus ceded control to the pilots, but it averaged input from the pilot and the copilot. The pilot knew what he was doing, the copilot didn't and kept yelling something about "touch-and-go" - but at the heights they were at, there is much less lift, and one does NOT tilt up the plane like in a landing exercise like at sealevel.

        2. David Leigh 1

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

          ddfsdfd

        3. David Leigh 1

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

          FYI pitots = HARDWARE, not SOFTWARE.

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

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

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

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

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

              1. tim 13

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

                What happens if they both press it?

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

                  1. N.

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

                    My recollection is that the pilots were not fighting over the control of the plane. The captain put the younger pilot in charge before going to bed. When the Pitot probes froze, this pilot set the plane in a steep climb, as the book recommended, but without informing his colleague. The plane stalled. At an altitude of 600 m, he told his colleague about what he was doing for the last five minutes or so. The more experienced pilot understood immediately what was happening ; he took over and set the plane in a dive. Near the water surface, the younger pilot got scared and battled with his colleague for control. It was too late, anyway.

                    That is what I remember from reading the investigation report ; I might be wrong.

                2. defiler

                  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.

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

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

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

                3. ITS Retired
                  Holmes

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

                  Set it up so who every made the red button make its contacts connect first, has control. If they can do similar on game shows, they can do this in multi-million $$$ passengers planes, too.

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

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

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

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

      2. dvvdvv

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

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

      3. Alan Brown Silver badge

        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 difference is that the airbus is an aerodynamically _stable_ design.

        The 737MAX has pushed the 737 design out from aerodynamically stable (the originals and turbofans out to the 1990s - when trimmed, pilots only need to touch the controls occasionally to nudge the aircraft back on course when flying "straight and level") to neutral (1990s to now) and into "unstable" territory - (pilot or computer needs to constantly fly the aircraft to keep it straight and level - fighter jets are an extreme example of this kind of thing)

        Instability should never be allowed in a civil transport and the MAX should not be allowed in the air. There are a bunch of questions that need to be asked of the FAA's approval processes and why a 50-year-old design has been allowed to be progressively modified to the point where it's become inherently unstable whilst retaining the basic type approval.

        I suspect this is going to be an example used in textbooks in future.

      4. Fursty Ferret

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

        Regarding Boeing apeing Airbus here...

        There are some fundamental differences.

        1. Airbus uses voted data from three or more sources. A single source fault will be automatically excluded, often with only a maintenance message after landing.

        2. Because of the fly by wire nature you will never find yourself at the limit of your strength. This hugely increases capacity for decision making.

        3. In the event of two simultaneously faulty air data sources, Airbus publish a simple and quick procedure to remove the flight control protections. It's two buttons.

        4. They are also aware of a single faulty AoA vane triggering a stall warning at lift off, and all pilots know the memory actions associated with it (TOGA power, maintain pitch 15 degrees).

        The first crew of this 787 that continued the flight actually demonstrated almost perfect decision making. So one of the stick shakers was going off. The situation was carefully evaluated, a clear risk assessment was made and the safe outcome of the flight was never in doubt.

    3. Updraft102

      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.

      1. eldakka

        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.

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

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

          1. Anonymous Coward
            Anonymous Coward

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

            Your excellent writeup covers lots of important things but seems to miss one important fact re pitot tube icing: in the case of the loss of AF447 and all on board, there were pitot tube icing issues already identified and various remedial programs were in progress, but its importance hadn't been fully recognised, and combined with various other unrelated failures, it led to the loss of AF447 and all on board:

            https://en.wikipedia.org/wiki/Air_France_Flight_447

            Article includes links to the original definitive history, showing that the "must never happen" state of two identically failed pitot tubes outvoting the one good pitot tube had been a worryingly frequent occurence over a few years, but in general, some other part of the picture had prevented a "must never happen" failure becoming a disaster.

            When all the failures and omissions line up together like holes in pieces of swiss cheese, well we know what happened on AF447.

            General Swiss Cheese model overview below [1].

            It's not rocket science (well, actually, maybe it is - see e.g. O rings and Feynman's addendum to the space shuttle inquiry report) e.g. via [2].

            But when the regulatory authorities start accepting modifications to equipment and procedures without proper understanding of the implications, we all stand to lose.

            [1] https://en.wikipedia.org/wiki/Swiss_cheese_model

            "The Swiss cheese model of accident causation is a model used in risk analysis and risk management, including aviation safety, engineering, healthcare, emergency service organizations, and as the principle behind layered security, as used in computer security and defense in depth. It likens human systems to multiple slices of swiss cheese, stacked side by side, in which the risk of a threat becoming a reality is mitigated by the differing layers and types of defenses which are "layered" behind each other. Therefore, in theory, lapses and weaknesses in one defense do not allow a risk to materialize, since other defenses also exist, to prevent a single point of failure. [etc]"

            [2] https://motherboard.vice.com/en_us/article/nz7byb/the-challenger-disasters-minority-report

          2. Alan Brown Silver badge

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

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

            In the case of AF447 it was also related to the _type_ of pitot used (although why you'd want them all from the same maker I'm not quite sure, it means they may all fail the same way. Nonetheless, that's what airlines insist on) and the factor that the pilots didn't turn on deicing heat when approaching said thunderhead (which should be automated anyway)

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

Other stories you might like