Air India 787 Crashes in Western India

Game changer? When we know why the rat deployed we'll actually know something.
 
Who here knows the interlocks provided by the "Air-Ground Sensing System"? Almost appears the engines quit upon lift-off. Maybe refueling valves stuck or closed when the weight came off the wheels. :dunno:
 
Game changer? When we know why the rat deployed we'll actually know something.
Most likely because the pilot pushed the button.

But this might explain some other hydraulic related stuff as to why the main gear was still out.
 
If my search results are correct, the RAT automatically deploys under the following conditions.

Dual engine failure
Low pressure in all three hydraulic systems
Complete loss of electrical power to captain and first officer displays
Loss of all four electric motor-driven hydraulic pumps
Loss of all four electric motor-driven hydraulic pumps + engine failure (takeoff)
 
If my search results are correct, the RAT automatically deploys under the following conditions.

Dual engine failure
Low pressure in all three hydraulic systems
Complete loss of electrical power to captain and first officer displays
Loss of all four electric motor-driven hydraulic pumps
Loss of all four electric motor-driven hydraulic pumps + engine failure (takeoff)

Seems to agree with what's in our manual.

IMG_3654.jpeg
 
What would you misfuel with?? Turbines will run on almost anything.
In at least one confirmed case, a fueler put DEF into the Jet-A tank of the truck, rather than the truck's DEF tank for diesel emissions.
Highly unlikely this happened, but it could stop two from turnin' and burnin'.
 
We tend to treat the 737 MAX crashes, Air France 447, and the recent 787 takeoff crash in India as separate events. Different airframes, different systems, different failure modes. But they are not separate. They are three manifestations of the same underlying problem.

In all three cases, the aircraft remained physically controllable. What failed was the logic that mediated between the crew and the machine.

The 737 MAX crashes were caused by MCAS acting on a single faulty angle-of-attack sensor. It trimmed nose-down repeatedly, overriding pilot inputs. The system was not transparent, and it was not defeatable without trim cutout switches. There was no way to tell it to stop and give full authority back to the crew.

Air France 447 lost pitot input at cruise, which triggered a cascade of degraded control laws. The autopilot disconnected, protections dropped out, and the aircraft entered alternate law. The airplane still flew, but the logic no longer matched the crew’s understanding. The pilots were not prepared to fly with what remained. The result was confusion, delay, and loss of situational awareness until it was too late.

Now the 787. The aircraft used the entire 11,000-foot runway. It lifted off, but the RAT deployed immediately after rotation, which tells us that primary electrical or hydraulic power was lost. The gear never retracted. There was no fire, no asymmetry, no visible external cause. Based on what is known so far, the engines appear to have stayed on but failed to deliver full power. Whether due to configuration, logic error, or electrical fault, the airplane did not respond to what the pilots needed. They had no way to force it to respond.

Three aircraft. Three contexts. One common thread: the system failed, and it would not hand control back to the pilots.

This is not a bug in any single system. It is a design philosophy problem. These aircraft were built on the assumption that software is the final arbiter, that logic can anticipate and manage edge cases better than a human can. That assumption works right up until it does not. When data is wrong, when systems degrade, when multiple constraints compete, the software narrows instead of yielding. It preserves its own coherence, even as the aircraft falls out of the sky.

We need a change in how authority is handled. If an aircraft loses flight data, if RAT deploys, if the autopilot disconnects unexpectedly or the engines stop responding to thrust commands, the pilots should be able to press one button and take full command. Not filtered command, not suggested input. Direct, physical, complete authority.

That means raw flight controls. Full thrust. Gear and flap operation regardless of system state. Acknowledge the damage risk. Accept the bypass. Let the pilots fly.

This is not about removing automation. It is about making sure the system knows when to step aside. Human pilots rarely exceed their own limits in a crisis. Software does, because it cannot triage. It tries to preserve everything. And when it cannot, it collapses silently and does nothing.

If the crews of the MAX, AF447, or the 787 had been given a simple, guaranteed way to bypass the system and fly the aircraft directly, the outcomes may have been very different. What killed those aircraft was not mechanical failure. It was software that did not know when to get out of the way.

Question. How many of you have had automation get in the way of safely flying your plane? How many wish they could have bypassed it?
 
