Air India 787 Crashes in Western India

I don't understand why people here get irritated about people speculation on these accidents. I mean this is pretty much what this forum is about. Also, I have zero experience with software or anything aviation related (aside from flying my little piper) but I was wondering since these accidents can affect many airplanes in other countries, does Boeing have any contractual legalese that requires them getting black box and CVR information?
 
Contractually no. But if the regulatory agencies want a change they would have to show Boeing. Usually the manufacturer of the aircraft, in the US at least, is typically a party to the investigation.
 
francisco collazos said:
does Boeing have any contractual legalese that requires them getting black box and CVR information?
Click to expand...
Within ICAO member countries, Annex 13 governs how accidents are dealt with and investigated. Part of that guidance are requirements for the country where the occurrence happened to notify the country of origin, operator, and manufacture. Once those other countries are notified their national aviation authority will notify the individual entities like Boeing. So unless the occurrence country wishes to share that CVRFDR info with Boeing, they have no access to it.

francisco collazos said:
I don't understand why people here get irritated about people speculation on these accidents.
Click to expand...
Mostly because the comments from curious bystanders with limited aviation experience start to reach levels of absurdity especially when people start to use other industries for comparisons. Regardless, its pretty subdued on PoA given the average demographics of the members but go to an industry specific forum and they'll cull out the offenders. What most people who bring up those types of comments don't realize is how they appear to those who do understand the industry or situation.

francisco collazos said:
Put me down as another one that thinks this is going to be related to the software.
Click to expand...
Rick A said:
My WAG agrees... software.
Click to expand...
Curious. Based on the known info, why do you both think is software related? Do you have any other previous examples to base that on?
 
Rick A said:
My WAG agrees... software.
Click to expand...

I worked with one contractor that wrote up problem reports as a software defect if the fix was done in software, even if the problem was actually in the hardware.

How many software engineers does it take to change a light bulb - none, it's a hardware problem.

How many hardware engineers does it take to change a light bulb - none, everything can be fixed in software.
 
To me with my limited experience, that's the only thing that I think that can make sense with everything that I know. But what do I know, i'm just a lowly Veterinarian.
bonefishpete said:
I don’t see it. If was software wouldn’t there be calls to ground the Fleet?
Click to expand...
That's why I was asking how much information would be legally available to Boeing and the FAA.
 
Considering s/w: did it do something unintended or unexpected? Those are very different things. Unintended =
“It was never supposed to do that!”, Unexpected = “given the inputs it did exactly what it was designed to do…too bad we didn’t think that one through.”

Assuming a loss of thrust: has there been any solid indication of when that happened? I know that early speculation the takeoff roll was unexpectedly long. I’m not sure that’s been verified.
 
SebIp said:
I work in safety critical systems as well. And while the processes are heavy, often how people do things can leave you quite concerned.

My area is automated train control. And I will say that for a lot of systems I know of, I would happily ride them. However, if I hear they are having issues like disabled train or passenger assistance events, I would start thinking what if. In my experience no one has ever managed to test all the corner cases. I am talking decades old code based which is about as revenue proven as you get. And they still find “well we didn’t think of that scenario” safety impacting bugs. After all the FEMCA, hazard logs, reviews and mitigations as well. And this is with regression tests taking up to 6 months with an army of testers after being very specific to only new changes.

It is entirely possible for there to be unknown safety problems. The name of the name is never to prevent all out comes but to adopt the layered Swiss cheese model. The idea being multiple levels of safety and mitigation to reduce the likelihood of any holes lining up. Even then it’s never ever a case of perfect safety but As Low As Reasonably Practical or ALARP.
Click to expand...
That is the problem with code that relies on combination of math ( which is easy and very predictable in term of testing ) and human programmed state machines ( which, as you mentioned, can be leaky even after decades of history and testing ) and that's where I think AI will come in …

If you think of AI training as self correcting, test driven development - continuously generating almost unlimited number of scenarios with back propagating algorithm responsible for adjusting and creating practically unlimited number of state machines in response to these scenarios , then this sort of process can generate state machines that no human programmers can approach in terms of complexity and problem coverage.
Of course, the flip side here is that the resulting state machine will be impossible to test using regular methods and we will never be fully able to verify its logic the way we can with purely mathematical constructs.

