7 ms·

Rookie pilot here. Large airplanes have drive by wire systems where the plane pretty much flies itself. But when certain instruments like the Pitot tube don't w

Rookie pilot here. Large airplanes have drive by wire systems where the plane pretty much flies itself. But when certain instruments like the Pitot tube don't work then the control is handed over to pilots and they operate in alternate law, where they are responsible for the actions. If instruments cannot measure key environmental indicators such as velocity, temperature etc - no amount of automation will save the plane. Instrument meteorological conditions (IMC) / Instrument Flight Rating (IFR) flights are when the plane is flying through darkness, or through conditions that do not allow for a judgement of the visual elements and therefore pilots can easily make incorrect judgement calls on the position of the plane, leading to a crash. The pitot tube is a primitive equipment to measure wind velocity and easily can be jammed by ice, insects etc. I think it was the Pitot tube malfunction in this plane that caused the incident.

inferiorhuman 8y ago
What's being called into question here is the alpha vane (which measures the angle of attack) and AoA disagree warning -- of which the 737 has two and none respectively. This means that there's no quorum (need 3+ vanes for that) and no way for the pilots to know if there's a problem with the AoA data being fed into the computers. I believe the issue is that this hidden system (MCAS) relies on AoA data which can, per the above, not be validated by the pilots or the computers. Thus the fear is that the plane will go full nose down for no obvious reason. Granted the emergency AD indicates some secondary indicators that your AoA vanes have gone wonky. Per the AA email: > The MCAS function becomes active when the airplane Angle of Attack exceeds a threshold based on airspeed and altitude. Stabilizer incremental commands are limited to 2.5 degrees and are provided at a rate of 0.27 degrees per second. The magnitude of the stabilizer input is lower at high Mach number and greater at low Mach numbers. The function is reset once angle of attack falls below the Angle of Attack threshold or if manual stabilizer commands are provided by the flight crew. If the original elevated AOA condition persists, the MCAS function commands another incremental stabilizer nose down command according to current aircraft Mach number at actuation. IOW hey the plane might try to kill you and while you're busy trying not to die at 5,000 ft please disable the electronic aids and grab the trim wheels by hand. Noting, of course, that it take the computer ~30 seconds to move the stabilizer from one end of its travel to the other. It'll take a person longer if you're cranking it by hand. This is, of course, all after the pilots have realized what the problem actually is. All of this at five thousand feet where you might not have 30 seconds to respond. I'd suggest that if this scenario is at all close to what transpired those pilots didn't have a chance.
- FabHK 8y ago
  > no way for the pilots to know if there's a problem with the AoA data Just to clarify, with two AoA sensors, you can know that there is a problem (if they disagree), but you don't know which one is erroneous. What I find surprising about this crash is that even if there's an indication of unreliable readings, the automation proceeds to actively do stuff - I thought Boeing philosophy was to hand everything to the pilots in such a case. > I'd suggest that if this scenario is at all close to what transpired those pilots didn't have a chance. Yeah, absolutely devastating. In the time they had, how were they supposed to diagnose that error condition (automatic down trim), given that a) it sneakily recurs every now and then, and b) it was not prepared/trained for?
  - inferiorhuman 8y ago
    > Just to clarify, with two AoA sensors, you can know that there is a problem (if they disagree), but you don't know which one is erroneous. The AoA disagree alert is an optional feature on the 737[1]. My understanding is that the AoA display is optional as well[2] but does not break down the info per vane. I don't know if the gauge and alert are bundled together or available separately. So maybe you can know, maybe not. 1: https://ad.easa.europa.eu/blob/2018-23-51_Emergency.pdf/EAD_US-2018-23-51_1 https://ad.easa.europa.eu/blob/2018-23-51_Emergency.pdf/EAD_... 2: https://cimg2.ibsrv.net/gimg/pprune.org-vbulletin/432x481/e7b83569_c06b_4d91_a0b7_2d397e0f608f_c460dc9136ee5730ca34bfc573d8b923e98b11bd.jpeg https://cimg2.ibsrv.net/gimg/pprune.org-vbulletin/432x481/e7...
    - FabHK 8y ago
      Interesting. What I meant to say is that even if the pilots had no way of knowing, the computer should notice and drop into a failure mode (that does not involve trimming down again and again, until the pilot sticks an umbrella in the trim wheel).
    - VBprogrammer 8y ago
      I'd be surprised if this was the case. Typically redundancy like this is handled by having A and B systems on commercial aircraft. In the case of flight instruments this is usually divided by pilot and co-pilot systems. They have a separate AHRS (Attitude and Heading system) and their flight instruments show data from each system independently. If you watch a cockpit video of an airliner taking off you will usually hear the co-pilot announce "80 knots" and the pilot reply "cross-checked". What they are doing is checking that their air-sensor data agrees (within a reasonable margin) for the most critical information at that stage of flight (since takeoff speed is very important with the modern wing shape on an airliner). Similarly they have A and B autopilot systems which are driven independently by two AHRS units (except in special cases like during auto-land where both systems are operational). Which is all to say that I think they likely have two separate AoA sensors. Although, perhaps being an optional element the failure of one doesn't automatically trigger a AHRS disagree message.