We tend to treat the 737 MAX crashes, Air France 447, and the recent 787 takeoff crash in India as separate events. Different airframes, different systems, different failure modes. But they are not separate. They are three manifestations of the same underlying problem.

In all three cases, the aircraft remained physically controllable. What failed was the logic that mediated between the crew and the machine.

The 737 MAX crashes were caused by MCAS acting on a single faulty angle-of-attack sensor. It trimmed nose-down repeatedly, overriding pilot inputs. The system was not transparent, and it was not defeatable without trim cutout switches. There was no way to tell it to stop and give full authority back to the crew.

Air France 447 lost pitot input at cruise, which triggered a cascade of degraded control laws. The autopilot disconnected, protections dropped out, and the aircraft entered alternate law. The airplane still flew, but the logic no longer matched the crew’s understanding. The pilots were not prepared to fly with what remained. The result was confusion, delay, and loss of situational awareness until it was too late.

Now the 787. The aircraft used the entire 11,000-foot runway. It lifted off, but the RAT deployed immediately after rotation, which tells us that primary electrical or hydraulic power was lost. The gear never retracted. There was no fire, no asymmetry, no visible external cause. Based on what is known so far, the engines appear to have stayed on but failed to deliver full power. Whether due to configuration, logic error, or electrical fault, the airplane did not respond to what the pilots needed. They had no way to force it to respond.

Three aircraft. Three contexts. One common thread: the system failed, and it would not hand control back to the pilots.

This is not a bug in any single system. It is a design philosophy problem. These aircraft were built on the assumption that software is the final arbiter, that logic can anticipate and manage edge cases better than a human can. That assumption works right up until it does not. When data is wrong, when systems degrade, when multiple constraints compete, the software narrows instead of yielding. It preserves its own coherence, even as the aircraft falls out of the sky.

We need a change in how authority is handled. If an aircraft loses flight data, if RAT deploys, if the autopilot disconnects unexpectedly or the engines stop responding to thrust commands, the pilots should be able to press one button and take full command. Not filtered command, not suggested input. Direct, physical, complete authority.

That means raw flight controls. Full thrust. Gear and flap operation regardless of system state. Acknowledge the damage risk. Accept the bypass. Let the pilots fly.

This is not about removing automation. It is about making sure the system knows when to step aside. Human pilots rarely exceed their own limits in a crisis. Software does, because it cannot triage. It tries to preserve everything. And when it cannot, it collapses silently and does nothing.

If the crews of the MAX, AF447, or the 787 had been given a simple, guaranteed way to bypass the system and fly the aircraft directly, the outcomes may have been very different. What killed those aircraft was not mechanical failure. It was software that did not know when to get out of the way.

Question. How many of you have had automation get in the way of safely flying your plane? How many wish they could have bypassed it?
A little soon to blame automation.

I think Occam is gonna say user error of some flavor.
 
In at least one confirmed case, a fueler put DEF into the Jet-A tank of the truck, rather than the truck's DEF tank for diesel emissions.
Highly unlikely this happened, but it could stop two from turnin' and burnin'.
At most airports being served by large airplanes like the 787, at most gates, the fuel is delivered by an underground system which a pump trailer connecting the in-ground hydrant to the airplane's refueling port(s). The fuel is never loaded onto a truck. I don't know if that was the case here.

It trimmed nose-down repeatedly, overriding pilot inputs. The system was not transparent, and it was not defeatable without trim cutout switches. There was no way to tell it to stop and give full authority back to the crew.
That not accurate. The two accident airplanes, and the one incident flight on what would be the first accident airplane, were all flyable and controllable WITHOUT using the stab trim cutoff switches. In all three cases, the crews did fly for a while using the main electric trim (yoke thumb switches) to remove ALL of the anomalous nose-down trim inputs. That could have continued indefinitely. On both accidents flights, it continued until the Captains handed control of the airplane to the first officers. The stab trim cutout switches are easily reachable by either pilot. Either one of which would have stopped the unscheduled MCAS activations. The problem was that neither of the accident flight's crews correctly accomplished the existing runaway stabilizer checklist items. The incident crew did, but not in a timely manner and not without being reminded of the procedure by their jumpseater.
 
Can anyone explain the two areas of contrast on the upper surface of each wing, behind the engines? On a normal takeoff, I’d assume we’d see the slots of flaps at or above certain extension settings, but do these look like partially deployed spoilers to anyone else?

