Posts by user "JustusW" [Posts: 28 Total up-votes: 0 Pages: 2]

JustusW
June 13, 2025, 16:31:00 GMT
permalink
Post: 11900677
Originally Posted by Right Way Up
If they retract flaps their speed does not necessarily increase.
Correct, but if they retract flaps while the engines are producing takeoff thrust and they are somehow losing altitude they definitely should speed up.
There are strong reasons to doubt the flaps had anything to do with the accident, I agree with the following sentiment completely:

Originally Posted by nachtmusak
I wonder if (given all the facts and rumours about the situation so far) the flaps would be so high on everyone's minds if they weren't already a hot topic from the initial, largely baseless speculation that they somehow took off with flaps retracted.
I want to thank everyone in this thread for the wonderful information provided so far. Since there were a few mentions earlier on of possible software/throttle interactions:
I was taught (only as familiarization for my job as ATC) that during takeoff the pilot flying should have their hand on the throttle levers. Is that generally correct? If yes, will changes to throttle settings always be reflected in the actual physical position of the throttle levers or are there situations where the actual commanded throttle could differ from the physical lever position?
The interaction with the TCMA in particular is of interest to me.

Regards,
Justus

Subjects: None

JustusW
June 16, 2025, 09:42:00 GMT
permalink
Post: 11903330
Originally Posted by Burnt Fishtrousers
Im a layman who knows nothing and am just a PPL and am fascinated by the technicals.So does the computer store the recommended flap setting given all the information entered and then decide whether the actual setting used is appropriate and spits out a warning of checklist complete?what would happen if use of the full runway was entered into the computer, but actually they entered at an intersection, surely the info would be wrong ?...
The 787 in particular has a system that is fully automated for takeoff calculation. That includes Takeoff Distance, all relevant airspeeds, etc and uses combined sensor data to make pilot error in calculations exceedingly unlikely.

In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end.

Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground.

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

JustusW
June 16, 2025, 09:42:00 GMT
permalink
Post: 11903756
Originally Posted by Burnt Fishtrousers
Im a layman who knows nothing and am just a PPL and am fascinated by the technicals.So does the computer store the recommended flap setting given all the information entered and then decide whether the actual setting used is appropriate and spits out a warning of checklist complete?what would happen if use of the full runway was entered into the computer, but actually they entered at an intersection, surely the info would be wrong ?...
The 787 in particular has a system that is fully automated for takeoff calculation. That includes Takeoff Distance, all relevant airspeeds, etc and uses combined sensor data to make pilot error in calculations exceedingly unlikely.

In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end.

Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground.

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

JustusW
June 20, 2025, 17:45:00 GMT
permalink
Post: 11907155
Originally Posted by Kraftstoffvondesibel
1/Would the recorders lose access to aircraft data streams when engine power is lost, at least temporarely making the cockpit area mic recorded by battery power on the front recorder the only source of information ?
2/The recorders only draw 20W, why is it the front with reserves only for 10 minutes? Can you even buy a battery that small giving 28VDC? Why is such a limited solution selected?
( For reference, This battery gives about 9 times that: <url removed> )
In reverse order, and the first one being very speculative: The type of battery will likely be highly specific for the usecase, here rugged before anything else. Likely specialized chemistry or one of those hybrid solid state ones. Commonly they trade capacity for other features.

Regarding the recording feature, there's three types of microphone commonly used nowadays: Condenser and Ribbon type are somewhat fragile and require power to record audio while Dynamic type is basically a reverse speaker and is considered rugged. There's an off chance that a Piezzo microphone would be used here as they are basically indestructible but usually reserved for recording while in contact with a large sound transducer. My guess based on that is that we're looking at a dynamic microphone with a run of the mill preamp.
Depending on the actual electric setup this would yield a handful of different possible installations:
1) The "Cockpit Area Microphone" (hereby christened CAM because I like abbreviations) is a self contained unit consisting of a Microphone, a preamp and AD converter. This would mean while provided power the digital recording could be passed to either EAFR.
2) The CAM is a self contained unit consisting of a Microphone and a preamp. This would mean while provided power it could send an analog audio signal to the forward EAFR no problem, but would potentially struggle generating enough of a signal to be picked up by the rear EAFR.
3) The CAM is just a Microphone. This would mean it requires either no or very little power (even Condenser Mics usually require only Milliwatts) but the signal would be very hard to send over long distances and would require the EAFR to have a preamp.

In general it is audio engineering 101 to place a preamp as close to the source as possible to avoid noise. Thus I would rule out 3. It has both ups and downs to convert the analog signal to a digital signal, and there is a possibility they'd do both. In either case I am confused from an audio engineering standpoint why the rear EAFR would not pickup audio from the CAM if the forward EAFR does. Unless the rear EAFR is fed (audio) data only via BUS, which would be an interesting choice.
Also keep in mind that historically the CVR was also located in the tail section and very much received an analog signal over the entire distance. There's really no technical reason this wouldn't be possible, I routinely use far longer cables when running audio signals at concerts and those can't use compression because it would dumpster sound quality.

So, yeah, I don't understand why there would be a mismatch between the recordings of either EAFR, unless there was something else preventing all signal transmission towards the rear EAFR. The CVR in the rear has been a thing for 80 years now.