howard941 8y ago
A minor correction as it pertains to US readers: >Instrument meteorological conditions (IMC) / Instrument Flight Rating (IFR) flights are when the plane is flying through darkness In the US flight in darkness is not flight in IMC. Neither does darkness impose instrument flight rules. Recall that IMC is governed by ceiling, proximity to visible moisture, and visibility: Fail one of those criterion and you're in IMC, governed by IFR. A pilot lacking an instrument rating may fly in pitch black, no moon, (high) overcast over an ocean and still be VFR compliant. Whether it's wise or not is a different issue...

inferiorhuman 8y ago

What's being called into question here is the alpha vane (which measures the angle of attack) and AoA disagree warning -- of which the 737 has two and none respectively. This means that there's no quorum (need 3+ vanes for that) and no way for the pilots to know if there's a problem with the AoA data being fed into the computers. I believe the issue is that this hidden system (MCAS) relies on AoA data which can, per the above, not be validated by the pilots or the computers. Thus the fear is that the plane will go full nose down for no obvious reason. Granted the emergency AD indicates some secondary indicators that your AoA vanes have gone wonky. Per the AA email: > The MCAS function becomes active when the airplane Angle of Attack exceeds a threshold based on airspeed and altitude. Stabilizer incremental commands are limited to 2.5 degrees and are provided at a rate of 0.27 degrees per second. The magnitude of the stabilizer input is lower at high Mach number and greater at low Mach numbers. The function is reset once angle of attack falls below the Angle of Attack threshold or if manual stabilizer commands are provided by the flight crew. If the original elevated AOA condition persists, the MCAS function commands another incremental stabilizer nose down command according to current aircraft Mach number at actuation. IOW hey the plane might try to kill you and while you're busy trying not to die at 5,000 ft please disable the electronic aids and grab the trim wheels by hand. Noting, of course, that it take the computer ~30 seconds to move the stabilizer from one end of its travel to the other. It'll take a person longer if you're cranking it by hand. This is, of course, all after the pilots have realized what the problem actually is. All of this at five thousand feet where you might not have 30 seconds to respond. I'd suggest that if this scenario is at all close to what transpired those pilots didn't have a chance.

FabHK 8y ago
> no way for the pilots to know if there's a problem with the AoA data Just to clarify, with two AoA sensors, you can know that there is a problem (if they disagree), but you don't know which one is erroneous. What I find surprising about this crash is that even if there's an indication of unreliable readings, the automation proceeds to actively do stuff - I thought Boeing philosophy was to hand everything to the pilots in such a case. > I'd suggest that if this scenario is at all close to what transpired those pilots didn't have a chance. Yeah, absolutely devastating. In the time they had, how were they supposed to diagnose that error condition (automatic down trim), given that a) it sneakily recurs every now and then, and b) it was not prepared/trained for?
- inferiorhuman 8y ago
  > Just to clarify, with two AoA sensors, you can know that there is a problem (if they disagree), but you don't know which one is erroneous. The AoA disagree alert is an optional feature on the 737[1]. My understanding is that the AoA display is optional as well[2] but does not break down the info per vane. I don't know if the gauge and alert are bundled together or available separately. So maybe you can know, maybe not. 1: https://ad.easa.europa.eu/blob/2018-23-51_Emergency.pdf/EAD_US-2018-23-51_1 https://ad.easa.europa.eu/blob/2018-23-51_Emergency.pdf/EAD_... 2: https://cimg2.ibsrv.net/gimg/pprune.org-vbulletin/432x481/e7b83569_c06b_4d91_a0b7_2d397e0f608f_c460dc9136ee5730ca34bfc573d8b923e98b11bd.jpeg https://cimg2.ibsrv.net/gimg/pprune.org-vbulletin/432x481/e7...
  - FabHK 8y ago
    Interesting. What I meant to say is that even if the pilots had no way of knowing, the computer should notice and drop into a failure mode (that does not involve trimming down again and again, until the pilot sticks an umbrella in the trim wheel).
  - VBprogrammer 8y ago
    I'd be surprised if this was the case. Typically redundancy like this is handled by having A and B systems on commercial aircraft. In the case of flight instruments this is usually divided by pilot and co-pilot systems. They have a separate AHRS (Attitude and Heading system) and their flight instruments show data from each system independently. If you watch a cockpit video of an airliner taking off you will usually hear the co-pilot announce "80 knots" and the pilot reply "cross-checked". What they are doing is checking that their air-sensor data agrees (within a reasonable margin) for the most critical information at that stage of flight (since takeoff speed is very important with the modern wing shape on an airliner). Similarly they have A and B autopilot systems which are driven independently by two AHRS units (except in special cases like during auto-land where both systems are operational). Which is all to say that I think they likely have two separate AoA sensors. Although, perhaps being an optional element the failure of one doesn't automatically trigger a AHRS disagree message.

howard941 8y ago

A minor correction as it pertains to US readers: >Instrument meteorological conditions (IMC) / Instrument Flight Rating (IFR) flights are when the plane is flying through darkness In the US flight in darkness is not flight in IMC. Neither does darkness impose instrument flight rules. Recall that IMC is governed by ceiling, proximity to visible moisture, and visibility: Fail one of those criterion and you're in IMC, governed by IFR. A pilot lacking an instrument rating may fly in pitch black, no moon, (high) overcast over an ocean and still be VFR compliant. Whether it's wise or not is a different issue...