View attachment 141939
Probably missing paint and speed tape
 
We tend to treat the 737 MAX crashes, Air France 447, and the recent 787 takeoff crash in India as separate events. Different airframes, different systems, different failure modes. But they are not separate. They are three manifestations of the same underlying problem.

In all three cases, the aircraft remained physically controllable. What failed was the logic that mediated between the crew and the machine.

The 737 MAX crashes were caused by MCAS acting on a single faulty angle-of-attack sensor. It trimmed nose-down repeatedly, overriding pilot inputs. The system was not transparent, and it was not defeatable without trim cutout switches. There was no way to tell it to stop and give full authority back to the crew.

Air France 447 lost pitot input at cruise, which triggered a cascade of degraded control laws. The autopilot disconnected, protections dropped out, and the aircraft entered alternate law. The airplane still flew, but the logic no longer matched the crew’s understanding. The pilots were not prepared to fly with what remained. The result was confusion, delay, and loss of situational awareness until it was too late.

Now the 787. The aircraft used the entire 11,000-foot runway. It lifted off, but the RAT deployed immediately after rotation, which tells us that primary electrical or hydraulic power was lost. The gear never retracted. There was no fire, no asymmetry, no visible external cause. Based on what is known so far, the engines appear to have stayed on but failed to deliver full power. Whether due to configuration, logic error, or electrical fault, the airplane did not respond to what the pilots needed. They had no way to force it to respond.

Three aircraft. Three contexts. One common thread: the system failed, and it would not hand control back to the pilots.

This is not a bug in any single system. It is a design philosophy problem. These aircraft were built on the assumption that software is the final arbiter, that logic can anticipate and manage edge cases better than a human can. That assumption works right up until it does not. When data is wrong, when systems degrade, when multiple constraints compete, the software narrows instead of yielding. It preserves its own coherence, even as the aircraft falls out of the sky.

We need a change in how authority is handled. If an aircraft loses flight data, if RAT deploys, if the autopilot disconnects unexpectedly or the engines stop responding to thrust commands, the pilots should be able to press one button and take full command. Not filtered command, not suggested input. Direct, physical, complete authority.

That means raw flight controls. Full thrust. Gear and flap operation regardless of system state. Acknowledge the damage risk. Accept the bypass. Let the pilots fly.

This is not about removing automation. It is about making sure the system knows when to step aside. Human pilots rarely exceed their own limits in a crisis. Software does, because it cannot triage. It tries to preserve everything. And when it cannot, it collapses silently and does nothing.

If the crews of the MAX, AF447, or the 787 had been given a simple, guaranteed way to bypass the system and fly the aircraft directly, the outcomes may have been very different. What killed those aircraft was not mechanical failure. It was software that did not know when to get out of the way.

Question. How many of you have had automation get in the way of safely flying your plane? How many wish they could have bypassed it?
Assuming that automation had something to do with this crash, how would the outcome have changed if the pilots had pushed your 'override automation" button?
 
Assuming that automation had something to do with this crash, how would the outcome have changed if the pilots had pushed your 'override automation" button?
I haven't flown the 787, just the 737, 757, and 767. On all of them, the minimum autopilot engagement altitude on takeoff was 400'. They didn't get much over 400', but that doesn't mean they didn't engage it.

In any case, if the airplane was on autopilot and the autoflight was commanding a descent, it would have pitched the nose down. I never saw the nose pitch down so I don't think that's what happened.