Regards,
Justus

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  CVR  Cockpit Area Audio  EAFR

JustusW
June 21, 2025, 17:04:00 GMT
permalink
Post: 11907907
Originally Posted by Lead Balloon
And I reiterate the point that the TCMA is "just software". I haven't seen anyone dispute the suggestion that the thing 'common' to all 4 channels of the TCMA is 4 copies of software.
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:
if ( happy == true ) {
print("I'm happy!"
}

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




Last edited by T28B; 21st June 2025 at 17:25 . Reason: Formatting making this easier to read for the layman. Nice post.

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

JustusW
June 21, 2025, 20:40:00 GMT
permalink
Post: 11908040
Originally Posted by JPI33600
Can you provide a source for this?
Sadly I'm unable to post links or I would have done so in my original post.

Originally Posted by JPI33600
I ask because when I look for info about FADECs generally and FADEC 3 more specifically, I find this kind of documentation (notice the mention of FADECs in the lower left corner):
... which is part of a larger Powerpoint presentation by Ansys, explaining that these products are developed with SCADE development workbench, generating either Ada or C code, and that the resulting code runs under a microkernel realtime operating system:
First off I should note that what I wrote is a massive oversimplification. I'd expect that neat metal box with the nice rugged connectors that Safran shows on their homepage to contain an ungodly mess of microcontrollers, ICs for signal conditioning, the FPGAs I mentioned and components that are well beyond my understanding of electronics. But from personal experience with a certain aircraft related company operating in Munich I can tell you that marketing level slides like you showed are so far removed from the technical reality that they might as well be fan-fic.

Originally Posted by JPI33600
Now, obviously enough, a CPU can be embedded in an application-specific FPGA, but it would still execute machine code. And from my experience in other embedded systems development, current CISC or RISC CPUs have more than enough computation power to implement command and control on a modern turbofan.
I agree with your observation that current microcontrollers are more than capable enough of dealing with these types of real time computation, but keep in mind that the Boeing 787, and thus its FADEC, had its first flight in 2009. Back then I would be rather more careful with that statement. Mostly because I would have just started my Computer Science Degree at the time XD

But maybe I should explain how I've arrived at the post above. I've basically spent the past few days on and off scavenging anything I could find on the 787 FADEC specifically. It was mentioned in this thread or the old one that the 787 uses the Safran FADEC 3, so my primary jumping off point was the Safran website and the information available on it. That plus a couple of press releases namely by Actel about their flash-based ProASIC3 and ProASICPLUS FPGAs was the evidence I used to arrive at my conclusions above. I can't for the life of me find the quote about the dual signal conditioning FPGAs anymore, but they are in there as far as I can tell.
Overall information on the actual inner workings of these things are so sparse that outside of a few patents (keyword: configurable CPU) I was hard pressed to find anything at all to be honest. This all not being helped by me now finding references to my own post, thus having created my very own Woozle. Hooray.

Originally Posted by skwdenyer
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).
I have only looked into the Safran FADEC 3 used on the 787 with the GEnx-1B engine. The system was very innovative for its time and uses technology not previously used on FADECs to my knowledge. Even saying that, this could be one of those "technically true" kind of statements. My intention was to highlight that due to the totality of the processes and architectural style of these types of computational device the typical kind of "software error" or "bug" was basically impossible and that we'd be looking at something way further back with implications for the base requirements. I merely want to correct the implied misconceptions about the "software" being used here. As I said, FPGAs are just very different kinds of beasts.

Originally Posted by Furr
"it is basically impossible for a "bug" to exist in this system." This is not my experience.There are a lot of bugs in hardware and FPGAs. The guys doing this are real experts and bugs are less common than in software. But they do exist and they can be difficult to reproduce and subtle to diagnose. For someone new to FPGA it can be very intimidating because everything is parallel. It requires a different way of thinking. You can execute 1000 instructions simultaneously.Then various tricks to speed things up or reduce glitches add complexity. For example you may want to count in gray code or one hot instead of binary. Writing bug free FPGA code is very challenging. We cannot assume the FPGA code is free of bugs.
I half agree and half disagree. Obviously I shouldn't have stated an absolute because, yes, it is possible despite multiple layers of engineering coordination that an error occurs at one step or another and is not caught by the multiple layers of checking. My point is that even in normal development FPGAs are well known to be bug resistant due to the way they are programmed. In general we create the logic condition tables using software which then translates our table into an actual FPGA configuration. This process is obviously not immune to faults but highly resistant and most importantly: Can easily be simulated.
Now, in normal "everyday" usecases I'd fully agree with you, but in case of the FADEC we're talking about an FPGA with logic condition tables where every line is likely to have its own separate binder of engineering notes, discussions and recommendations. It is there where any "error" or "bug" is most likely to reside by a considerable margin.

Originally Posted by EDML
I have developed embedded systems for more than 20 years - most in real time applications. I wouldn\x92t expect FPGAs in such systems. As mentioned before modern microcontrollers can easily handle loads like that in a real time environment with guaranteed response times.
They were, and continue to be, a valid and reliable technology for this type of application especially before the extreme proliferation of consumer microelectronics in the last 20 years. The Safran FADEC 3 was designed at basically the same time as the first iPhone. And boy do I feel old now.

