Posts by user "skwdenyer" [Posts: 20 Total up-votes: 0 Pages: 1]

skwdenyer
June 15, 2025, 00:10:00 GMT
permalink
Post: 11901981
Originally Posted by DrPlokta
There are around 100,000 scheduled flights per day. That means that a billion to one chance happens roughly every 30 years, and can\x92t be ruled out.
Rather more importantly, a billion-to-one chance can happen on the first try with equal probability to happening on some much later test. Low probability events happen all the time. Humans frequently misunderstand this.

Subjects: None

skwdenyer
June 18, 2025, 17:44:00 GMT
permalink
Post: 11905421
Originally Posted by N8477G
I\x92m asking, \x93Whatever the flaw was that initiated these events, how did it remain un-known *until* it produced an accident?\x94 We test and re-test modern aircraft for every imaginable failure mode during the design, certification, and production process. We train and re-train techs, mechanics, flight crew, and everybody else that touches the airplane to be sure a high level of performance and safety is not compromised. Think bigger. Think about \x93the system\x94 as a whole. Apparently the system missed something. What are we not seeing?
To my mind, this points to a potential software issue. 787s have already suffered from 2 separate software issues in which the passage of time causes a major and possibly catastrophic failure - the need to reboot systems before 51 days and 248 days have elapsed, due to poorly-written software. Given that history, the probability of there being a third, previously-unidentified but broadly similar in nature software issue seems surprisingly high. They aren't independent variables.

Such a passage-of-time software issue wouldn't show up in most (or possibly any) testing scenarios. It is the sort of issue that robust QA and static code analysis are designed to catch. But in at least two separate systems on the 787 it has not been caught prior to software shipping. Meanwhile, every new technical post demonstrates the myriad ways in which non-software potential causes are mitigated by redundant design.

The odds of two (or more) redundant mechanical systems failing in precisely the same way at precisely the same moment are very, very small. The odds of identical software on two (or more) redundant systems reaching a passage-of-time bug at precisely the same moment are, by contrast, very much higher. True redundancy would require different software on each redundant sub-system.

Subjects: None

skwdenyer
June 19, 2025, 12:25:00 GMT
permalink
Post: 11905983
Originally Posted by DTA
They comply with a military standard that requires 40,000 cycles though the locking part is tested 20,000 times by just pulling to its full extent. Or something like that. How well that testing matches real world use is debatable.
As a mechanical engineer, I highly doubt that locking mechanism could withstand 20,000 cycles of a human attempting to use the switch whilst locked, or any serious number of cycles of things in the cockpit accidentally dropping on them.

I\x92d be very interested to know the current state of those switches, if they\x92re recoverable.

Subjects: None

skwdenyer
June 19, 2025, 16:12:00 GMT
permalink
Post: 11906161
Originally Posted by StudentInDebt
this isn\x92t the type of switch fitted to the 787 as a fuel control switch, totally irrelevant but has generated yet more nonsense. The switches are spring loaded (or so it feels) in addition to having a massive block to prevent inadvertent operation in either direction. Anyone suggesting they could be accidentally \x93knocked off\x94 is so clueless about their operation it\x92s actually painful to rebut
The type of switch being discussed is the specific type reported as being liable to problems. The SAIB is here https://ad.easa.europa.eu/blob/NM-18...SIB_NM-18-33_1 and specifies a part number for the B788 as 4TL837-3D

That's a TL series switch with 4 poles (the "4" in "4TL"), a "type D" lock (meaning locked out of centre position per the Honeywell data sheet - the "D" in "3D." This is a photo of one:


You can find the manufacturer's datasheet here: https://octopart.com/datasheet/4tl83...ywell-25749542

Problems with critical switches aren't new on 787-8s. For instance, in addition to the SAIB above, there's this AD: https://www.federalregister.gov/docu...pany-airplanes

Looking at the photo above, it isn't just wear that's potentially an issue, but foreign object impingement. There don't appear to be gaitors fitted to these switches in the 788, so the locking mechanisms are potentially susceptible to a build-up of material if not kept clean. There are a range of other failure modes possible, whilst the SAIB specifically describes found-in-the-field problems with these switches.

Yes, they're chunky, and very positive when new. That doesn't mean they shouldn't be discussed.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  Honeywell  Special Airworthiness Information Bulletin