Now, if you think about it , we have the same problem with human intelligence – while we are reasonably confident that the person we have selected to be responsible for , say flying an airplane, will not suddenly develop hallucinations and start speaking in tongues , we can’t be 100% sure ( just like with the enormously complex AI developed state machines) and our ways of mitigating this risk is to build multiple layers of redundancy on top – that’s is having another pilot, ATC and so no and on …

We can do that same with Ais by having another one or more Ais ( using different implementation ) validate and supervise the original AI and so on…
 
Bell206 said:
Curious. Based on the known info, why do you both think is software related? Do you have any other previous examples to base that on?
Click to expand...
Both engines failed simultaneously. Air conditioning glitches were reported by prior passengers of that aircraft. The survivor said the lights flickered soon after liftoff. Don't know what other reasons could connect all three of those reports (if all true) together than a software issue within the flight management computer. Wild Ass Guess is just that...
 
Seems to me Air India is dragging their feet over this. If it was this catastrophic electrical crash/transfer/glitch, why delay everything? You know they would gladly blame Boeing, don’t see that.

I think it comes back to maintenance or crew actions, just seems like more would be out by now.
 
sourdough44 said:
Seems to me Air India is dragging their feet over this. If it was this catastrophic electrical crash/transfer/glitch, why delay everything? You know they would gladly blame Boeing, don’t see that.

I think it comes back to maintenance or crew actions, just seems like more would be out by now.
Click to expand...
My thoughts exactly. My speculation is air India knows what happened but doesn't want to share as that would make them look bad. Being the flag carrier in a country known for bribes, I would not be surprised if things get covered up.

Looking at the financials a bit, it doesn't look good. When financial heath is an issue. Maintenance is an issue as well.
 
Rick A said:
Both engines failed simultaneously. Air conditioning glitches were reported by prior passengers of that aircraft. The survivor said the lights flickered soon after liftoff. Don't know what other reasons could connect all three of those reports (if all true) together than a software issue within the flight management computer.
Click to expand...
So its your assumption that the engine FADEC software also talks to the AC software and the lighting software? As for other reasons perhaps there was an electrical issue due to improper mx, or the crew turned off the wrong switch, or the fuel system failed, or....?
 
Or.... massive electrical surge that kicked everything off line? Would explain the RAT deploy. That is my WAG contribution - and I'll even rate that myself as pretty implausible.
 
WDD said:
Or.... massive electrical surge that kicked everything off line? Would explain the RAT deploy. That is my WAG contribution - and I'll even rate that myself as pretty implausible.
Click to expand...
In a few of the thousands of comments on this accident over on PPRuNe, arcing across circuits is described as a potential source of failure. "Boeing whistleblower, Sam Salehpour claims that Boeing used improper techniques to ground electrical systems on the 787, which could lead to arcing, overheating, and potential fire hazards."
 