Originally Posted by Feathers McGraw
Now, I am sure that the state of the art has moved on a lot since I was heavily involved in this sort of engineering but I can say that when my colleagues were prototyping ASICs (which are application specific devices that are not programmable like an FPGA) using FPGAs because it can be reprogrammed to cure bugs found in the code that created it I am absolutely sure that it is possible for a latent bug to exist in what has been built despite extensive testing being carried out. I well remember sitting down with an FPGA designer and a software engineer and showing them a situation where one of my radio devices was not being commanded to transmit, they refused to believe me until we captured their output signals in the failed state and I was thus able to prove to them that it was their logic and code that was failing and that my radio system was fully working except it couldn't possibly transmit when its enable line was inactive.

I would therefore never state that an FPGA-based FADEC is infallible. The devil will be in the detail of the functions contained within the devices and how they interact with each other and how the original logical functions are described and specified and then coded and checked for logical errors before getting on to the actual physical reality of the FPGA manufacturer's design and development system that bolts on to the back of the source code. If the FPGA devices are being pushed anywhere near the edge of their performance envelope, just like an aircraft things can go wrong. If a design begins with a device that is only just large enough in terms of how many logic blocks and routing channels are available for the logic required it's almost a certainty that development will take it to this area of its performance and a lot of tweaking may be needed which means that even more testing will be needed to be reasonable sure that it does what it is supposed to.
I realize that my post is a massive simplification of the topic, considering the intricate details that are simply unknown to the general public in a system as complex as a FADEC I certainly agree that things can go wrong. What I wanted to point out is the reliability of the last steps versus the design and requirements engineering phase. In general software development bugs will happen at any stage with basically equal likelihood. Given the way the standard processes around FPGA development alone would influence this probability towards the design and requirements engineering stage and then combining it with how it is handled in the Aerospace Sector I felt it was justifiable to state the extreme mismatch in probabilities of error the way I did. With the system being in operation for this length of time I do still feel comfortable with my original statement although I would now decorate it with a little * for the reasons mentioned by you and others.

In the end I hope it was useful for understanding where the reluctance of apportioning blame to these systems originates and ​​​​at the same time talk about some pretty nifty tech that I know few Software Engineers will ever deal with in their entire career. I do still find the idea of a fault (with the understanding above of where that fault originates) in the FADEC a convincing possibility, it's merely the nature and location of that fault that I felt could benefit from some more specifics in regards to the nature of how they were most likely to actually happen. I would love to actually hear more about how the FADEC 3 is structured internally and which components it uses, but I suspect that those who know are under NDA.

Regards,
Justus

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

JustusW
July 14, 2025, 19:04:00 GMT
permalink
Post: 11922436
Upfront: Sorry for my initial post on the topic, like some other people in this thread it obviously touches a nerve and was rightly removed for exceeding the rules of civil discussion.
This is my attempt to shed a bit of light on why I find pushing theories of suicide very objectionable at this point in time.

Originally Posted by Winemaker
Considering that there are more than 100,000 flights/day worldwide I think you are off by several orders of magnitude.
Let's actually run some numbers here.

https://www.boeing.com/content/dam/b...df/statsum.pdf gives us a nice statistic over the last 20 years and also has this little tidbit:
"965 million departures since 1959. 63% of those departures were on Boeing airplanes. (609 million on Boeing airplanes)"
For the last 20 years I'd eyeball an average of between 20-25 million departures per year. So 400-500 million flights in just 20 years. Maybe let that sink in for a moment. We have doubled the total number of flights in the 20 years since 2005.

In that timeframe we have:
Nov 2013, LAM 470, 33 fatalities, confirmed by CVR
Mar 2015, Germanwings 9525, 150 fatalities, confirmed by CVR

There are additionally these:
Mar 2014, MH370, 239 fatalities, no final report, no information available
Mar 2022, CES5735, 132 fatalities, no final report, media reports claiming pilot suicide, strong counter by the investigating agency: "CAAC has previously said speculation surrounding the crash had "gravely misled the public" and interfered with accident investigation work."

Both confirmed cases in that time have a very clear pattern that does in no way resemble the Air India Crash.
Even beyond that timeframe no confirmed pilot suicide involved any measures against discovery by the departed.

There is speculation regarding Silk Air 185 because the CVR failed to record the relevant part of the accident, but it is firmly in the "debated" category.

But we can ignore all of that. Even if we put any theoretically possible Pilot Suicide into the equation one fact remains: The actual likeliness of pilot suicide has not changed. There were 2 confirmed prior to 2005 and 2 after and 2 suspected prior to 2005 2 and after. And that is despite a higher sensitivity and a more stressful job as well as significantly increased environmental stress factors. Obviously we are talking about, statistically speaking, numbers too small for analysis, but all of this is actually well within expected parameters. The recent years have seen a focus on mental health in general in many countries worldwide, and mental healthcare availability is growing in most countries. And here the US is a great example as far as aviation goes: https://casten.house.gov/media/press...tion-committee With this bill whose merit can be assessed by the people supporting it: " The legislation is endorsed by the Pilot Mental Health Campaign, Air Line Pilots Association, Airlines for America, the National Air Traffic Controllers Association, National Flight Training Alliance, the National Business Aviation Association, and NetJets Association of Shared Aircraft Pilots (NJASAP)."

