2025-06-15T08:32:00
permalink Post: 11902232
I expect you (or most of us) reallly don’t know enough about the Flight Control Systems to say that. Any FBW intervention would have been in play and the Captain would notimmediately by instinct have lowered the nose dramatically, whilst assessing the situation… far too low and too much going on.
Last edited by HarryMann; 15th Jun 2025 at 08:50 .
2025-06-15T22:40:00
permalink Post: 11902919
My understanding is that GE uses an automated coding system that takes logic diagrams of what we want the s/w to do and turns that into the s/w code - again don't know details (my expertise is engine control and engine/aircraft interface - not s/w development).
The FADEC is a dual channel device (most of the sensors are also duplicated between channels), but both channels use the same s/w (Rolls did a thing many years ago where the channels used different s/w - it was mess and caused all sort of problems - I don't think anyone else has tried that since).
FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC). Yes, it is possible for something designed and certified to DAL A to have 'bugs' (and yes it has happened), although those 'bugs' have nearly always been traced to requirements errors - not the actual incorporation of those requirements.
It's also worth noting that the GEnx-1B has millions of hours of operation. Nothing is 'impossible' - even a 10-9 event will happen given enough opportunities - but the odds are very low of it happening.
Then again, all of the plausible explanations for dual engine power loss that would explain this accident are of a very low probability.
11 users liked this post.
2025-06-15T23:19:00
permalink Post: 11902949
FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC).
I have been on the fringes of dissimilar hardware and dissimilar software designs (MD-11 flight controls). Sometimes it is necessary but there is a huge overhead in both development and test.
Edit to add - Even with dissimilar processor and software the requirements for both will trace up to some common high level system requirements specification. There is a non zero probability that those top level requirement were inadequate or included an error.
1 user liked this post.
2025-06-14T08:43:00
permalink Post: 11903718
I’m not a 787 driver so for fear of looking dumb in front of those that are this still confuses me. Even IF they’ve mis-selected the flap setting (I still don’t think it’s been cemented on here that there is in fact a FMS/flap setting disagreement warning but i believe there is), had the wrong de-rated take off settings, selected flaps instead of gear up the 787 with massive high bypass engines, FBW and full envelope protections surely cannot let itself be put in such a low energy/high alpha regime as we saw in the videos IF it has both fans functioning normally, surely?
the pilots may have messed up royally and numerous times so those holes lined up but the plane is the final block in the chain and a 21st century all digital entirely clean sheet design was sold as being immune to such catastrophic outcomes from a few minor (consequential yes) and fairly common errors- aren’t all the protections and our procedures designed after decades of mistakes?
im having a hard time squaring how a fully functioning modern bird like this could allow for this outcome and almost whatever the pilots did outside of unbelievable inputs and the pilots are are a bit of a red herring IMO
Dale Winsley
@Winsleydale
No. The LE slats are deployed therefore the flaps are as well. This is an automatic linkage. The flaps are set at Take-Off. Hard to see from the angle but they are...if slats are out (easy to see) then flaps are set. Looks like Flaps 5. Also, the 787 has the highest Thrust-to-Weight ratio of any airliner on Earth. The change in Alpha and lift is a trifling matter for it, at these settings (1-5). It will fly out of it easily, even at that density altitude. The attitude change is - in the circumstances I describe, consistent with a massive power loss (both sides). I believe based on probability that simultaneous mechanical failure is not the cause. Fuel contamination or starvation is likewise unlikely based on the 787 fuel system. The common element is the FADEC/Autothrottle/TOGO. However, each engine FADEC is dual redundant two channels. So any such common failure must happen further upstream. From a design perspective, that would be unthinkable. But this is Boeing. Given what I can see with my own eyes, I believe the flap issue is a non-starter. Also, re the landing gear: Clearly the Positive Rate challenge would be met based on normal rotation and fly-off at V2. But since we know the flaps were set correctly, that rules out an "oopsie" moment. Just as likely there was at the challenge moment an indication that something was amiss, and the Gear Up call was not made. They see both N1s unwinding and it takes a second to get past the WFT factor. They cross-check and see the airspeed also unwinding. Then they unload the Alpha and pitch to gear down Vy. And they had another 6 seconds. Whatever it was, it was not a flap, mechanical or fuel issue. We will know soon enough. But this is Boeing. My gut says "software". All 787s worldwide need to be grounded, now.
6:10 AM \xb7 Jun 14, 2025
\xb7
53.8K
Views
2025-06-14T08:52:00
permalink Post: 11903719
https://x.com/winsleydale/status/193...230524974?s=46
I\x92m not a 787 driver so for fear of looking dumb in front of those that are this still confuses me. Even IF they\x92ve mis-selected the flap setting (I still don\x92t think it\x92s been cemented on here that there is in fact a FMS/flap setting disagreement warning but i believe there is), had the wrong de-rated take off settings, selected flaps instead of gear up the 787 with massive high bypass engines, FBW and full envelope protections surely cannot let itself be put in such a low energy/high alpha regime as we saw in the videos IF it has both fans functioning normally, surely?
the pilots may have messed up royally and numerous times so those holes lined up but the plane is the final block in the chain and a 21st century all digital entirely clean sheet design was sold as being immune to such catastrophic outcomes from a few minor (consequential yes) and fairly common errors- aren\x92t all the protections and our procedures designed after decades of mistakes?
im having a hard time squaring how a fully functioning modern bird like this could allow for this outcome and almost whatever the pilots did outside of unbelievable inputs and the pilots are are a bit of a red herring IMO
I\x92m not a 787 driver so for fear of looking dumb in front of those that are this still confuses me. Even IF they\x92ve mis-selected the flap setting (I still don\x92t think it\x92s been cemented on here that there is in fact a FMS/flap setting disagreement warning but i believe there is), had the wrong de-rated take off settings, selected flaps instead of gear up the 787 with massive high bypass engines, FBW and full envelope protections surely cannot let itself be put in such a low energy/high alpha regime as we saw in the videos IF it has both fans functioning normally, surely?
the pilots may have messed up royally and numerous times so those holes lined up but the plane is the final block in the chain and a 21st century all digital entirely clean sheet design was sold as being immune to such catastrophic outcomes from a few minor (consequential yes) and fairly common errors- aren\x92t all the protections and our procedures designed after decades of mistakes?
im having a hard time squaring how a fully functioning modern bird like this could allow for this outcome and almost whatever the pilots did outside of unbelievable inputs and the pilots are are a bit of a red herring IMO
2025-06-15T22:40:00
permalink Post: 11903428
My understanding is that GE uses an automated coding system that takes logic diagrams of what we want the s/w to do and turns that into the s/w code - again don't know details (my expertise is engine control and engine/aircraft interface - not s/w development).
The FADEC is a dual channel device (most of the sensors are also duplicated between channels), but both channels use the same s/w (Rolls did a thing many years ago where the channels used different s/w - it was mess and caused all sort of problems - I don't think anyone else has tried that since).
FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC). Yes, it is possible for something designed and certified to DAL A to have 'bugs' (and yes it has happened), although those 'bugs' have nearly always been traced to requirements errors - not the actual incorporation of those requirements.
It's also worth noting that the GEnx-1B has millions of hours of operation. Nothing is 'impossible' - even a 10-9 event will happen given enough opportunities - but the odds are very low of it happening.
Then again, all of the plausible explanations for dual engine power loss that would explain this accident are of a very low probability.
2025-06-15T23:19:00
permalink Post: 11903725
FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC).
I have been on the fringes of dissimilar hardware and dissimilar software designs (MD-11 flight controls). Sometimes it is necessary but there is a huge overhead in both development and test.
Edit to add - Even with dissimilar processor and software the requirements for both will trace up to some common high level system requirements specification. There is a non zero probability that those top level requirement were inadequate or included an error.
2025-06-17T10:01:00
permalink Post: 11904160
Not an avionics specialist, but electronics / software engineer here, with extensive experience in hardware fault tracking, protocol monitoring and software debugging in embedded systems : mods, feel free to delete this post if I am completely out of track (and thank you for the huge amount of work you've done trying to keep this discussion clean).
After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first.
Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming):
1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead?
2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case?
The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust.
Does it make sense or is it pure fantasy?
After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first.
Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming):
1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead?
2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case?
The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust.
Does it make sense or is it pure fantasy?
3 users liked this post.
2025-06-17T10:13:00
permalink Post: 11904168
Not an avionics specialist, but electronics / software engineer here, with extensive experience in hardware fault tracking, protocol monitoring and software debugging in embedded systems : mods, feel free to delete this post if I am completely out of track (and thank you for the huge amount of work you've done trying to keep this discussion clean).
After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first.
Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming):
1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead?
2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case?
The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust.
Does it make sense or is it pure fantasy?
After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first.
Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming):
1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead?
2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case?
The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust.
Does it make sense or is it pure fantasy?
1 user liked this post.
2025-06-17T21:31:00
permalink Post: 11904684
Short answer is yes but IIRC from the 777 (believe the 78 to be similar) the auto throttles go into SPD mode at that point which could be really confusing. As one goes up through the MCP altitude and the FD commands a descent.
In any case the autopilot wouldn\x92t have been in at such a low altitude and the PF would have been hand flying. Most of the min engagement altitudes for autopilots is 400\x92 AGL.
But again all of this is speculation in every way.
In any case the autopilot wouldn\x92t have been in at such a low altitude and the PF would have been hand flying. Most of the min engagement altitudes for autopilots is 400\x92 AGL.
But again all of this is speculation in every way.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
3 users liked this post.
2025-06-17T21:37:00
permalink Post: 11904691
Most? The Airbus I'm familiar with is 100' AGL or 5s after liftoff and I think this is common to all Airbus FBW. The B787 & B777 appear to be 200' AGL but I'm taking this from online FCOM extracts. The
B737
does appear to be 400'. Company limitations may be higher.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
Yes yes back into my box.
1 user liked this post.
2025-06-17T22:42:00
permalink Post: 11904730
Most? The Airbus I'm familiar with is 100' AGL or 5s after liftoff and I think this is common to all Airbus FBW. The B787 & B777 appear to be 200' AGL but I'm taking this from online FCOM extracts. The
B737
does appear to be 400'. Company limitations may be higher.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
yeah the low MCP alt setting/alt capture doesn\x92t make a whole lot of sense- the plane didn\x92t pitch forward it just failed to climb/lost lift
that\x92s not conducive with what happened nor does it explain why the gear is still down (although seemingly selected up given the boogie tilt) or the RAT deployed (if it really was)
2025-06-18T08:46:00
permalink Post: 11905031
Most? The Airbus I'm familiar with is 100' AGL or 5s after liftoff and I think this is common to all Airbus FBW. The B787 & B777 appear to be 200' AGL but I'm taking this from online FCOM extracts. The
B737
does appear to be 400'. Company limitations may be higher.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
As mentioned elsewhere both EK and Air NZ have had messy low level mis-set altitude capture incidents with the B777, but in isolation, obviously, this wouldn't cause RAT extension.
About airport cameras. Someone pointed out on the other thread that airports have more coverage than they would necessarily advertise. Presumably available to investigators but not to the public or press.
The ideas of mis-set MCP, AT modes, etc. were worth exploring but by this point, like the gear/flap/performance ones, there is enough convincing evidence now that a) the takeoff was normal until it suddenly wasn\x92t and b) none of the above would cause RAT deployment and a glide into the ground.
3 users liked this post.
2025-06-22T07:08:00
permalink Post: 11908310
The gear tilt position is not definitive evidence crew had selected gear up. I've speculated another cause for this non-normal gear tilt is that C hydraulics failed around time of rotation. This would explain the gear remaining in the forward tilt position. There are reasons why the crew may have not selected gear up,
see earlier post.
Therefore we cannot determine wow or air/ground logic from an assumed gear retraction.
Another point pointing to that the aircraft did consider itself being \x94In Air\x94 is the ADS-B data sending Altitude from the first 575 feet at 08:08:46.55 until at least 08:50.87\x85?
I would think the sub systems like TCMA would use the same In Air / On Ground logic as the aircraft normally use?
I come from an FBW aircraft with a Air/Ground logic that seems rather bullet proof and would guess the 787 wouldn\x92t use a less solid logic which probably, in doubt would consider it being \x94In Air\x94?
It would be \x94logic\x94 for the TCMA to use this logic?
5 users liked this post.