Air India crash

[Garfly]

24 minutes ago, Roundsounds said:

The ignorant people who dream up this sort of rubbish obviously don’t understand the certification requirements for these types of airplane. 

Or have been let down before by "understanding" them all too well.

[onetrack]

34 minutes ago, Garfly said:

Russ Niles of AvWeb adds this take:

 

 

Without Video, We'll Never Really Know - AVweb

AVWEB.COM

---

Will the real cause of the crash of Air India 171 ever be known?

 

Excerpt:

"As with everything else it seems, those switches feed wires that end up at a computer, which has the final decision on whether the simple opening or closing of a circuit can proceed. That little box, strapped unceremoniously to the main fan housing of the massive engine, controls all things to do with the fuel, including its sudden absence, a handy feature if it’s on fire but a disaster a few seconds after the mains have air under them. A solder joint on that control unit is prone to cracking and airlines were advised to replace them in 2021.

This plane was said to be up to date on all those sorts of maintenance advisories, so I assume it was done. But the working theory heading around the airline blogs and forums is that it’s possible that a cracked solder joint interrupted the current from the switches under the Gs of rotation to stop the fuel flow long enough to shut down both engines. As far-fetched as it seems, it introduces enough doubt to lay waste to all the other depressing scenarios being bandied about and the arguments that flow from there."

 

 

 

The people who dream up these scenarios have obviously never studied up on the actual design and construction of the B787 systems.

The HPSOV's are solenoid-actuated valves, held in their last-actuated position by spring-pressure detents.

It's not possible for a "cracked solder joint" to shut off the fuel to the engines. It requires ELECTRICAL actuation for the HPSOV's to move from any one position to the other.

 

If the electrical current flow ceases, the HPSOV stays in its previous position. This is what Roundsounds is talking about, the amount of "what-ifs" that go into the design of these systems, before they can be certified to be used in commercial, passenger transport aircraft.

 

I would opine it's likely not even possible for a short-circuit in the fuel cutoff switching circuitry to activate a HPSOV from open to shut.

The engine ECU logic would examine the electrical messaging and determine whether the signal was false or true, by matching the actual fuel cutoff switch position.

 

Of course, if the circuitry close to the HPSOV was shorted (between the ECU and the HPSOV), then I would imagine there COULD be an unintended valve actuation.

But I'll wager the Boeing engineers considered that angle as well, and have done all they could to prevent that happening.

 

This is UNINTENDED, INSTANT engine shutdown we are talking here, it is something that the entire aircraft design would centre around, not happening.

 

But an INTENDED, HPSOV actuation, is going to go through to the engine instantly, it is not designed to be intercepted by either the FADEC or the engine ECU.

[Litespeed]

We can say certification and design would never allow such a situation.

But history of the 737 max and self certification by Boeing with minimal federal oversight has allowed the seemingly impossible to happen.

 

Until the final report and one that's accepted by the European safety authorities, we can not be sure.

 

I do not have a great deal of faith in the USA been a beacon of safety over profit, esp given the Trump cuts. This is India's first full modern investigation into a crash and in a country with known compliance issues, as such we need to wait and see.  They may do a great job or they may not.

 

Question?

Does the 787 have a single FADEC for both engines?

Is it not possible the FADEC is the culprit?

 

Computers are never completely failsafe.

 

To openly speculate about pilot suicide whilst possible does the poor families a great disservice and pilots in general. It also shifts the focus away from technical matters that need to be exhaustively tested.

 

I remember everyone blaming the Pilots for the Max 737 crashes and Boeing happy to blame them, even after the second crash.

 

We can desktop cowboy all we want but we don't know what happened.

 

 

 

[onetrack]

Litespeed - No, the B787 has one FADEC for each engine, and each engine FADEC has totally separate electrical/electronic systems.

 

On the B787, the primary engine control device is termed the EEC, Electronic Engine Control.

 

If there's a B787 weakness anywhere, it could be in the electronic components that switch between the various signal formats, to the ARINC 664 electronic messaging format, that many Boeing aircraft operate on.

 

"The Boeing 787-8 utilizes the Common Core System (CCS) to support the operation of multiple airplane systems, enhancing reliability, and reducing costs and weight.