Summing up I would like to point out that there are good indications that there are no mental health issues involved here. Taking the aforementioned accidents as reference the issues were usually quite obvious once any kind of scrutiny was placed on the individuals involved. The individuals also made little to no effort of concealment in all confirmed cases and while the absence of evidence can be interpreted as indicative of successful concealment it is not proof and cannot be treated as such. Especially when it is documented that the overwhelming majority of suicides do not involve any element of concealment, and the psychological mechanisms at work commonly preclude any thought about what happens after, as far as medical study of the issue is concerned. This does not mean it does not happen, cases of concealment attempts or even partial successes are well documented, but it is a lot less prevalent. In this case estimates range mostly from between 10% to 30% of all suicides being misreported as unintentional injury with massive variation depending on multiple factors like country, ethnicity, gender, sexual identity, etc.

In final conclusion: Anyone can make mistakes. It is possible one or both of these pilots made a mistake. It is also possible that a combination of bad luck lead to an alignment of the holes. In my opinion the inability to receive urgently required medical support is as much a hole in the Swiss Cheese as the worst maintenance or design error imaginable. We know from the previous discussions in all threads on this Accident and the report itself that the pilots were flying their aircraft until they ran out of time and airspace. One cannot demand more from a human being, no matter what the final cause is ultimately determined to be.

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

JustusW
July 15, 2025, 06:26:00 GMT
permalink
Post: 11922684
Originally Posted by wondering
Or the handling pilot is trying to put the blame on the monitoring pilot. Apparently, the cpt had medical issues.
Please cite sources for such a claim. There certainly have been media reports and clickbait implying as much, but when you look into them the actual story is that of a mentally healthy adult dealing with perfectly normal situations in life in an appropriate manner.
His mother died and he took some time off to grief. He later returned to flying status and was openly contemplating early retirement to spend time with his Dad. There is absolutely nothing indicating any sort of mental health issues. Post accident it is normal to pull medical records. There can be many reasons for this, be it toxicology coming back weird due to the fire or any of a myriad other reasons imaginable that require reference data.
Also note that the PF was the FO not the Captain and that the report does not say which pilot said what.

Originally Posted by wondering
Could there have been a third person in the cockpit tempering with the FCSs?
This was discussed multiple times already. The report does not mention it in any way shape or form. There is no reason to believe the report would leave out such a crucial detail.

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

JustusW
July 15, 2025, 08:00:00 GMT
permalink
Post: 11922728
Originally Posted by Sizzling_foil
Apparently mentally healthy. Getting a medical signed off isn't exactly an iron-clad guarantee of mental health, but you're right that some commentators are trying to sensationalise the consequences of normal but testing life events.
The captain reportedly took bereavement leave in 2022 after the death of his mother. The only other source for any claims about his medical history were made by a person named Mohan Ranganathan, a former Pilot who had until then publicly refuted claims of Pilot Suicide. He had supposedly "heard [that] from several Air India pilots". I have no reason to believe that random Air India Pilots would be privy to the reasons for any type of leave another pilot was taking. I have good reason to believe that a man like Captain Sabharwal would have been a great topic for baseless gossip.

So everything beyond the bereavement leave is based on statements by one of the many "experts" opining publicly for clout or money based on rumors from people who have no way of knowing what they are talking about. The list of baseless false statements by those experts is getting a bit long. If there was reason to believe Pilot Suicide we would expect Law Enforcement to be involved and the homes of both pilots to have been searched. Either this was done completely evading public notice, which I find hard to believe in such a high profile case, or it was not done at all. I find the latter option the more believable of the two.

There is no need to put any kind of emphasis on the "apparently" part. Obviously we are only looking in from the outside. But there is zero evidence for mental health issues and several indicators for this to not be the case. Taking time off to grief for a parent is a healthy and normal way to deal with a tragic life event like this. It shows that the Captain was both emotionally and financially stable enough to assess and prioritize his personal needs.


Again: Human Error is quite obviously a leading theory right now based on the preliminary report. Ascribing any kind of intent not based on factual information is not a good idea.

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

JustusW
July 15, 2025, 08:10:00 GMT
permalink
Post: 11922732
Originally Posted by Shep69
It\x92s not a simple mistake.[...]
I guess there might theoretically be a way to snag them with loose clothing (like having a very frayed sweater with holes in the sleeve putting one\x92s arm in a really strange place) somehow and while pulling to free it manage to pull them out and down but I\x92m going to put this in the asteroid hitting earth category.
There have been numerous examples of healthy individuals making lethal mistakes out of the blue. Whether you call it "brainfart" or Action Slip, it's a real thing. And considering that multiple asteroids have hit earth even in our lifetime you might want to reconsider your risk categorization

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

JustusW
July 15, 2025, 10:26:00 GMT
permalink
Post: 11922807
Originally Posted by clearedtocross
Lets assume the perliminary report contains facts and lets give the pilots the benefit of doubt. What electrical/electronic failure could produce the simultaneous shut down of both engines?
This has been discussed to death previously. I suggest looking for tdracer's excellent insights into FADEC design and implementation. From the beginning we've been discussing various very rare types of circumstances. Based on the preliminary report we can now lay most of those to rest.

