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

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:

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

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.

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.

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

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: 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

Sadly I'm unable to post links or I would have done so in my original post.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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:
So this would then mostly preclude the possibility of one or both switches being faulty electrically.

The report then states:
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.

To quote the preliminary report for completions sake:
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.

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.

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.

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.

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:
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.

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?

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".

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.

Attention, Wall of Text incoming. Take appropriate precautions and fasten your seatbelts!

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.

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:

Can we please stick to the actual facts, like za9ra22, and not spread baseless rumors that are self contradictory to begin with?

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.

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.

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.

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.

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.

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.