skwdenyer
June 19, 2025, 19:18:00 GMT
permalink
Post: 11906289
Originally Posted by galaxy flyer
In the history of jet transport aviation, both ETOPS and non-ETOPS operations, exactly how many simultaneous dual engine failures have there been, excluding pilot causal ones? I\x92d venture it\x92s zero. Even the old DC-9/Boeing 727 era had none. ETOPS is 40 years on and zero cases, to my knowledge. Modern twins are systematically divided into two separate and independent planes. My bet is all these neat theories based on arcane questions will boil down to some human causal event, excluding Boeing. They might contributory, as in the Delta 767 where the switch design contributed to pilot misaction, but design fault, vanishingly improbable.
Dual engine failures? Or uncommanded dual engine shutdowns?

ANA NH-985, a 787-8, suffered dual uncommanded engine shutdown just after air-ground transition. That was a TCMS "feature."

Baltic BT-139 likewise, resulted in an FAA AD to upgrade FADEC software on a whole bunch of P&W engines.

It isn't unheard of. It may not have been seen at rotation before.


Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  Engine Failure (All)  Engine Shutdown  FAA  FADEC

skwdenyer
June 19, 2025, 21:09:00 GMT
permalink
Post: 11906376
Originally Posted by Captain Fishy
This switch thing is a nothing burger. If you\x92ve ever operated these switches you\x92d know how they feel. They require a very distinct pull and are most definitely either on or off. There is no impossibly balanced in between position.
I agree, if working properly they're very substantial switches. They should be at $1500-$3000 per switch!

But the SAIB is clear - they can be assembled / installed incorrectly, resulting in no lockout protection, with actual failures / anomalies apparently found in the field.

None of which means they were the cause of this crash.



Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Special Airworthiness Information Bulletin

skwdenyer
June 20, 2025, 00:36:00 GMT
permalink
Post: 11906509
A good round-up of dominant themes, including this:

Originally Posted by user989
V. Shutdown of engines by TCMA
A parallel is drawn to the ANA incident. However, this would require not only a fault in the air/ground logic but also a sensed discrepancy between T/L position (not necessarily idle) and thrust output on both engines simultaneously.
You may be at risk of assuming that the air/ground control logic is in some way hard-wired, as opposed to being a function of software. I don't believe we (yet) know this to be true.

We know there has been a bug in the Generator Control Unit software (an overflowing counter) that could lead to simultaneous shut down of all generators and a total loss of all AC power (the 248 days bug).

In the interests of completeness, we should perhaps also consider the possibility of some other previously-unknown software issue capable of creating an uncommanded dual engine shutdown. TCMS is the most likely candidate due to the deliberate separation of other systems from being able to achieve this outcome. The question then isn't whether there's some odd combination of input faults that would confuse TCMS into believing it were on the ground, but rather whether there's any way in which the software side could crash in such a way as to create an anomalous state within the system leading to engine failure. For instance, another overlooked software counter with an unwelcome failure mode.

Or even just a "dirty power supply" (cf all the reports of dodgy passenger-side electrics on this a/c) leading to spurious inputs and unexpected consequences.

Whatever is the cause will likely turn out to be have been a very low-probability event. But unless we have a TCMS expert who can state canonically that (say) the WoW sensor electrically disables TCMS when airborne (as opposed to merely being an input to the TCMS logic) then we cannot say with certainty that multiple inputs would have to have failed / been corrupted in order to reach the end state of this flight.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Dual Engine Failure  Engine Failure (All)  Engine Shutdown  Generators/Alternators

skwdenyer
June 20, 2025, 06:18:00 GMT
permalink
Post: 11906620
Originally Posted by ignorantAndroid
TCMA is simply a bit of software in the FADECs, so it has the same separation as everything else. There's no inter-engine interaction when it comes to TCMA.
There is no inter-engine interaction. But if both FADECs are running the same software then they will potentially behave identically to some bug or external input / condition. That's why software redundancy isn't always redundancy.

Originally Posted by ignorantAndroid
This is technically possible, but of course the FADECs would have the ability to shut down the engines anyway, even if TCMA didn't exist. If there's a software bug, it could involve TCMA but it could easily be somewhere else.
I agree.