Originally Posted by tdracer
The fuel switch discrete doesn't really get used except for engine start - if it falsely indicates shutdown (on one or both channels), the FADEC won't do anything if the engine is already running. All this will set maintenance faults - and associated EICAS Status messages (L/R ENGINE CONTROL or ENGINE C1). I doubt that would be recorded on the DFDR - it would go to the QAR but that's unlikely to survive a crash. It would also be logged in the FADEC NVM - but again no guarantee that would survive either (although when the Lauda 767 crashed due to the thrust reverser deployment, the DFDR was destroyed but the FADEC NVMs both survived - much of what we know about that crash came from the FADEC NVM.)

Again, not familiar with the specifics of the 787, but on the 747-400/-8, one pole of the fuel switch feeds EICAS - which uses it in various message logic - and sends it out to any other aircraft systems that use it. There is "Digital Flight Data Acquisition Unit) DFDAU (pronounced Daff Du) that takes all the various system digital signals, sorts them and provides them to the DFDR and QAR. The 787 has something similar to the DFDAU but I don't recall what it's called.
Which actually brings me to this one because I would like to ask for a bit of clarification: By "fuel switch discrete" are you referring to the Fuel Control Switches discussed in the preliminary report?
I would assume from your statement, that if a mismatch in the NC/NO signal on the switch was detected the FADEC would not direct the Fuel Cutoff Valves to close (as far as the types you are familiar with are concerned), is that correct?

The report states:
[...] at about 08:08:42 UTC [...] the Engine 1 and Engine 2 fuel cutoff switches transitioned from RUN to CUTOFF position one after another with a time gap of 01 sec. The Engine N1 and N2 began to decrease from their take-off values as the fuel supply to the engines was cut off.
So this would then mostly preclude the possibility of one or both switches being faulty electrically.

The report then states:
As per the EAFR, the Engine 1 fuel cutoff switch transitioned from CUTOFF to RUN at about 08:08:52 UTC. [...] Thereafter at 08:08:56 UTC the Engine 2 fuel cutoff switch also transitions from CUTOFF to RUN.
There is a 10 second gap between cutting fuel and re-enabling it and a 4 second gap between switches during re-enabling. Is there a mechanical reason why these switches would be slower to operate in either direction? There are obviously reasons such as startle factor and stress that might negatively affect the speedy operation of switches by anyone, but I am nonetheless curious if this might not be a pointer to some sort of mechanical issue after all, such as asymmetric wear or FOD.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): DFDR  Digital Flight Data Acquisition Unit  EAFR  EICAS  FADEC  Fuel (All)  Fuel Cutoff  Fuel Cutoff Switches  Preliminary Report  RUN/CUTOFF  Timeline (Preliminary Report)

JustusW
July 15, 2025, 10:41:00 GMT
permalink
Post: 11922820
Originally Posted by sorvad
One thing that is confusing from the report is the fact that the thrust levers were found in the idle position yet the EAFR data recorded them in the takeoff thrust position.
To quote the preliminary report for completions sake:
The thrust lever quadrant sustained significant thermal damage. Both thrust levers were found near the aft (idle) position. However, the EAFR data revealed that the thrust levers remained forward (takeoff thrust) until the impact. Both fuel control switch were found in the \x93RUN\x94 position. (fig.13) The reverser levers were bent but were in the \x93stowed\x94 position.
The reverser levers are made from Aluminium as far as I know? So anything capable of bending them would certainly be capable of displacing the Thrust Levers.

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

JustusW
July 15, 2025, 10:55:00 GMT
permalink
Post: 11922831
Originally Posted by hec7or
It is also part of the evacuation drill, practiced regularly during recurrent training in the simulator. If a high stress situation had developed after V1, a "brain fart" may have resulted in the deliberate but unintended switch selection.
One of the initially discussed variants was inadvertent operation of the Fuel Cutoff Switches instead of putting up the landing gear. There was some pushback against that idea based on the position of the landing gear. As far as I recall the observed position of the landing gear was ultimately deemed to be caused by loss of hydraulics, and not as caused by interruption of the raising operation, making it fully compatible with the preliminary report. It's curious that the report does not mention the positive rate and gear up call out, either for its absence or it being made. It does note that the landing gear lever was in the down position, which isn't unusual for a severe event just after V2 but also in line with the theory.

With what we know now from the preliminary report that option seems to be a good candidate as the source of initiation for an action slip. Both the PF instead of calling Gear Up Action Slipping and operating the Cutoff Switches, or the PM instead of calling Positive Rate doing so would fit that scenario and timeline.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Action slip  Fuel (All)  Fuel Cutoff  Fuel Cutoff Switches  Gear Lever  Preliminary Report  V1  V2

JustusW
July 15, 2025, 16:08:00 GMT
permalink
Post: 11923051
Originally Posted by Mrshed
Firstly as point of pedanticness, its actually potentially 2 to 6 seconds, not 3 to 5 seconds (albeit almost certainly the distribution probability says within 3 to 5 seconds).
Important thing about sampling rate: It mostly provides an _upper bound_ for the time between two events. The lower bound is determined by the length of measurement and the resulting gap between measurements. Example: Sampling at 1Hz with a measurement taking .1s we have an upper bound for the time between two events occuring in sucessive measurements of 1.1s and a lower bound of 0.9s. But if we take longer measurements this can lead to very different results! 1Hz sample rate with measurements approaching 1s may result in as little as a few milliseconds between two events recorded as being 1 sample apart.