This system shifts from the traditional approach of dedicated units for each airplane system, to centralized processing.

 

At the heart of the CCS (Common Core System) are software applications that calculate data for most airplane systems. Components of the CCS include:

Two Common Computing Resource (CCR) cabinets, named left and right. Each houses:

2 Power Conditioning Modules (PCM) which provide power for other modules.

8 General Processor Modules (GPM) which run software applications, manage databases, and handle system calculations.

2 ARINC 664 network Cabinet Switches (ACS).

2 Fibre Optic translator Modules (FOX), vital for data conversion between electrical and fibre optic formats.

2 Graphics Generators (GG), not part of the CCS but rather the Primary Display System.

Six ARINC 664 network Remote Switches (ARS) and 21 Remote Data Concentrators (RDC).

The ARS and ACS switches ensure that data gets to the correct destinations, changing between fibre optic and electrical signal formats.

 

RDCs act as intermediaries between the network switches and most airplane systems that don’t use ARINC 664. They convert data from various formats like analogue, ARINC 429, and CAN bus data to ARINC 664 format, and vice versa.

 

The CCR cabinets are in the forward electronic equipment bay, with positions defined by program pins. The system powers up automatically when the airplane is powered, with two startup modes: Uninhibited, involving a full power-up built-in test, and inhibited, where the system is ready in about 50 seconds under specific conditions.

 

The Common Data Network (CDN) facilitates data transfer between various aircraft systems and within the CCS. Many cockpit panel switches interface with the CDN through Panel Interface Pod (PIP) logic circuit card assemblies.

The PIPs digitize panel switch position data, sending it to the CDN and receiving indication data from the CDN.

In summary, the CCS and CDN are integral parts of the Boeing 787, centralizing data processing and communication among airplane systems to optimize functionality and efficiency."

 

The B787 Thrust Management System graphics:

 

Edited yesterday at 02:46 PM by onetrack

[Roundsounds]

8 hours ago, Litespeed said:

We can say certification and design would never allow such a situation.

But history of the 737 max and self certification by Boeing with minimal federal oversight has allowed the seemingly impossible to happen.

 

Until the final report and one that's accepted by the European safety authorities, we can not be sure.

 

I do not have a great deal of faith in the USA been a beacon of safety over profit, esp given the Trump cuts. This is India's first full modern investigation into a crash and in a country with known compliance issues, as such we need to wait and see.  They may do a great job or they may not.

 

Question?

Does the 787 have a single FADEC for both engines?

Is it not possible the FADEC is the culprit?

 

Computers are never completely failsafe.

 

To openly speculate about pilot suicide whilst possible does the poor families a great disservice and pilots in general. It also shifts the focus away from technical matters that need to be exhaustively tested.

 

I remember everyone blaming the Pilots for the Max 737 crashes and Boeing happy to blame them, even after the second crash.

 

We can desktop cowboy all we want but we don't know what happened.

 

 

 

Let’s focus on the AAIB report and not speculate. So you’re speculating the AAIB, FAA, BOEING and GE are all covering up  both Left and Right FADECs failed within 1 second of each other, then around 10 seconds later they recovered?

 

Speaking of cowboys, if the 737 MAX crew had followed SOPs neither of those aircraft would have crashed. 

[IBob]

Some comments here are clearly so one-eyed and judgemental, I've taken to just skipping over them. 

Here are 787 Oral Notes that go some way towards describing the general layout of the electronics and automation:

https://pdfcoffee.com/787-oral-notesdocx-2-pdf-free.html

[Arron25]

13 hours ago, Roundsounds said:

Not to shut down both engines. The systems architecture ensures this cannot occur. 

After 30+ years in the computer industry... 'Cannot Occur' is not something I can agree with

The coincidental errors occur with usually the most inconvenient timing

[facthunter]

That's been covered. Nev

[onetrack]

2 hours ago, IBob said:

Some comments here are clearly so one-eyed and judgemental, I've taken to just skipping over them. 

As with all investigations trying to discover all the facts, the timeline, the motives, and to examine all the potential scenarios, the worst approach is to rapidly come to a conclusion, and to then make the facts fit the conclusion one has come to.

 

