2025-06-19T09:30:00
permalink Post: 11905864
https://ad.easa.europa.eu/blob/NM-18...SIB_NM-18-33_1
The FAA recommends that all owners and operators of the affected airplanes incorporate the following actions at the earliest opportunity: 1) Inspect the locking feature of the fuel control switch to ensure its engagement. While the airplane is on the ground, check whether the fuel control switch can be moved between the two positions without lifting up the switch. If the switch can be moved without lifting it up, the locking feature has been disengaged and the switch should be replaced at the earliest opportunity.
Last edited by Senior Pilot; 19th Jun 2025 at 11:13 . Reason: Image
3 users liked this post.
2025-06-19T18:05:00
permalink Post: 11906239
Fuel valves and TCMA software updates?
Commanded engine cutoff - the aisle stand fuel switch sends electrical signals to the spar valve and the "High Pressure Shutoff Valve" (HPSOV) in the Fuel Metering Unit, commanding them to open/close using aircraft power. The HPSOV is solenoid controlled, and near instantaneous. The solenoid is of a 'locking' type that needs to be powered both ways (for obvious reasons, you wouldn't want a loss of electrical power to shut down the engine). The fire handle does the same thing, via different electrical paths (i.e. separate wiring).
As I've noted previously, a complete loss of aircraft electrical power would not cause the engines to flameout (or even lose meaningful thrust) during takeoff. In the takeoff altitude envelope, 'suction feed' (I think Airbus calls it 'gravity feed') is more than sufficient to supply the engine driven fuel pumps. It's only when you get up to ~20k ft. that suction feed can become an issue - and this event happened near sea level.
Not matter what's happening on the aircraft side - pushing the thrust levers to the forward stop will give you (at least) rated takeoff power since the only thing required from the aircraft is fuel and thrust lever position (and the thrust lever position resolver is powered by the FADEC).
The TCMA logic is designed and scrubbed so as to be quite robust - flight test data of the engine response to throttle slams is reviewed to insure there is adequate margin between the TCMA limits and the actual engine responses to prevent improper TCMA activation. Again, never say never, but a whole lot would have had to go wrong in the TCMA logic for it to have activated on this flight.
Now, if I assume the speculation that the RAT deployed is correct, I keep coming up with two potential scenarios that could explain what's known regarding this accident:
1) TCMA activation shutdown the engines
or
2) The fuel cutoff switches were activated.
I literally can come up with no other plausible scenarios.
In all due respect to all the pilots on this forum, I really hope it wasn't TCMA. It wouldn't be the first time a mandated 'safety system' has caused an accident (it wouldn't just be Boeing and GE - TCMA was forced by the FAA and EASA to prevent a scenario that had never caused a fatal accident) - and there would be a lot embarrassing questions for all involved. But I personally know many of the people who created, validated, and certified the GEnx-1B TCMA logic - and can't imagine what they would be going through if they missed something (coincidentally, one of them was at my birthday party last weekend and inevitably we ended up talking about what we used to do at Boeing (he's also retired)). Worse, similar TCMA logic is on the GEnx-2B (747-8) - which I was personally responsible for certifying - as well as the GE90-115B and the 737 MAX Leap engine - the consequences of that logic causing this accident would be massive.
As I've noted previously, a complete loss of aircraft electrical power would not cause the engines to flameout (or even lose meaningful thrust) during takeoff. In the takeoff altitude envelope, 'suction feed' (I think Airbus calls it 'gravity feed') is more than sufficient to supply the engine driven fuel pumps. It's only when you get up to ~20k ft. that suction feed can become an issue - and this event happened near sea level.
Not matter what's happening on the aircraft side - pushing the thrust levers to the forward stop will give you (at least) rated takeoff power since the only thing required from the aircraft is fuel and thrust lever position (and the thrust lever position resolver is powered by the FADEC).
The TCMA logic is designed and scrubbed so as to be quite robust - flight test data of the engine response to throttle slams is reviewed to insure there is adequate margin between the TCMA limits and the actual engine responses to prevent improper TCMA activation. Again, never say never, but a whole lot would have had to go wrong in the TCMA logic for it to have activated on this flight.
Now, if I assume the speculation that the RAT deployed is correct, I keep coming up with two potential scenarios that could explain what's known regarding this accident:
1) TCMA activation shutdown the engines
or
2) The fuel cutoff switches were activated.
I literally can come up with no other plausible scenarios.
In all due respect to all the pilots on this forum, I really hope it wasn't TCMA. It wouldn't be the first time a mandated 'safety system' has caused an accident (it wouldn't just be Boeing and GE - TCMA was forced by the FAA and EASA to prevent a scenario that had never caused a fatal accident) - and there would be a lot embarrassing questions for all involved. But I personally know many of the people who created, validated, and certified the GEnx-1B TCMA logic - and can't imagine what they would be going through if they missed something (coincidentally, one of them was at my birthday party last weekend and inevitably we ended up talking about what we used to do at Boeing (he's also retired)). Worse, similar TCMA logic is on the GEnx-2B (747-8) - which I was personally responsible for certifying - as well as the GE90-115B and the 737 MAX Leap engine - the consequences of that logic causing this accident would be massive.
I seem to remember Fred Dibner talking about how railway cars brake by draining the piston not by pressurising it, so trains will stop when supply lines break.
The electrical system updates to 787s for ADs and SBs - do any of these include software updates? For example the integer overflow causing GCU failsafe rectified under AD 2018-20-15. If so, who is writing and implementing these software updates? The original engineers? Their apprentices who had years long handovers? Or have they been outsourced and offshored? When these updates occur, does the entire system get tested and ratified or just the bit the bug fix is meant to fix? Because I\x92ve seen new bugs introduced by bug fixes in areas seemingly nothing to do with the original problem.
2025-06-19T19:18:00
permalink Post: 11906289
In the history of jet transport aviation, both ETOPS and non-ETOPS operations, exactly how many simultaneous dual engine failures have there been, excluding pilot causal ones? I\x92d venture it\x92s zero. Even the old DC-9/Boeing 727 era had none. ETOPS is 40 years on and zero cases, to my knowledge. Modern twins are systematically divided into two separate and independent planes. My bet is all these neat theories based on arcane questions will boil down to some human causal event, excluding Boeing. They might contributory, as in the Delta 767 where the switch design contributed to pilot misaction, but design fault, vanishingly improbable.
ANA NH-985, a 787-8, suffered dual uncommanded engine shutdown just after air-ground transition. That was a TCMS "feature."
Baltic BT-139 likewise, resulted in an FAA AD to upgrade FADEC software on a whole bunch of P&W engines.
It isn't unheard of. It may not have been seen at rotation before.
1 user liked this post.
2025-06-20T02:46:00
permalink Post: 11906545
tdracer addressed the shutoff valve operation earlier: "the aisle stand fuel switch sends electrical signals to the spar valve and the "High Pressure Shutoff Valve" (HPSOV) in the Fuel Metering Unit, commanding them to open/close using aircraft power. The HPSOV is solenoid controlled, and near instantaneous.
The solenoid is of a 'locking' type that needs to be powered both ways (for obvious reasons, you wouldn't want a loss of electrical power to shut down the engine).
"
2025-06-20T06:18:00
permalink Post: 11906620
TCMA can't be disabled electrically. It's just software, and all of the hardware involved serves other functions which are still needed while in the air. For example, the FADECs would command the HPSOV closed in case of N2 overspeed. That would have the exact same effect as TCMA.
4 users liked this post.
2025-06-21T08:19:00
permalink Post: 11907566
"Boeing explained that the RAT will remain operational as the airplane decelerates through the minimum RAT design speed of 120 knots, not 130 knots. Boeing expressed that the performance of the RAT was shown to meet the Boeing Model 787 requirement that specifies 120 knots as the minimum RAT design speed. We agree that the RAT will remain operational as the airplane decelerates through the minimum RAT design speed of 120 knots, not 130 knots..."
Again I'm not sure this is of any particular utility now, but is included here in the interests of ensuring as much factual data is available as possible.
FP.
5 users liked this post.
2025-06-21T18:31:00
permalink Post: 11907969
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:
Regards,
Justus
When we say "Software" we mean things like this:
This is the type of software we are usually subject to in our everyday lives basically everywhere. Your phone, your fridge, your oven, your water heater, your car, etc. pp. ad nauseam.
In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with.
In a normal computer we simply translate code like above into something less human readable but instead interpretable by a microchip or the like. This "machine code" is then run sequentially and does whatever it is meant to do (hopefully). If we were to expand our little happy check above with another condition then our computer would sequentially check these conditions. This opens up a lot of hoopla about timing, especially when interacting with the real world.
Let's say you want to track N1 and N2 in an engine. You'd have to make a measurement, that value would have to go through an AD converter, which writes it to some (likely volatile) storage, where it is then accessed by some sort of (C)PU, transferred to yet another piece of volatile memory and then used in the computation. This takes time because you can't do those things within the same clock cycle.
Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine.
Enter the FPGA.
While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check.
This is very useful for our Turbine Engine, because now we can verify that N2 is smaller than X without delaying our check that the Throttle Control Lever setting is within acceptable distance to N1 and N2, while also creating the appropriate output for all the different bypasses and bleed valves in a modern engine, and so on. The Safran FADEC 3 does this "up to 70 times per second" as per the vendor.
In order to be manageable the actual FADEC consists of multiple different pieces, many of which are FPGAs. At least two are used for so called "input conditioning". This is where we deal with converting messy real world values from sensors subject to real physics into nice and clean numbers. Here our values from the Throttle Control Levers come in, the signal from our N1 and N2 sensors, WOW signal, and on, and on, and on.
This is then changed into logic level signals provided to a different set of FPGAs. Lacking an actual schematic I suspect that this is what sometimes is referred to as "channels". The channel could consist of both a signal conditioning stage and then a logic stage or (more likely) redundant signal conditioning stages feed separately into separate FPGA "channels" are evaluated and then the end result is likely put into yet another FPGA for control output generation.
Why is this important?
Because it is basically impossible for a "bug" to exist in this system. These systems are the epitome of a dumb computer. They do _precisely_ what they are meant to do. The TCMA is simply a set of conditions evaluated just like any other condition in those FPGAs. If there is an "error" then it is in the requirements that lead to the truth table used by these devices but never in the truth table itself. In fact these types of computation device are used precisely because of that very property.
So when people say "the FADEC software" (ie TCMA) has "failed" or "has a bug" what they're really saying is:
The conditions that were experienced in the real world by the system were incorrectly assessed in the system requirements and lead to an undesired output state when taking into account the real world result we would have preferred.
A bit of a mouth full, granted, but an important mouth full. This simply wouldn't be someone missing a semicolon somewhere in a thousand lines of code.
Regards,
Justus
2025-06-21T20:40:00
permalink Post: 11908040
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
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:
... 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:
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.
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.
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).
"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.
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.
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 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.
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
3 users liked this post.
2025-06-22T11:04:00
permalink Post: 11908445
* all MCAS can do is affect the trim
* if something goes wrong with the trim, the crew works the "runaway trim" checklist
* this cuts MCAS off from the trim
* therefore, MCAS failure of any sort is going to be contained
It just turned out that if a crew is stuck, shortly after takeoff, in an aircraft that wants to go down, and they have no clue why because "AOA disagree" indicators are considered a luxury item for Boeing and Boeing also did not want to train crews for this, the crew may not be in the right mindset to prioritise that checklist.
Today, everyone is aware, so it's no longer an issue.
TCMA was motivated by a similar observation: that crews can fail to shut down an engine that no longer follows command input. So the FAA requires aircraft to detect that condition and do it automatically when on the ground, where an engine running at significant thrust is a danger to people and movable objects in the vicinity. The safety consideration here is, if you're on the ground and the thrust reverser is not deployed, you're not going to need the engine that badly. (I think there are actually two more conditions that I don't remember right now.)
In safety, you kinda need to weigh the consequences of having this system (with a chance that it might malfunction) vs not having it. Also consider that the benefit of having it, all of the occasions where it correctly shuts an engine off, don't get reported in the press.
If a TCMA bug caused this accident, the investigation will find out.
But right now, we don't have any evidence that that's what happened.
8 users liked this post.
2025-06-22T11:24:00
permalink Post: 11908460
MCAS wasn't "under the radar". The designers thought:
* all MCAS can do is affect the trim
* if something goes wrong with the trim, the crew works the "runaway trim" checklist
* this cuts MCAS off from the trim
* therefore, MCAS failure of any sort is going to be contained
* all MCAS can do is affect the trim
* if something goes wrong with the trim, the crew works the "runaway trim" checklist
* this cuts MCAS off from the trim
* therefore, MCAS failure of any sort is going to be contained
Anyway, I think we agree here.
I cannot se TCMA logic flying under the Boeing radar in this case?
TCMA is a logic nuilt in the EEC/FADEC by the Engine manufacturer I guess?
TCMA was motivated by a similar observation: that crews can fail to shut down an engine that no longer follows command input. So the FAA requires aircraft to detect that condition and do it automatically when on the ground, where an engine running at significant thrust is a danger to people and movable objects in the vicinity. The safety consideration here is, if you're on the ground and the thrust reverser is not deployed, you're not going to need the engine that badly. (I think there are actually two more conditions that I don't remember right now.)
In safety, you kinda need to weigh the consequences of having this system (with a chance that it might malfunction) vs not having it. Also consider that the benefit of having it, all of the occasions where it correctly shuts an engine off, don't get reported in the press.
If a TCMA bug caused this accident, the investigation will find out.
But right now, we don't have any evidence that that's what happened.
With extremely little data for us to use I think people are grabbing anything as a cause.
TCMA as a cause has been interresting, learning. But it should be designed safe. Can we find a data point that takes us away from TCMA or can\x92t we?
2025-06-22T13:13:00
permalink Post: 11908531
There is a bigger issue here. The general public are more and more concerned that Boeing is cutting corners, and perhaps that is debatable and a complex balance of "how much do you want to pay for a plane ticket" vs "how absurdly close to diminishing returns can statistical probability get when dealing with some of the most complex machines and industries humanity has ever created".
What isn't debatable is that MCAS was part of an initiative to save on regulatory and training costs. It was designed entirely because a regulatory environment existed where you could extend the fuselage to the point where you needed to mount engines in a way that would essentially make this no longer the same type, and probably not something that any aircraft designer would design fresh. Boeing, like everyone else, played within that framework, but Boeing didn't execute properly and the public optics are that they cut corners on top of cutting corners.
I agree that engineering is all about tradeoffs but I don't think anything is "no longer an issue" because we had 2 disasters within a couple of years and learned from mistakes. There is an issue somewhere, maybe a systemic corporate issue, a PR issue, or just a Boeing issue - the Air India crash has the potential to make it far bigger.
What isn't debatable is that MCAS was part of an initiative to save on regulatory and training costs. It was designed entirely because a regulatory environment existed where you could extend the fuselage to the point where you needed to mount engines in a way that would essentially make this no longer the same type, and probably not something that any aircraft designer would design fresh. Boeing, like everyone else, played within that framework, but Boeing didn't execute properly and the public optics are that they cut corners on top of cutting corners.
I agree that engineering is all about tradeoffs but I don't think anything is "no longer an issue" because we had 2 disasters within a couple of years and learned from mistakes. There is an issue somewhere, maybe a systemic corporate issue, a PR issue, or just a Boeing issue - the Air India crash has the potential to make it far bigger.
I also think that saying \x91cutting corners\x92 is an unjustified indictment. They didn\x92t IMHO. What WAS wrong was not making it clear how the system operated and that it could be triggered by a single AOA probe failure. And making it clear that the crew handles it just like any other runaway trim scenario. So to me it was mostly a training issue.
IF \x97 and it\x92s a big IF \x97 this accident was caused by an FAA requirement to automatically cut engines with engine runaway due unresponsive throttle (which isn\x92t needed in the first place with FCS and fire handles available) then the primary culpability lay with the regulatory entity (FAA) requiring more silly boxes on airplanes. Without zero thought towards unintended consequences.
But at this point it\x92s wayyyyyyy too early to do any Boeing Bashing based on an accident none of us have any clue as to the cause.
6 users liked this post.
2025-06-22T21:47:00
permalink Post: 11908831
No, no, I was thinking about the FDR data being downloadable from the EAFR through the aircraft's network. Be it with the Maintenance Laptop (which I presume) or any kitchen-grade laptop with a physical ethernet port (which I hope is not the case). But I have no clue on what an appropriate device is for such an operation.
Regarding the QAR, the 787 is or can be equipped with a WQAR, but I hate to type the W, as in Wireless, as the moment I hit the 'enter' button, Starlink interfaces will be devised and engineered on the spot....
Regarding the QAR, the 787 is or can be equipped with a WQAR, but I hate to type the W, as in Wireless, as the moment I hit the 'enter' button, Starlink interfaces will be devised and engineered on the spot....
2025-06-28T03:55:00
permalink Post: 11912318
"This AD was prompted by reports of water leakage from the potable water system due to improperly installed waterline couplings, and water leaking into the electronics equipment (EE) bays from above the floor in the main cabin, resulting in water on the equipment in the EE bays"
2025-06-28T05:36:00
permalink Post: 11912338
The FAA is saying it's a
problem
. Any suggestion that it's related to
this incident
is pure speculation. Possibly brought on by that slop 'report', which may have itself been somewhat inspired by the ADs.
The engines controllers are powered internally, and the control signals appear to be redundant wiring to the thrust lever module. Perhaps there are joints in the E/E bays (probably to be avoided) but asserting liquid intrusion would cause simultaneous loss of all four signals seems laughable.
Flight controls are primarily in the fwd E/E bay but there is a set of actuator control electronics in the aft E/E bay. So even if one bay gets a deluge, it shouldn't take out all flight controls. And the flight path isn't consistent with uncontrolled flight, much less uncommanded flight with high thrust.
Consider that there's standby instruments with independent sensors and computing and mostly independent power. Thrust and flight control is subject to greater scrutiny and requirements.
The engines controllers are powered internally, and the control signals appear to be redundant wiring to the thrust lever module. Perhaps there are joints in the E/E bays (probably to be avoided) but asserting liquid intrusion would cause simultaneous loss of all four signals seems laughable.
Flight controls are primarily in the fwd E/E bay but there is a set of actuator control electronics in the aft E/E bay. So even if one bay gets a deluge, it shouldn't take out all flight controls. And the flight path isn't consistent with uncontrolled flight, much less uncommanded flight with high thrust.
Consider that there's standby instruments with independent sensors and computing and mostly independent power. Thrust and flight control is subject to greater scrutiny and requirements.
1 user liked this post.
2025-06-28T06:41:00
permalink Post: 11912358
https://www.federalregister.gov/d/2022-26933/p-18
This paragraph (and one before) is/are also worth a read - they see no rush to fix, obviously. https://www.federalregister.gov/d/2025-08346/p-20
100% Agree: any suggestion that it's in any way related to 171 is pure speculation. Sounds like these ADs apply only to small numbers of 787s. Don't even know if 171 was one of them.
But installing lavatories directly above EE Bays? Who's the genius...? .
Anyway, I make a point of not going 'there' during the last half of any long flight. They are frequently "awash" and unpleasant places to be. The washbasins themselves are also prone to the ejecting of water onto the floors. Agreed, it's a ####ty problem.
2025-06-28T18:53:00
permalink Post: 11912625
FAA requirements and the discussion/changes that resulted from the initial NPRM here -
https://www.federalregister.gov/docu...er-regulations
1 user liked this post.
2025-06-28T19:17:00
permalink Post: 11912637
The requirements I have seen indicate that RIPS is applicable only to CVR or the CVR function of an EAFD. If you are aware of any requirement for RIPS to support flight data recording would you please provide a reference.
FAA requirements and the discussion/changes that resulted from the initial NPRM here -
https://www.federalregister.gov/docu...er-regulations
FAA requirements and the discussion/changes that resulted from the initial NPRM here -
https://www.federalregister.gov/docu...er-regulations
Yes, possible electric failure on the eafr is of course a totally different story concerning voice recording
2025-06-30T13:59:00
permalink Post: 11913645
That said, the continued absence of the FAA issuing an Emergency Airworthiness Directive for the Dreamliner suggests to me the fault was something like contaminated fuel which was specific to that flight.
2025-06-30T15:52:00
permalink Post: 11913718
2025-06-30T23:59:00
permalink Post: 11913958
- There is zero reason for the engines to have to be DOA before rotate. A point of note will be a close look at the elevator deflection at rotate, and that alone would put paid to such a position.
- The engines being lost shortly after rotate is consistent with the video from the NE met sensor camera.
- Determining the liftoff point by ADSB without adding a correction for the flow change at the PS sensor due to AOA is going to give nonsense, and that appears to be the case. The video gives a fair, not brilliant geometry to shoot a transit sighting of the aircraft at liftoff, and that is before the point that GT states.
- I am impressed that GT has the deceleration rates for a B787 gear down, flaps at 5, for zero thrust. I know what it is for gear up, gear down, not so much, but it will be on the prompt side of ugly.
- Undertaking an MLE estimate of the kinematics, do add the change for AOA if assuming a deceleration rate. You can get away with a rough overall estimate, but then lets not "gild the Lilly" by assuming accuracy at the decimal point level.
- Every sensor has measurement errors, position errors, and granularity factors when converting to an output, accuracy to multiple decimal points just looks tacky.
- The weight of the aircraft, if it is within +/-2% of the actual is doing pretty well, we have analysed baby puppy FAA aircraft that alter their actual weight by over 6% depending on whether they are using EASA weights for PLD, or FAA, or maybe the aircraft just happen to suffer from Coriolis.
- GT's heart is in the right place, I don't agree with much of what he says, but then my wife doesn't agree with me often either, so maybe that is inconclusive.
For the past 30 years, we have collectively bagged Boeing in increasing measure, for doing what all corporations are obliged to do; the board is answerable to the investors, and the investors have a "10-second Tom" event horizon when it comes to their earnings. It is little wonder that the race to the bottom is being won by Boeing, it is what Wall Street demands, and in the end, after the bones of the OEM are picked clean by those that do such things on the carcasses of once great US engineering giants, then they will bitch and moan about the losses to shareholders while they pocket the profit of their profession, fleecing the investors. L-M has been better in managing the milking of the public purse, and maybe that is the way it should be.
6 users liked this post.