This is the reason why a common rule of thumb is that to observe a signal at any given frequency you need to have at least twice that frequency in sampling rate. Unless someone with actual knowledge of the signal pathway comes along I would be very cautious with any time interval close to the likely sampling rate. A difference of 1 second may be a real world difference way less than that.
I'm unaware what sort of debouncing is used in these systems, so can't comment on that.

Subjects: None

JustusW
July 15, 2025, 17:30:00 GMT
permalink
Post: 11923102
Originally Posted by MarineEngineer
The probability on one flight of a pilot suicide is very low. But there have been an estimated 600 million departures since the year 2,000. And about 8 strongly suspected incidents of suicide.
That translates to a 1 in 75 million chance per flight.
1982 JAL350, confirmed
1994 RAM630, confirmed
1997 SilkAir 185, NTSB says confirmed, Indonesian NTSC says undetermined, private investigation blames a technical fault
1999 EgyptAir 990, confirmed
2013 LAM470, confirmed
2014 MAH370, no report, no evidence
2015 Germanwings 9525, confirmed
2022 China Eastern 5735, media reports of pilot suicide strongly rejected by investigating agency, no report.

Excluding the last one because the investigating agency explicitly called reports of pilot suicide false we have 7 cases since the beginning of commercial aviation. 2+1 suspected cases since 2000. That's 1:300.000.000 to 1:200.000.000. Actually I erroneously included the last one in my previous posts. I don't think including a case where the investigating agency explicitly refuted claims of suicide is valid.

Last edited by Senior Pilot; 15th July 2025 at 20:59 . Reason: Edit quote

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

JustusW
July 15, 2025, 17:49:00 GMT
permalink
Post: 11923123
Originally Posted by Engineless
The STAB cutout switches are located next to the Fuel cutoff switches. What did Air India\x92s on duty AME do as part of their troubleshooting? Were panels removed to gain access to the rear of the switches and wiring? What about wiring and data connections elsewhere? What may have been disconnected/disturbed as part of this process? It would not be the first time that an engineer had innocently done something that later caused an accident. And I haven't read anything about possible nefarious action by a (disgruntled?) engineer - but I've seen lots of accusations directed at the pilot(s)...
I would stay away from assuming any intentional harm as it goes against the definition of safety I learned at Eurocontrol: Safety is the absence of unintended harm. Safety Culture and Security are so often mutually exclusive that I don't consider security considerations worthwhile in the context of aviation accidents.
Wires or wiring is mentioned twice in the report:
The wiring from the TO/GA switches and autothrottle disconnect switches were visible, but heavily damaged.
The aft EAFR was located on the roof top of Building A on 13th June 2025. The EAFR had impact and thermal damages to the housing. The wires were protruding from the housing and the connectors were burnt.
Considering the state of the rest of the components, with basically everything showing signs of burn damage, it will be a hell of a puzzle and very time consuming to reconstruct that and nigh impossible to find any source of error there. I was actually intrigued by the potential for FOD. But I'd imagine they would have been able to identify anything pretty easily.

While severely burnt the switches are still solidly in place and anything that was lodged in the switch housing itself would likely still be there. And I guess it would also be unlikely for FOD to equally impact both switches. I think I just talked myself out of the FOD theory.

Originally Posted by Engineless
C) One of the pilots unknowingly operated the fuel cutoff switches.
I find option C to be at least a productive train of thought because it may provide methods of mitigation. That is after all what we're trying to achieve in discussing this kind of accident. I would expect or at least look positively on a suggestion to use the Embraer model for operating the cutoff valves. While it introduces a secondary element that may fail, requiring the Throttle Control Levers to be at idle just seems like a good idea. How is this handled by Airbus?

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

JustusW
July 15, 2025, 18:26:00 GMT
permalink
Post: 11923158
Originally Posted by MarineEngineer
Whether it is four or eight does not really change my argument. Rare events can happen quite often when there are millions of flights.
It is nonetheless important to observe relative likeliness and circumstances when looking at unlikely events. Given the circumstances and total lack of any signs of mental health issues it is by far more likely that a simple human error occurred. It may be uncomfortable to consider that brain 1.0 has potentially lethal flaws, but it is a valid concern in the process of improvement through safety culture and learning from accidents. There is a reason CRM is now a staple in pilot training at almost any level from ultralight hobbyists to commercial professionals.
It's kind of amazing and terrifying that there is a set of switches that can cause this kind of accident with this kind of immediacy. Imagine having a button in your car directly next to your gear selector that will make the car suffer an immediate highspeed crash if touched under the wrong circumstances. I personally would not want that button there. Or if it had to be there I'd want there to be a few really good measures preventing anything that included "fiery death" and "me experiencing".