Bell206 said:
So its your assumption that the engine FADEC software also talks to the AC software and the lighting software?
Click to expand...
I don't think @Rick A has to assume they're connected to think software is the culprit. I sure don't think AC is connected to FADEC, yet I've heard enough to want to redesign the software even if it is unrelated in any way whatsoever to the cause of the crash. No captain wants his fuel shut off on takeoff. Period. This is a design for an imaginary ground malfunction required by the FAA (it's not a clever Boeing selling point) to prevent a possible problem never seen before — a runaway FADEC on the ground. Unfortunately, nobody seems to have ever asked, "So what happens if FADEC is in the air despite that it thinks it's on the ground?"

This is where the video of passengers fanning themselves in sweltering heat and seat back displays and phones not working become clues in my mind. The AC was not up to the task, which it should be. Information I've seen at PPRuNe raises the question that the APU may (I say "may") have been inop or not installed, since it was an option, necessitating use of three GPUs instead. That begets the possibility there weren't three available. By using the "Ground Test Enable" switch, one AC pack could be operated with two GPUs. Load shedding would occur as normal if that was the case, and that might (I said "might") explain why some screens seemed to work while others did not in the video. The AC pack software doesn't need to "talk to the FADEC software", as you put it.

So, let's say maintenance in a rush to depart on time doesn't normalize the switch? Now, the normal lockouts are defeated. As far as FADEC is concerned, if it could think, it's on the ground and about to run some tests with the normal safeguards linked to the weight on wheels system disabled in order to test the systems. One such disabled safeguard affects TCMA. TCMA shuts down the engine, as required by the FAA and drawn up by Boeing, only on the ground under certain conditions. Since it's safeguard is disabled, it can now do it in the air too. All it needs is a reason.

Reasons? N1/N2? Thrust reverser deployment? Throttle position sensor? TOGA? In the past, FADEC has mistakenly thought it was landing and idled the engines, but the pilots thought they were going around. Who do we suppose was correct? TCMA also thought the engines were running away after landing and shut down both of them when the pilots got a little too aggressive with reverser deployment, not very helpful if they were running out of runway, which, luckily, they weren't. N1/N2 overspeed, I forget which is the sensor of interest, is apparently more sensitive at high ambient temperatures. If so, I could see both sides exceeding TCMA's parameters as IAS increases during takeoff on a hot day.

I keep looking to learn some fact that shuts down this possible path. Like, "There is a lockout for the ground test enable switch, so it's impossible to takeoff with it enabled."

Does anybody here know the answer? Any Boeing pilots/mechanics able to set me straight?
 
Last edited:
WDD said:
Or.... massive electrical surge that kicked everything off line? Would explain the RAT deploy. That is my WAG contribution - and I'll even rate that myself as pretty implausible.
Click to expand...
To me the lack of urgency to decipher the problem points directly to the cockpit crew.
 
bonefishpete said:
To me the lack of urgency to decipher the problem points directly to the cockpit crew.
Click to expand...
Why this instead of a maintenance issue?

A crew issue is individual and can be blamed on someone who cannot defend themselves, and can never do it again. The perfect scapegoat.

Mx issues, OTOH, lead straight back to the team operating every future flight. This reflects on the company, processes, management, employees, and the general state of their fleet. This is a report that they will avoid at any cost.
 
Last edited:
Rick A said:
Both engines failed simultaneously. Air conditioning glitches were reported by prior passengers of that aircraft. The survivor said the lights flickered soon after liftoff. Don't know what other reasons could connect all three of those reports (if all true) together than a software issue within the flight management computer. Wild Ass Guess is just that...
Click to expand...

A "software issue within the flight management computer" wouldn't cause AC glitches or cabin lights flickering.

The software in an aircraft is not some huge monolithic blob with everything connected to everything.
 
Bob Noel said:
A "software issue within the flight management computer" wouldn't cause AC glitches or cabin lights flickering.

The software in an aircraft is not some huge monolithic blob with everything connected to everything.
Click to expand...
Absolutely not.

However, an intermittent short in one circuit can inductively couple to a different circuit and create interference.

If the frequency of the noise is a multiple of the digital comms rate, it can confuse software with false messages.
 
Bill said:
Well, yes. Different end result.
Click to expand...
Not just a different result, a completely different potential root cause.

TWA 800 would have been a high current / low impedance continuous fault that generated enough heat to ignite fuel. That requires a short in a power circuit.

The theoretical effect I was referring to is a high impedance / low current intermittent fault that creates electromagnetic noise which inductively couples to and interferes with digitial communications.
 
Sorry if this was clarified in the prior 500+ posts...
The CVR and FDR would only be relevant up until the RAT was activated as they're not provided emergency power, correct?
 
dtuuri said:
Information I've seen at PPRuNe raises the question that the APU may (I say "may") have been inop or not installed, since it was an option, necessitating use of three GPUs instead.
Click to expand...
Keep in mind, the moderators at pprune have locked the Air India threads a number of times due to the amount BS posts and other false info. And for reference, the original Air India thread exceeded all pprune records for posts within a 24 hour period. Regardless, there have been some authoritative posts on the various systems on pprune and other forums by 787 pilots, mechanics, and engineers.

For example, the 787 APU is standard equipment and specifically built for it due to the increased electrical loads. However, it can be MEL’d under certain conditions. And it is not uncommon for some operators to continuously run the APU until after takeoff to help manage the electrical loads.

On the GPU references, due to the higher electrical loads the 787 requires the use of 2 GPUs of a minimum rating to power all systems on the ground. The 3rd GPU is only needed for engine start, however, the APU can easily handle all ground loads and engine starts. And given the APU inlet door was open on the wreckage, there is a consensus the APU was running at take-off.

dtuuri said:
If so, I could see both sides exceeding TCMA's parameters as IAS increases during takeoff on a hot day.
Click to expand...
There have also been several interesting TCMA discussions to include comparisons to the ANA 787 incident. The consensus there is while an improper TCMA activation would cause an engine decel, the logic or parameters to get there are highly unlikely. The TCMA is only enabled on the ground and requires the throttle to be at idle to initiate. And from a software failure point of view, it would require a major failure in 2 separate software paths to the FADEC and at both engines at the same time. So unless the crew pulled the throttles back to idle just prior to liftoff, activation of the TCMA does not appear to be possible at this point.

tobnpr said:
The CVR and FDR would only be relevant up until the RAT was activated as they're not provided emergency power, correct?
Click to expand...
No. Its been stated in other discussions one of the EAFRs has an internal power supply.
 
Eh... Let's just all blame Putin. Let's say there was a Russian whistle-blower he didn't like on that plane.
 
Bell206 said:
Regardless, there have been some authoritative posts on the various systems on pprune and other forums by 787 pilots, mechanics, and engineers.
Click to expand...
Yes, I looked for TDRACER's posts, mostly. He's a retired Boeing software designer, on throttle action mostly, IIRC.
Bell206 said:
For example, the 787 APU is standard equipment and specifically built for it due to the increased electrical loads. However, it can be MEL’d under certain conditions.
Click to expand...
It can be inop (MEL'd) if always within 3 hrs. of a suitable airport on the upcoming flight.
Bell206 said:
... given the APU inlet door was open on the wreckage, there is a consensus the APU was running at take-off.
Click to expand...
I saw the picture of it, but does it mean the APU was running for takeoff or on the ramp? I've read where the APU automatically starts if there's an electrical failure.
Bell206 said:
There have also been several interesting TCMA discussions to include comparisons to the ANA 787 incident. The consensus there is while an improper TCMA activation would cause an engine decel, the logic or parameters to get there are highly unlikely. The TCMA is only enabled on the ground and requires the throttle to be at idle to initiate. And from a software failure point of view, it would require a major failure in 2 separate software paths to the FADEC and at both engines at the same time. So unless the crew pulled the throttles back to idle just prior to liftoff, activation of the TCMA does not appear to be possible at this point.
Click to expand...
Not my understanding of the comparison, but I may be misremembering. I thought the ANA incident was a shutdown of both engines and it was due to being too light on the "squat switches" upon touchdown when the pilot deployed thrust reversers. Shutdown or idle, I guess the plane needed to be towed off the runway. FADEC/TCAM doesn't allow TRs in flight. I also think I read where there is a service bulletin upgrade to the software. Maybe all operators haven't yet complied?
 
Rick A said:
The survivor said the lights flickered soon after liftoff.
Click to expand...
All of the modern airliners that I know of use non-paralleling electrical systems. That means that in order to change the power source of an electrical BUS, the BUS must first be depowered, then the new power source is applied. It takes just a fraction of a second but there is a flicker in the lights that are powered by that bus. The BUS transfer will happen when an engine or generator fails and the busses it powers are switched to an alternate power source. This is a simple explanation which is consistent with what the survivor described.

Don't know what other reasons could connect all three of those reports (if all true) together than a software issue within the flight management computer.
Click to expand...
Not knowing other reasons is very different from there not being any other reasons. Case in point, the flight management computers (three of them) do not have anything to do with engines, airconditioning, or cabin lighting. They are navigation computers.

dtuuri said:
raises the question that the APU may (I say "may") have been inop
Click to expand...
APUs are not usually running during takeoff. There are situations where they would be but it is relatively rare. GPUs are the ground power units that the airplane is plugged into while parked at the gate. Similarly, airconditioning at the gate is often provided by a pre-conditioned air unit at the gate so that the APU doesn't have to run continuously while parked.

So, let's say maintenance in a rush to depart on time ...
Click to expand...
I've been an airline pilot since 1990. I've yet to see a mechanic in a rush. Maybe it's different in India.
 
X3 Skier said:
They have some data but nobody outside of the Indian “NTSB” apparently knows what it is or is not.
Click to expand...
The Indian "NTSB" is called the Aircraft Accident Investigation Bureau (AAIB). They have one of the oddest government websites I've seen.

Aircraft Accident Investigation Bureau

AAIB, India is responsible for classification of ‘Safety Occurrences’ involving aircraft operating in the Indian Airspace into Accidents, Serious Incidents and Incidents.
aaib.gov.in
 
dtuuri said:
I don't think @Rick A has to assume they're connected to think software is the culprit. I sure don't think AC is connected to FADEC, yet I've heard enough to want to redesign the software even if it is unrelated in any way whatsoever to the cause of the crash. No captain wants his fuel shut off on takeoff. Period. This is a design for an imaginary ground malfunction required by the FAA (it's not a clever Boeing selling point) to prevent a possible problem never seen before — a runaway FADEC on the ground. Unfortunately, nobody seems to have ever asked, "So what happens if FADEC is in the air despite that it thinks it's on the ground?"

This is where the video of passengers fanning themselves in sweltering heat and seat back displays and phones not working become clues in my mind. The AC was not up to the task, which it should be. Information I've seen at PPRuNe raises the question that the APU may (I say "may") have been inop or not installed, since it was an option, necessitating use of three GPUs instead. That begets the possibility there weren't three available. By using the "Ground Test Enable" switch, one AC pack could be operated with two GPUs. Load shedding would occur as normal if that was the case, and that might (I said "might") explain why some screens seemed to work while others did not in the video. The AC pack software doesn't need to "talk to the FADEC software", as you put it.

So, let's say maintenance in a rush to depart on time doesn't normalize the switch? Now, the normal lockouts are defeated. As far as FADEC is concerned, if it could think, it's on the ground and about to run some tests with the normal safeguards linked to the weight on wheels system disabled in order to test the systems. One such disabled safeguard affects TCMA. TCMA shuts down the engine, as required by the FAA and drawn up by Boeing, only on the ground under certain conditions. Since it's safeguard is disabled, it can now do it in the air too. All it needs is a reason.

Reasons? N1/N2? Thrust reverser deployment? Throttle position sensor? TOGA? In the past, FADEC has mistakenly thought it was landing and idled the engines, but the pilots thought they were going around. Who do we suppose was correct? TCMA also thought the engines were running away after landing and shut down both of them when the pilots got a little too aggressive with reverser deployment, not very helpful if they were running out of runway, which, luckily, they weren't. N1/N2 overspeed, I forget which is the sensor of interest, is apparently more sensitive at high ambient temperatures. If so, I could see both sides exceeding TCMA's parameters as IAS increases during takeoff on a hot day.

I keep looking to learn some fact that shuts down this possible path. Like, "There is a lockout for the ground test enable switch, so it's impossible to takeoff with it enabled."

Does anybody here know the answer? Any Boeing pilots/mechanics able to set me straight?
Click to expand...
Software doesn't think. It cannot reason. It cannot make decisions, despite the terminology being used in development. Software can take inputs and do something specifically programmed with those inputs then output something specifically programmed. There are always situations where the inputs are incorrect (faulty sensors, malformed inputs, etc.) or situations where the developers truly didn't anticipate something, both can lead to unexpected behavior. Rarely does a software error result in the software doing something expected, however the wrong expectation.

Your presumption that SGsOTI thought of exceptions that Boeing just didn't think of or intentionally allow these systems to catastrophically fail is simply ridiculous. I don't have a clue why you think this crazy chain of software failures, switches in the wrong position, sensors that no one tested at temperatures that are typical in may parts of the world, GPUs (what do GPUs have to do with a loss of thrust while departing?), blah, blah is likely. Yet, you can easily dismiss that humans, who can think and reason and make decisions might misinterpret valid inputs (I feel a loss of thrust, it must be this) and incorrectly output something (cutting fuel to restart engines, cutting the wrong engine in a single engine failure, manually deploying the RAT).
 
You must log in or register to reply here.
Back
Top