On Boeing, the autopilot can be disengaged by pressing the disengagement switch on either control yoke (normal method) or pulling down the disconnect bar, under the autopilot CMD buttons, on the mode control panel (never seen that used). Very easy to do and done on every single flight, even those that autoland. (You can't taxi off the runway after an autoland without disengaging the autopilots (all three will be engaged at that point). They won't let you turn off the centerline.
 
Now the 787. The aircraft used the entire 11,000-foot runway. It lifted off, but the RAT deployed immediately after rotation, which tells us that primary electrical or hydraulic power was lost. The gear never retracted. There was no fire, no asymmetry, no visible external cause. Based on what is known so far, the engines appear to have stayed on but failed to deliver full power. Whether due to configuration, logic error, or electrical fault, the airplane did not respond to what the pilots needed. They had no way to force it to respond.
Where do you get that? I've read other analysis comparing the flight path to previous 787 takeoffs and it falls within those flightpaths.
 
At most airports being served by large airplanes like the 787, at most gates, the fuel is delivered by an underground system which a pump trailer connecting the in-ground hydrant to the airplane's refueling port(s). The fuel is never loaded onto a truck. I don't know if that was the case here.


That not accurate. The two accident airplanes, and the one incident flight on what would be the first accident airplane, were all flyable and controllable WITHOUT using the stab trim cutoff switches. In all three cases, the crews did fly for a while using the main electric trim (yoke thumb switches) to remove ALL of the anomalous nose-down trim inputs. That could have continued indefinitely. On both accidents flights, it continued until the Captains handed control of the airplane to the first officers. The stab trim cutout switches are easily reachable by either pilot. Either one of which would have stopped the unscheduled MCAS activations. The problem was that neither of the accident flight's crews correctly accomplished the existing runaway stabilizer checklist items. The incident crew did, but not in a timely manner and not without being reminded of the procedure by their jumpseater.
Thanks for the clarification. But I beleive you are missing the point. You're right that the 737 MAX was flyable in each of those cases and that the trim could be manually managed for a time. And yes, the stab trim cutout switches were available throughout. Where I stand by the critique is this: the MCAS system acted without annunciation, based on a single input, and with no direct way to isolate or disable it independently. The crews were put in a position of troubleshooting an unknown failure, under time pressure, without being told that the system even existed. In that context, the core problem is not physical controllability - it’s that the system did not yield command or explain itself when its logic failed. That’s the throughline I’m pointing to across MAX, AF447, and now the 787 event.

That’s where I see the architectural flaw: modern aircraft increasingly embed systems that act invisibly but require pilots to respond as if they had perfect information.

That asymmetry, between what the system does and what the crew knows, puts even highly trained crews at a structural disadvantage. That’s the shared logic problem I’m pointing to. Whether it’s trim, air data, or thrust: when software fails and doesn’t yield, it makes a recoverable aircraft unrecoverable.
 
We tend to treat the 737 MAX crashes, Air France 447, and the recent 787 takeoff crash in India as separate events. Different airframes, different systems, different failure modes. But they are not separate. They are three manifestations of the same underlying problem.


Question. How many of you have had automation get in the way of safely flying your plane? How many wish they could have bypassed it?
I think there's something to be said that as aircraft get more complicated, the human/machine interface can lead to the human doing the wrong thing. Just want to point out two things in the above.

1 - Of those three, we know cause of only the first 2. We don't know that it was the crew that did something wrong on 787. Seems kinda likely to me? But not known, as far as I know.

2 - I'm sure not intentional, but the first one is 737, the second I believe Airbus A330. Just pointing out this human/machine thing isn't limited to any particular manufacturer. I'm sure that wasn't the intent to imply, but you referred to the 737/787 by model number, and the A330 by flight number. I'm one of the first to make fun of Boeing, but interface and complexity is to me a universal thing.
 
At most airports being served by large airplanes like the 787, at most gates, the fuel is delivered by an underground system which a pump trailer connecting the in-ground hydrant to the airplane's refueling port(s). The fuel is never loaded onto a truck. I don't know if that was the case here.


That not accurate. The two accident airplanes, and the one incident flight on what would be the first accident airplane, were all flyable and controllable WITHOUT using the stab trim cutoff switches. In all three cases, the crews did fly for a while using the main electric trim (yoke thumb switches) to remove ALL of the anomalous nose-down trim inputs. That could have continued indefinitely. On both accidents flights, it continued until the Captains handed control of the airplane to the first officers. The stab trim cutout switches are easily reachable by either pilot. Either one of which would have stopped the unscheduled MCAS activations. The problem was that neither of the accident flight's crews correctly accomplished the existing runaway stabilizer checklist items. The incident crew did, but not in a timely manner and not without being reminded of the procedure by their jumpseater.
Thanks for the clarification. But I beleive you are missing the point. You're right that the 737 MAX was flyable in each of those cases and that the trim could be manually managed for a time. And yes, the stab trim cutout switches were available throughout. Where I stand by the critique is this: the MCAS system acted without annunciation, based on a single input, and with no direct way to isolate or disable it independently. The crews were put in a position of troubleshooting an unknown failure, under time pressure, without being told that the system even existed. In that context, the core problem is not physical controllability - it’s that the system did not yield command or explain itself when its logic failed. That’s the throughline I’m pointing to across MAX, AF447, and now the 787 event.

That’s where I see the architectural flaw: modern aircraft increasingly embed systems that act invisibly but require pilots to respond as if they had perfect information.

That asymmetry, between what the system does and what the crew knows
Where do you get that? I've read other analysis comparing the flight path to previous 787 takeoffs and it falls within those flightpaths.
If you watch the takeoff on one of the videos where a shack obstructs part of the runway, you can see a cloud of sand as soon as it lifts off. That would point to the fact that the plane used most if not all of the runway.

But again, you are missing the point. Should you be able to use full thrust when you see the end of the runway vs what was decided by an engineer in Seattle to protect the engines? Are the pilots and passengers now less important than the life of an engine?
 
But again, you are missing the point. Should you be able to use full thrust when you see the end of the runway vs what was decided by an engineer in Seattle to protect the engines? Are the pilots and passengers now less important than the life of an engine?
So you've concluded that the crash was caused by the autothrottle?
 
Where I stand by the critique is this: the MCAS system acted without annunciation, based on a single input, and with no direct way to isolate or disable it independently. The crews were put in a position of troubleshooting an unknown failure, under time pressure, without being told that the system even existed.
If they had followed the applicable checklist, they would have disabled the system and continued the flight safely.

It's not hard to diagnose a runaway stabilizer in a 737. The, somewhat noisy, trim wheels are spinning next to your inboard knee coupled with an increasing nose-down (or up) feel on the yoke. This happens all the time when hand flying the airplane. The normal response is to trim out the control pressures with the main electric trim.

Did you know that as you are accelerating after takeoff during the climb the Speed Trim System is periodically trimming nose up to provide increased speed stability? When you're intentionally accelerating you have to repeatedly stop the nose-up trim and trim out the nose-up inputs it added. A 737 pilot does this on every single flight.

The single-input to MCAS was intentional. Most systems on the airplane work on one system, or the other, depending on which pilot is the flying pilot. There's a very good reason for this. You don't want bad data on one of the two, separate, systems to corrupt the good system as that would leave you without any good data. That makes building a system that can compare data, without creating failure modes that corrupt all of the data, more difficult. That is why it took so long to return the MAX fleet to service as they had to design such a system and test all of the failure modes to ensure that it wouldn't cause both sides to be corrupted. The bigger Boeings, all designed after the 737, have three sets of navigation, flight instrumentation data systems, and autoflight systems instead of two. I'm not an Airbus expert but I only see two sets of switches in the A320 series when I jumpseat so it may be similar.

When we have a problem in a transport jet we don't self-diagnose and come up with our own solution. We refer to the appliable checklist and do those steps. The problem on the MAX accident flights were that the pilots did not follow their training and action the applicable non-normal checklist. If they had, they would have landed safely.
 
I haven't flown the 787, just the 737, 757, and 767. On all of them, the minimum autopilot engagement altitude on takeoff was 400'. They didn't get much over 400', but that doesn't mean they didn't engage it.
The 757’s and 767’s that I’ve flown required 1,000’ AGL for autopilot engagement after takeoff. Also required a lateral and vertical mode selection prior to engaging. Different airline specs obviously. Other jets at my previous employer were 400’.
Boeing also has the infamous low altitude capture logic on some variants but that clearly didn’t come into play here.
A lot of this is dependent on how the jet was ordered. There’s different avionics packages offered. I’ve flown a couple of the variants, which function with slightly different MCP logic and mode options.
 
So you've concluded that the crash was caused by the autothrottle?
Nobody has concluded anything.

On takeoff, the auto-throttles go into ARM mode at around 85 to 90 knots. By that time, they have set TO thrust. This prevents them from making any more changes to thrust during the critical time just before, and just after, takeoff. They stay in ARM until reaching acceleration altitude which is generally between 800' and 3000', depending on the type of departure you are doing. During that time, the auto-throttles can not move the thrust levers.
 
The 757’s and 767’s that I’ve flown required 1,000’ AGL for autopilot engagement after takeoff.
That's probably a company limit. My searches show that the Boeing limitation is 500' on the 767. I also just found that Boeing's limit on the 787 is only 200' so perhaps they did engage the A/P that low.

On the 737, engaging at 400' is more work than just hand flying it through acceleration and clean up. I'm sure the 787 does that better. I'll do it periodically just for practice. Usually hand-fly to at least 15,000', as do most of us.
 
If you watch the takeoff on one of the videos where a shack obstructs part of the runway, you can see a cloud of sand as soon as it lifts off. That would point to the fact that the plane used most if not all of the runway.
Many agree that that sand was kicked up by the wing vortex at the side of the runway as the wing developed lift at rotation. It was not at the end of the runway.
 
He's two days late with that info, which was already known when he made the first video. Stop citing narcissists as sources.
What makes him a narcissist? Is it the giant tik tok and YouTube plaques over his right shoulder on display for everyone to see?
 
Duct tape for planes
Used extensively on the composite wings as they still can't find a paint that wont flake off.

Wouldn't be shocked to see them move to a vinyl wrap for long term uv protection.
 
That's probably a company limit. My searches show that the Boeing limitation is 500' on the 767. I also just found that Boeing's limit on the 787 is only 200' so perhaps they did engage the A/P that low.

On the 737, engaging at 400' is more work than just hand flying it through acceleration and clean up. I'm sure the 787 does that better. I'll do it periodically just for practice. Usually hand-fly to at least 15,000', as do most of us.
I think you’re correct about company limits. A lot of companies fly the same type airplanes differently.
Yeah, I’ve never engage the AP at the minimum altitude except during sim drills.
We typically hand-fly the departure usually into the low to mid teens.

Put me down for it was a hand flown departure with dual engine failure. RAT auto-deployed.

I’ve instructed countless Boeing (not 787) dual engine failures in the simulator at my previous job. Never once did I see someone reach up for the RAT with all that going on. There’s no reason to. It’s already auto deployed. It deploys before most pilots even realize there’s a failure. It’s not uncommon for a CA to reach for the APU to get it coming on line.
Doubt these guys had time for any manual selections at 200’. They were busy processing what had happened while trying to keep it flying.
 
Especially unlikely since 787-8 fuel capacity is over 220,000 lbs and this was a 10 hour flight. Where would enough DEF to effect engine operation come from?
You only need enough to restrict fuel flow through the filters. There is a now-banned additive for Jet-A that did that.
 
I think you’re correct about company limits. A lot of companies fly the same type airplanes differently.
...
Yeah, the published repair specs for jet engines, for example, vary per airline!
 
Thanks for the clarification. But I beleive you are missing the point.
I don't think I've missed your point, I just disagree with it.

In the case of MCAS. I think we all agree that the system could have been better designed and implemented. Failure of the system, however, did not immediately result in an unflyable airplane and the most applicable immediate action procedures were effective. It was only after repeated engagement and off-script troubleshooting that control was lost.

In the case of AF447, much of the augmentation *was* deactivated. The crew rode a stalled airplane down more than 30K ft holding full aft stick. I'm not going to list all of the crew performance errors, but if you're going to wave this banner you should read the full final report.

That means raw flight controls. Full thrust. Gear and flap operation regardless of system state. Acknowledge the damage risk. Accept the bypass. Let the pilots fly.
Not that far from what the A330 above had at the time. It did not work as well as you think it should.

Somewhere in my archives (piles of paper in my office) I have a (publicly available) report of a Harrier crash - the pilot was known for disengaging stability augmentation thinking he could get better maneuverability with no augmentation. While the cause was not determined with any certainty there were strong indications that he broke his neck when the airplane departed and subsequently rode it into the ground.

I've also watched someone depart an F/A-18 with augmentation disabled (in SRM, for those familiar) during benign maneuvering, and have seen the results of similar with a variety of other airplanes.

Given pilot performance when they are surprised by mode changes or disengagement of outer loops, I'm not confident that handing them a completely unaugmented airplane in extremis is going to have a better outcome.

Put me down as unconvinced.

Oh yeah...how were you able to determine the cause the recent 787 crash?

Nauga,
and the demise of MECH mode
 
Last edited:
Game changer? When we know why the rat deployed we'll actually know something.
Game changer in that it wasn’t the FO retracting the flaps instead of the gear like a lot of people myself included thought.
 
Back
Top