Originally Posted by ignorantAndroid
TCMA can't be disabled electrically. It's just software, and all of the hardware involved serves other functions which are still needed while in the air. For example, the FADECs would command the HPSOV closed in case of N2 overspeed. That would have the exact same effect as TCMA.
Thank you. So saying "TCMA would only trigger if WoW and RA have failed somehow" is incorrect? Those are simply inputs to software, which might itself fail badly for other reasons. See the FAA AD to replace FADEC software on certain P&W engines following a previous uncommanded dual engine shutdown.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  Dual Engine Failure  Engine Failure (All)  Engine Shutdown  FAA  FADEC  High Pressure Shutoff Valve

skwdenyer
June 21, 2025, 15:23:00 GMT
permalink
Post: 11907840
Originally Posted by EDML
That doesn\x92t make sense at all. 53% would be around 53t which is reasonable for that flight.
A full fuel load of 100t would have brought them by far over the MTOM as there is only around 8t of load left with full fuel of 100t. My guess with 242 POB and some baggage would be at least around 24t of load. Furthermore the fuel burn for tankering almost 50t for 9h would be enormous.

EDIT: Sailvi767 was quicker\x85
Multiple sources, including BBC, have quoted Amit Shah, Home Affairs Minister, as saying the plane had 100 tonnes of fuel on board. This seems to stem from a direct quote from Shah, in which it is reported he said:

The plane carried almost 1,25,000 litres of fuel, and due to the high temperature, there was no chance of saving anyone.
Using a rough approximation of 0.8kg = 1l leads to the 100t figure. Plenty of other sources for that 1.25 lakh litres fuel quote, including Times of India: https://timesofindia.indiatimes.com/.../121815339.cms

I have no idea if he actually knew how much fuel was on board, or whether he'd simply been told it was "full" and somebody had looked up the capacity (126k litres) and he then quoted that "full" number. Or whether, in fact, there was an excess of fuel. But since that seems so far the only public statement on fuel load, it shouldn't just be dismissed out of hand.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): BBC

skwdenyer
June 21, 2025, 18:31:00 GMT
permalink
Post: 11907969
Originally Posted by JustusW
This has been setting a bit wrong with me for the entirety of the thread. When people say "software" they have an image in their head, and in this case the image is rather unhelpful if not outright wrong.
When we say "Software" we mean things like this:

This is the type of software we are usually subject to in our everyday lives basically everywhere. Your phone, your fridge, your oven, your water heater, your car, etc. pp. ad nauseam.

In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with.

In a normal computer we simply translate code like above into something less human readable but instead interpretable by a microchip or the like. This "machine code" is then run sequentially and does whatever it is meant to do (hopefully). If we were to expand our little happy check above with another condition then our computer would sequentially check these conditions. This opens up a lot of hoopla about timing, especially when interacting with the real world.

Let's say you want to track N1 and N2 in an engine. You'd have to make a measurement, that value would have to go through an AD converter, which writes it to some (likely volatile) storage, where it is then accessed by some sort of (C)PU, transferred to yet another piece of volatile memory and then used in the computation. This takes time because you can't do those things within the same clock cycle.

Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine.

Enter the FPGA.

While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check.

This is very useful for our Turbine Engine, because now we can verify that N2 is smaller than X without delaying our check that the Throttle Control Lever setting is within acceptable distance to N1 and N2, while also creating the appropriate output for all the different bypasses and bleed valves in a modern engine, and so on. The Safran FADEC 3 does this "up to 70 times per second" as per the vendor.

In order to be manageable the actual FADEC consists of multiple different pieces, many of which are FPGAs. At least two are used for so called "input conditioning". This is where we deal with converting messy real world values from sensors subject to real physics into nice and clean numbers. Here our values from the Throttle Control Levers come in, the signal from our N1 and N2 sensors, WOW signal, and on, and on, and on.

This is then changed into logic level signals provided to a different set of FPGAs. Lacking an actual schematic I suspect that this is what sometimes is referred to as "channels". The channel could consist of both a signal conditioning stage and then a logic stage or (more likely) redundant signal conditioning stages feed separately into separate FPGA "channels" are evaluated and then the end result is likely put into yet another FPGA for control output generation.

Why is this important?

Because it is basically impossible for a "bug" to exist in this system. These systems are the epitome of a dumb computer. They do _precisely_ what they are meant to do. The TCMA is simply a set of conditions evaluated just like any other condition in those FPGAs. If there is an "error" then it is in the requirements that lead to the truth table used by these devices but never in the truth table itself. In fact these types of computation device are used precisely because of that very property.