Originally Posted by andihce
Originally Posted by JustusW
How kind of you to so thoroughly engage with my overview of the facts. Feel free to point out any "abuse of statistics" I made in my post. It's not exactly rocket science to divide the number of known and suspected suicides by the number of departures...
To address this directly, the critical flaw is what a statistician would call " a posteriori analysis ".[...] The statistic you have simply can't be properly applied to the situation you are attempting to apply it to.
A major part of statistical analysis is a posteriori. It is not invalid or critically flawed methodology. And of course it can be applied here in the manner I have chosen. I have not used it to argue anything, but merely as foundation for an examination of the actual cases and to refute the false numbers thrown around here previously. Namely the claim that more people have supposedly died recently to pilot suicide than to any other cause. Which is simply false.

I have specifically examined the actual incidents of suspected and confirmed pilot suicide and contrasted their significant differences with the Air India accident. I have concluded based on those differences and the known data about behavior of people committing suicide that the Air India accident does not show even marginal overlap with any confirmed or suspected cases of pilot suicide and is inconsistent with our general understanding of the mental conditions leading to suicidal behavior. I have not, and will not make a statistical argument against this case being pilot suicide. I will however refute attempts at misrepresenting the statistical facts about pilot suicide.

The only reason we are talking about pilot suicide is that this is now likely to be a case of human error and some people are apparently unwilling to entertain the thought of human fallibility even in the total absence of any indication of a mental health issue, let alone crisis.
We know with absolutely certainty that people very rarely make lethal mistakes out of the blue that fly in the face of the entirety of their training and normal routine behavior. This should not be a hot take. Doubly so in the context of a Safety Culture that has majorly contributed to that very knowledge.

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

JustusW
July 16, 2025, 10:23:00 GMT
permalink
Post: 11923614
Attention, Wall of Text incoming. Take appropriate precautions and fasten your seatbelts!

Originally Posted by andihce
I will say that in reading your earlier post, I came away thinking you were arguing for the unlikelihood of suicide in this case, at least in part because it is unlikely in the world of commercial aviation as a historical fact. If that's not the case, I apologize. But I will add I think other commentary here has fallen into this trap, as discussed in my referenced post.
It is a bit difficult to not appear to use statistics in this fashion when trying to refute people using made up numbers and stories as argument.

Originally Posted by B2N2
I think we can move away from switch mysteriology and muscle memory and simulator games. [...] The CA had taken bereavement leave 3 years ago and according to Indian sources leave for mental health reasons?
If you had read the articles you quoted you might have realized that the basis for these "media reports" is a single individual who "heard from some Air India pilots". The supposed source wouldn't even have any way to actually know about the claimed information. Unless you want to elevate the Company Rumor Mill to hard evidence standard. This stands against:

Originally Posted by za9ra22
TATA, the parent company of Air India, pushed back, saying, “He did take bereavement leave in 2022 following his mother’s death, and his medical records were submitted as part of the investigation, and the preliminary report did not find anything noteworthy.”
Can we please stick to the actual facts, like za9ra22, and not spread baseless rumors that are self contradictory to begin with?

Originally Posted by DutchRoll
Lots of stiff competition for "most implausible theory" going on but I think my favourite so far is "could've mistakenly moved fuel control switches to cutoff when going for gear up selection". Geezus. 🤦‍♂️
I find this a particularly concerning statement coming from someone who claims to be a pilot. Things like "Action Slip" and "Mental Load" should have been covered extensively in any CRM related education. If you think you are exempt from that kind of failure you are rejecting some very costly lessons learned over the last 50 years of accident investigation.

There have been many accidents where unindicated or even counter indicated action was taken by one or more pilots involved. As discussed in the first and second thread extensively many pilots could report incidents where they observed someone retracting flaps instead of gear. There have been major fatal accidents with pilots shutting down healthy engines instead of surging or burning ones. There's good reason the 787 has extensive takeoff configuration warnings, because we have had accidents and incidents with unsafe configurations taken to takeoff, beyond and sometimes even into a crash. Humans make mistakes. It is the goal of Safety Culture to prevent those mistakes from causing harm.

Originally Posted by AirScotia
The. question about enforcing idle throttles before CUTOFF has been discussed voluminously on this thread.
It was certainly mentioned. I'd not say it was discussed in any big way. Someone mentioned that for Embraer this is indeed the default, I haven't really found anything beyond that, despite considering it a worthwhile train of thought and possible recommendation as a result of this investigation.

Originally Posted by Mrshed
But TL;DR - I'd posit that the rate of truly experienced mental health issues experienced in pilots is higher than whatever rate almost anyone is thinking.

Around 12% of people globally have a mental health issue at any given time - even being incredibly conservative, the rate in pilots is clearly going to be at least in single whole figure percentages (which is far from rare).

Obviously the majority of these issues are not going to be those with severe outcomes, but some will. And almost all mental health issues tend to affect cognitive ability to at least some level. Slowness in action and fatigue are diagnostic criteria for many of the most common mental health conditions for example.
This is a topic of actual research: https://www.pmhc.org/research
Currently 12.6% of pilots meet the medical threshold for depression, with a slight but below average difference between males (12.8%) and females (11.4%), with 4.1% of all pilots experiencing recent suicidal thoughts. https://ehjournal.biomedcentral.com/...940-016-0200-6