Many Police forces have failed dismally when trying to solve major crimes with limited evidence, damaged crime scenes, lies, and often, seemingly no motive - because they approached the cases with preformed ideas, and ignored seemingly small pieces of information, instantly considering them as having no value, and dismissing them from the investigation.

 

In essence, despite air crash investigations being based on avoiding the placement of blame on any one party, the principles of crime investigation should also be applied to air crash investigations, to ensure that even the tiniest piece of evidence of the crash cause or causes, is not ignored, or dismissed out of hand.

 

There is sufficient power pressures at play in this major crash (almost on a par with the Erebus crash), that suspicion is harboured in many quarters, that political or corporate pressure will be applied to ensure that either Air India, Boeing, or even the Indian Aviation regulator come out of the investigation, squeaky clean.

 

An interesting factor now is that a U.K. based law firm, intent on placing blame on a particular party involved in the crash, has commenced its own separate crash investigation, utilising the skills and knowledge of a very senior commander from the IAF.

I do feel that this law firms investigation may be skewed from day one - and they are still reliant on the AAIB providing them with information, whereupon the AAIB may withhold critical information if it reflects badly on Air India or Indian aviation training, or the Indian Aviation regulator. 

 

However, it's perhaps not a bad thing to have another investigation running alongside the primary AAIB one, to maybe uncover facts or issues that the AAIB may overlook, or ignore.

 

I've seen one of the victims relatives describe the preliminary report as "reading like a product review", rather than placing all the facts on the table.

 

The preliminary reports failure to address the timing of the crew voices on the CVR, and to identify those particular voices, is something that seems to be a major failure in the report and has numerous aviation experts carrying on at length about the 10 second delay in returning the fuel cutoff switches to run.

 

That 10 second delay could easily be explained if the voice records had been given a precise timeline in the preliminary report.

There would almost certainly be a "WTF" few seconds in the cockpit as the engines spooled down, power to the displays flickered (as it does in the switching from the primary generators to backup power), and a visual check of thrust control positions was carried out, immediately after major thrust failure.

 

Edited 22 hours ago by onetrack

[IBob]

I agree with all your above Onetrack.
I programmed decades of automation (though not in aircraft). I had a lot to do with logging plant data, also examining it.  And I have a strong troubleshooting background.

On that basis I would like to add this:

There are lots of posts here that assume the EAFR cannot be wrong, in either the data it logs, or the timestamps. So there seems to be a general acceptance that certain exact things happened at certain exact times. While I have no doubt that the people who design these systems do everything they can to ensure that, we cannot be sure that is so.

The data accuracy depends on where the data is sourced and how robust that source is (in this case in accurately reflecting the state of some switches). We should not be simply assuming that the EAFR 'looks' at the switches. It is entirely possible that it 'looks at' something in the software that is interpreting the condition of those switches. In which case there is more to consider than just a couple of switches.

Regarding the timestamps: the EAFR is sharing a common central comms bus with many other things. And it is capturing a broad array of data. Whether it grabs all this data pretty much in one burst, or a bit at a time, I don't know. But any major disruption of those central comms...or indeed any failure to answer by whatever provides the data... has the potential to put the time stamps out from the actual events.The timestamp is when the EAFR managed to source the data. We need to be confident of rapid uninterrupted data access for those timestamps to be taken as accurate.

I write this not to further muddy the waters. But from the info provided, I think we should be saying 'The switches were logged off/on at these specific times.' Not 'The switches went off/on at these specific times.'

I should end by saying that close inspection of the captured data and of how and where that data is sourced would clarify much of the above. And I am hopeful that there are impartial investigators with access to do that.



 

[onetrack]

The blokes in the video below are very, very good. They're aircraft maintainers and crash investigators, and they're three proper experts sitting around having a clinical discussion of the facts.

 

They're not scripted, as are many of the YooToob "crash experts". They savage a lot of the airline captains who present as crash experts, but lack maintainer and crash investigation knowledge.

They absolutely slam the wild theorists, the conspiracy merchants and the outright loonies who propose answers with little logical reasoning and even less technical knowledge.

 

They point out that the lag in providing information by the Indians was a factor that has led to stupid opinions on the reasons for the crash. They also point out the preliminary report information is deficient, and hope that further AAIB information will be more enlightening.

 