So when people say "the FADEC software" (ie TCMA) has "failed" or "has a bug" what they're really saying is:
The conditions that were experienced in the real world by the system were incorrectly assessed in the system requirements and lead to an undesired output state when taking into account the real world result we would have preferred.
A bit of a mouth full, granted, but an important mouth full. This simply wouldn't be someone missing a semicolon somewhere in a thousand lines of code.

Regards,
Justus
Whilst you\x92re right to highlight the type of software in a FADEC, it should also be recalled that after the dual uncommanded engine shutdown event on the Baltic CS300, the FAA mandated updated FADEC software for all of a family of P&W engines. FADEC s/w can contain what we\x92d call bugs (whether they\x92re mistakes of coding or mistakes of logic in the design assumptions).

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  Engine Failure (All)  Engine Shutdown  FAA  FADEC

skwdenyer
June 21, 2025, 18:33:00 GMT
permalink
Post: 11907973
Originally Posted by DaveReidUK
If only there were an easy way of telling how much fuel had been loaded for the sector ...
I agree. All I\x92m saying is dismissing the only public statement on the matter because it doesn\x92t match what you think is sensible or plausible isn\x92t an especially useful exercise.

What I think we can say is, if the a/c were fuelled as the minister suggested then there\x92d be a major weight issue for the a/c that day. Absent any other info we can say little else.

Subjects: None

skwdenyer
June 30, 2025, 03:42:00 GMT
permalink
Post: 11913342
Originally Posted by Kraftstoffvondesibel
This has also been touched upon earlier in the thread, but it rather seems the cut-off switches are in the same LRU, in close proximity, using the same connector and goes through the same wiring harness. No one was able to say whether it works purely by digital signaling, and goes through any common software, or if it is duplicated by purely direct signaling. There might be numerous failure modes of the cut-off switch design, it is obviously very, very robust and overall sound, since dual failures here have never happened, but this is alredy an outlier event.
If we are to take the TCMA patent at face value, the fuel cut-off switches are directly-acting, not some sort of signalling protocol.

That's a pretty big "if" but here's the patent drawing:

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff  Fuel Cutoff Switches

skwdenyer
June 30, 2025, 12:29:00 GMT
permalink
Post: 11913592
Originally Posted by The Brigadier
We know that the right-hand GEnx-1B was removed for overhaul and re-installed in March 2025 so it was at \x93zero time\x94 and zero cycles, meaning a performance asymmetry that the FADEC would have to manage every time maximum thrust is selected. If the old engine was still on the pre-2021 EEC build while the fresh engine carried the post-Service Bulletin software/hardware, a dual \x93commanded rollback\x94 is plausible. A latent fault on one channel with the mid-life core can prompt the other engine to match thrust to maintain symmetry, leading to dual rollback.
You think the Thrust Asymmetry Protection could kick in and leave the aircraft with little to no thrust?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Dual Engine Failure  Engine Failure (All)  FADEC

skwdenyer
June 30, 2025, 14:04:00 GMT
permalink
Post: 11913652
Posters may like to read this old (2016) pprune thread on 787 engine failure procedures: 787 engine failure procedure

Some interesting comments about how a combination of ATM and derate can lead to some pretty surprisingly poor outcomes, coupled with Boeing advice not to advance thrust levers or engage TOGA.

(edited for poor spelling)

Last edited by skwdenyer; 30th June 2025 at 14:40 .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Engine Failure (All)  TOGA

skwdenyer
July 10, 2025, 00:08:00 GMT
permalink
Post: 11918713
Originally Posted by Magplug
As a 787 operator I can observe a couple of things......

Deliberately cycling the Engine Cutoff switches just after rotate, in response to a dual power loss is inconceivable. You are way too low and slow for it to have any effect and your attention is better devoted to aiming for the flattest area ahead to crash into. Commencing the Dual Eng Fail/Stall checklist memory items is conditional upon both engines being at sub-idle and the aircraft being within the in-flight relight envelope. Neither of those conditions existed.
Given your professional view above, how do you react to the posted Air India 787 manual suggesting that dual engine relight should be attempted at any altitude?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  Memory Items  Relight

skwdenyer
July 12, 2025, 19:31:00 GMT
permalink
Post: 11920773
Originally Posted by KSINGH
to add