It should be noted that the utilized test (PHQ-9) is considered insufficient to assess suicide risk. Depending on scoring these values could be about average, or significantly below average. Based on their wording I would expect the latter, because their methodology does not specify severity.*1 Results of 0-4 points suggest no intervention necessary, 5-9 (classified as mild) simply suggest retaking the test after a few weeks. Research shows that for the general public Major Depressive Episodes have a prevalence of ~5-10%, with the prevalence of minor depression being less studied but significantly higher than major depression. There is also significant symptomatic overlap of mild depression with stress related conditions such as "Burnout" (if you know, please don't, this conversation is already complex enough without bringing that in). Considering the prevalence of stress in the industry I am actually surprised the numbers here are not higher. The lesser delta between males and females could be indicative of just such an issue, meaning that based on the data available the number of pilots actually suffering from depression could be less than even the comparably low number reported here. The actual suicide risk is usually orders of magnitude below even that but not easily covered in this data context due to the test used.

Cognitive impact is highly variable depending on the individual, actual symptoms and severity. It would be wrong to assess that 12.6% of pilots are a risk factor from this data. Quite the opposite, in fact. After the Germanwings crash the topic was discussed and has reached the awareness threshold for many. Mild cases usually require little to no intervention beyond raising awareness and helping the brain fix its chemistry through positive reinforcement. This can be as simple as taking PTO, reducing work hours, or focusing on social or physical activities. In the past 10 years these kinds of low impact measures have been made more readily available, most notably during the Covid-19 pandemic and the resulting turmoil.

Further political activity has lead to some positive action as well. I already mentioned the recent success of the Pilot Mental Health Campaign getting legislation through Congress for improvements of the outdated FAA guidelines on mental health in an earlier post. Similar efforts are underway globally, be that internal review within regulatory bodies, or political movements.

Originally Posted by slats11
As a critical care physician (with AVMED background), these last few years we seeing unprecedented rates of self-reported stress, anxiety, depression, and deliberate self-harm. This is being experienced in most western countries (perhaps globally, but I have less direct knowledge of non-western countries). It is absolutely off the scale. In my 35 year career, I have never seen anything like the last 4 years.

Sadly, I am confident this phenomenon will result in more incidents like Germanwings, MH370 and this.
Keeping what I wrote previously in mind I would still caution against extrapolating your personal experiences too far. Having family in the field and having volunteered myself I can certainly relate, albeit with far fewer and less impactful personal experiences. The research is obviously lagging and we haven't really understood the impact of the Covid-19 pandemic generally, let alone in all its intricacies. There is indeed an observable global trend. Some correlation has been shown to climate anxiety, but other factors like the deteriorating condition of international relations as well as a global rise in movements against individual rights are obvious sources for this trend as well.
This is certainly a challenge for healthcare everywhere, but I do not consider the data available to be majorly applicable in the context of aviation over the already very current research closer to the industry and GA. The positive impact of what has been done and is being done is highly likely to outperform whatever global mechanism is at work here. It's certainly a very important field of study, but based on the data I would still consider the industry and regulators as a global whole to be on a positive path.

We can certainly discuss this topic further, but I would not currently see it as likely to be causal in this particular case.

Overall I am still not convinced we are looking at an individuals mental health crisis in this case. I have already detailed the massive differences to all known or suspected cases of pilot suicide at least twice. There is no evidence of mental health issues for the Captain or the FO. There is certainly a strong indication for a human factors cause to this accident. And as mentioned above I find the idea of improving the safety of the Fuel Cutoff Switches a worthwhile topic to discuss. No single action, and I see these two switches as a single action just as much as operating both thrust levers, should be able to cause a major accident. I find it perfectly reasonable to require the Throttle Levers be at idle for the Cutoff Switches to work, and in case of an incorrect setting some sort of alert would be appropriate.

*EDIT*
*1: I missed this in my original readthrough, the cutoff is sensibly set to 10, starting with moderate depression. I'd have to look into the classification scheme but from memory both mild and moderate depression fall into the same category as relevant for the following statements.

Last edited by JustusW; 16th July 2025 at 10:37 .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Action slip  FAA  Fuel (All)  Fuel Cutoff  Fuel Cutoff Switches  Human Factors  Mental Health  Muscle Memory  Preliminary Report  RUN/CUTOFF

JustusW
July 16, 2025, 10:43:00 GMT
permalink
Post: 11923626
Originally Posted by 1stspotter
There is just one explanation: one of the pilots deliberately set both switches to cutoff.
Let me fix that statement for you:
"There is a reasonable explanation: One of the pilots set both switches to cutoff."

There is no known evidence for the claim of intent. There are documented instances of pilots making fatal mistakes out of the blue. Human Error is by far the more likely explanation.

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  Human Factors

JustusW
July 16, 2025, 17:14:00 GMT
permalink
Post: 11923864
Originally Posted by 1stspotter
Lets focus on the omit of the report the name of the pilot who said " why did you cutoff" and the name of the other pilot.[...]So it was a choice not to write in the report what was known.
That is not correct. Normal procedure, as mentioned in various posts in this thread, is to only include facts without analysis. Determining which person said something on a compressed recording, likely containing various types of noise, will definitely require some analysis. Your statement is pure speculation and likely wrong. The CAM is per definition recording a lot of things and does not come with a neat automatically generated script with attributions.
A preliminary report can only contain what is certain. The attribution you want is unlikely to be available yet.

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  Pilot "Why did you cut off"  Preliminary Report