But they come to the logical conclusion that no matter what the potential for computer or data glitches, the simple fact remains that the switches were physically moved, they were moved by one of the crew, they were physically returned to run by one of the crew, and that the fuel shutoff valves functioned precisely as designed - from off and back to on, on instructions from the physical movement of the cutoff switches. 

 

A software glitch must be eliminated in this conclusion, as it is basically impossible for it to happen in the above defined events timeline.

 

The conclusion can only be that the cutoff switches were moved in a criminal act, or in a "brain fart" action that seems incredible, but which as we know, can happen, because humans are humans, and they do stupid things.

 

This video is a little long-winded, and you can skip the few minutes in the centre where they talk to an underwriter in an "infomercial" - but overall, it is a worthy watch.

 

 

Edited 20 hours ago by onetrack

[danny_galaga]

4 hours ago, Arron25 said:

After 30+ years in the computer industry... 'Cannot Occur' is not something I can agree with

The coincidental errors occur with usually the most inconvenient timing

And of course, sometimes whatever fault or design flaw caused one thing to go haywire occurs at a similar time in other devices of the same manufacture date.

[Garfly]

45 minutes ago, onetrack said:

"... But they come to the logical conclusion that no matter what the potential for computer or data glitches, the simple fact remains that the switches were physically moved, they were moved by one of the crew, they were physically returned to run by one of the crew, and that the fuel shutoff valves functioned precisely as designed - from off and back to on, on instructions from the physical movement of the cutoff switches ... "

But, to reiterate, that action might have been the (expected) reaction to a double engine failure rather than the cause of it:

 

“Here (in the AAIB prelim report) there is a reference to the pilot cutting off, let’s assume that the pilots cut off both the switches and then put it back again. Now that’s exactly what you’re supposed to do as per the checklist if you lose thrust on both engines."  Capt. Sam Thomas.

 

See the minute from around 07:30 

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

 

[onetrack]

Garfly, the timeline is definitive, there's no place for ASSUMING any action. The fuel cutoff switches were moved to OFF, and then returned to ON, between 10 and 14 seconds later.

 

That's not cycling the switches to reset the engine EEC's, as recommended in the POH checklist, you would expect a cycling of the switches would be much faster - and the timeline says the engine thrust ceased AFTER the switches were moved.

 

Take a look at the above video I linked to, starting at 27:33, and stop the video at 29:19 when the timeline appears.

 

Capt Sam Thomas' assumption is, that a double engine failure can happen spontaneously, but nothing in the B787 design, nor in the timeline, support his assumption.

 

In fact, his assumption is based on a conspiracy to blame the crew. Conspiracy theories are easy to promote, but far harder to prove, as they rely on multiple actions in concert, in a planned path, by multiple agencies or persons, and all with a common supposed agenda.

As a result, conspiracy theories should get short shrift in any professional investigation.

 

Edited 18 hours ago by onetrack

[facthunter]

10 seconds is a LONG time to move the switches to ON. Another thing is It's better to have the gear DOWN when  crash landing other than ditching. nev

[BurnieM]

The 1 second gap switching the fuel switches my not be as significant as some suggest.

Time is normally taken from the GPS.

Many GPS only grab the GPS output once a second mainly cause it takes time to calculate the position and forward it to other devices.

If a second action (second switch?) occurs 2-10 hundreds of a second after the first it may 'wait' for a GPS time to log it.

 

Also 10 seconds to identify a non-standard engine condition, think about it and then react correctly is a very short period of time.

 

We dont know what we dont know.

 

[Thruster88]

4 hours ago, Garfly said:

But, to reiterate, that action might have been the (expected) reaction to a double engine failure rather than the cause of it:

 

“Here (in the AAIB prelim report) there is a reference to the pilot cutting off, let’s assume that the pilots cut off both the switches and then put it back again. Now that’s exactly what you’re supposed to do as per the checklist if you lose thrust on both engines."  Capt. Sam Thomas.

 

See the minute from around 07:30 

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

 

If there had been an engine failure or an almost mathematically impossible double engine failure BEFORE the cut off switch movements it would have shown up on the flight recorder as a reduction in N1, N2. THEY WOULD HAVE PUT THIS IN THE REPORT.