In my airline (we don\x92t fly the 787 but our engine masters are in a near identical position on our jet) we have had *multiple* incidents of engine masters being manipulated accidentally in flight. This has involved both flight deck and cabin crew. This has meant a re-emphasis on SOPs regarding the centre pedestal but you still routinely see this broken on the line in minor and major ways from time to time


I think it would be *very* interesting to hear about those incidents, especially those involving cabin crew at this juncture.

Subjects: None

skwdenyer
July 12, 2025, 21:28:00 GMT
permalink
Post: 11920844
Originally Posted by KSINGH
I don\x92t think there\x92s much to say other than they were entirely accidental and inadvertent

in the instances I know of they were in the cruise and thus the flights were almost entirely unaffected (thrust restored very swiftly)
I think the question is *how* fuel switches were accidentally turned off by flight crew, given what\x92s said about their protections?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches

skwdenyer
July 17, 2025, 10:19:00 GMT
permalink
Post: 11924286
If the Captain was suffering from some sort of mental health crisis (not necessarily suicidal depression), all bets are off.

He could just as easily have started to believe he was in a simulator and wanted to throw a curveball at a cocky young FO.

Strange things can happen to the brain. Sometimes they come on very quickly.

It is natural for us all to want to rationalise behaviour, but sometimes it is simply not possible. We may never know what happened in the minds of this crew, even if we manage to know conclusively which person did what.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Mental Health

skwdenyer
July 18, 2025, 01:03:00 GMT
permalink
Post: 11924785
Originally Posted by Iron Duck
Depressed pilots have access to psychotherapy just as other people do. The problem is that using that access appears to be career-terminating.
Just so we're clear, most "other people" in the UK, for instance, don't have access to psychotherapy. NHS waiting lists are years-long; private services are (a) often provided by (being brutal) quacks, and (b) a significant cost that often can't be born. I can't speak for India in this regard, but sweeping generalisations like this are unhelpful. Mental health provision in much of the world is limited to non-existent.

Last edited by skwdenyer; 18th July 2025 at 01:20 .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Mental Health

skwdenyer
July 18, 2025, 01:20:00 GMT
permalink
Post: 11924788
Originally Posted by MedicAn
Not a strong argument against; the majority of completed suicides examined by the US military didn't have indicators of serious MH issues (or suicidal ideation) in either the medical record, nor was family aware.

The study of suicidality is interesting, when it comes up against the examination of an event like this (whether murder/suicide is a possible explanation, why it might or might not be). Non-medical people will often focus on something that's a red herring because it seems strange in the context of a potential suicide, but in terms of the "natural history" of suicide, it might be a pretty common thing. I've been inv with suicide investigation as part of my work, and in some ways it's as frustrating to try to inform laypeople about what norms exist in that field as I imagine it must be for the professional pilots to have dilettantes like me opine on throttles and CRM.

On the topic of family members, etc. I'm not going to go into huge detail for reasons of confidentiality, but suffice it to say I have *far* too much experience of dealing with suicide attempts, ideation and indeed suicidal "success" amongst family members and others. Almost without exception, most family members don't see the signs because they're not looking for them, are generally not attuned to their family members, or simply block them out as something they don't want to consider. Whereas I've prevented more than one suicide by recognising precisely the signs others ignore and acting upon them quickly to intervene.

It is the same reason so many people seem to be able to get away with conducting affairs - so many humans, even humans who claim to be in love with us, are simply not very attuned, aware or observant.

A post-mortem questionnaire of family members is of little worth in determining if signs were present in my view, but more useful in showing how little those signs were seen.

As regards the points made by others up-thread about whether intervention helps, my preference is to use the broken limb analogy. If you speak to your Doctor, or your spouse, about your broken arm, they speak to your brain. If you speak about your mental health issues, they're talking to the injury. Whatever somebody else says to you is mediated through a - for want of a better term - broken interface. The trick (that so many, including in my experience mental health professionals) completely lack is to figure out (iteratively if necessary) how that "broken interface" is interfering, and find ways to get through it. What seems irrational, for instance, is usually anything but.

To be frank, from a risk-management perspective, rather than making mental health issues a career-limiting admission, it would likely be better for every airline simply to provide free (and mandatory, and confidential) counsellor sessions monthly - provide a safe space for all to open up, in the certain belief it will help some of them, and treat it as a prophylactic investment.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Mental Health