Page Links: First Previous 1 2 3 Next Last Index Page
Lead Balloon
June 19, 2025, 03:13:00 GMT permalink Post: 11905692 |
Thanks
Capn Bloggs
and
BuzzBox
. My apologies
Shep69
. I'm recalibrated re the minimum autopilot engagement height.
Subjects: None |
Lead Balloon
June 19, 2025, 12:45:00 GMT permalink Post: 11905991 |
The discussion about the fuel control switch design is interesting so far as it goes, but I'm more interested in the physical arrangements under the bracket to which they're fitted and the associated connection and wiring arrangements. No doubt the arrangements are designed so as to reduce to 'vanishingly small' the probabilities of any common shorts to the wrong places, but who knows, for sure, how the switches and connections and wiring were installed in the accident aircraft, or whether there was a piece of swarf or other FOD that ended up somewhere that it should not have been (i.e. anywhere on the aircraft) during manufacture or maintenance.
Subjects: None |
Lead Balloon
June 20, 2025, 00:49:00 GMT permalink Post: 11906514 |
SLF but I think this makes sense. If pulling from takeoff thust back to idle with WoW would cause TCMA activation, we'd see engine shutdowns on every rejected takeoff.
I also wonder about this theory that one of the pilots called for reject and pulled the thrust levers back, and the other overruled him and continued the takeoff. Is this plausible? CRM aside, if max braking and spoilers are triggered in this scenario, it doesn't seem so to me. Last edited by Lead Balloon; 20th June 2025 at 00:59 . Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All) Fuel Cutoff Parameters |
Lead Balloon
June 20, 2025, 03:41:00 GMT permalink Post: 11906563 |
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC Fuel (All) Fuel Cutoff Fuel Cutoff Switches |
Lead Balloon
June 20, 2025, 04:31:00 GMT permalink Post: 11906582 |
That is interesting. I'll wait for ignorantA's or tdracer's confirmation (though not suggesting you are wrong, Someone Somewhere). The 'bottom line' would nonetheless seem to remain that the TCMA software, at least, is common to both TCMA 'channels' in the FADEC on both of the engines. Not one piece of software, but presumably two (or four?) identical copies of the same software. Of course, given the stringency of the DO-170B and C software development process and the brains that work on this stuff, the probabilities of the TCMA software directing a shutdown when the conditions for it do not exist are extraordinarily remote.
Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC |
Lead Balloon
June 20, 2025, 05:47:00 GMT permalink Post: 11906608 |
I don't have any direct knowledge, but yes, that's my understanding based primarily on tdracer's comments. It also just makes sense. I'm pretty confident that all the necessary hardware already existed because of the need for N2 overspeed protection. A failure in one FADEC channel could drive the FMV fully open, leading to an overspeed and uncontained engine failure. For regulatory purposes, it would be unacceptable to have a single point of failure with catastrophic consequences, so it would be necessary to make the inactive FADEC channel capable of cutting off fuel in that case.
The air/ground signal would've already been present as well. It would be needed for switching between ground idle, flight idle, and approach idle. Tdracer has discussed that as well, in past threads. Re air/ground input to the TMCA, I am more interested in whether that is hardwired from the sensors / systems involved or - as appears to be the case just based upon what I've read here - read from ARINC or other format data. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ARINC Engine Failure (All) FADEC |
Lead Balloon
June 20, 2025, 11:17:00 GMT permalink Post: 11906849 |
I have read through all the first thread and much of the second before commenting; SLF here, albeit with a lot of flights in a lot of commercial, emergency and non-commercial aircraft but with a relevant background and expertise in collision reconstruction and looking for holes in Swiss Cheese.
.... One of the engineering experts has noted that a specific engine control circuit board must be powered down every 51 days or can cause problems, and even more so at 249 days when it has the capacity to cut both engines simultaneously. ... Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Dual Engine Failure Engine Failure (All) Generators/Alternators |
Lead Balloon
June 20, 2025, 11:21:00 GMT permalink Post: 11906856 |
Lead Balloon:
A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It\x92s really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate for more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications. Getting back to the point, if the TCMA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TCMA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC |
Lead Balloon
June 20, 2025, 11:27:00 GMT permalink Post: 11906863 |
Looking at the GE Aerospace website they appear to offer a remote monitoring service;
If this was on AI 171 presumably they would already know what happened. https://www.geaerospace.com/commerci...ital-solutions Recall that the various search 'arcs' for MH370 were calculated on the basis of attempts by the engine monitoring systems to transmit data via satellite. The system involved did not transmit the data continuously. Maybe that's changed, but if it has not, I wonder how often any data would have been transmitted after the engines started on the (very) short AI 171 flight. Subjects: None |
Lead Balloon
June 20, 2025, 11:38:00 GMT permalink Post: 11906873 |
We have an authoritative answer to that question, but only if the TCMA implemented in the FADEC used on the 787 engines functions in the way described in conceptual documents: If one of the two TCMA 'channels' for an engine 'thinks' the shut off criteria are satisfied but the other channel doesn't, the channel which 'thinks' the shut off criteria are satisfied 'wins' and the fuel shut off valve for that engine is therefore given a shut off signal.
Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC Fuel (All) Fuel Cutoff |
Lead Balloon
June 20, 2025, 12:20:00 GMT permalink Post: 11906917 |
And each FADEC is unique to the engine in which it is hosted. So whilst these may be "autonomous" they still rely on data external to the engine itself such as WoW and Rad Alt where they hold more "sway" than they do in the flight deck.
Are these values recorded in the FDR? Are values from the FADEC recorded? Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC FDR |
Lead Balloon
June 20, 2025, 22:41:00 GMT permalink Post: 11907374 |
The excellent #724 post by user989 really should be seen as the defining statement on what is currently known.
I’d like to add a complimentary test to user989’s logic on TCMA faults. Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll? Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely. They may be out there but you’d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with ‘aircraft on ground’ found during maintenance or engines not responding to thrust lever position and so on. Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let’s confine this thread to fact based technical discussion and debate. Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it. But I'd posit these points (without making any assertions about the probabilities of the scenarios). There is a flaw in the logic arising from the categorical assertion that the 'aircraft on ground' signal 'would have been correct' during the take off roll: "Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll?" What IF the 'aircraft on ground' signal into the TCMA systems was INcorrect during taxi and the take off roll, thus disabling the TCMA functionality during that phase of the flight, making no difference in any event because the engines were operating normally in accordance with the thrust lever settings? In that case, any error in, for example, the thrust lever signals and engine signals to the TCMAs would not have had any consequence. Maybe the signal reversed and stayed INcorrect after take-off. Of course, that's why we are all craving to find out from what source/s the TCMAs get the 'on ground/in air' input/s and what other systems use the same source/s. And I reiterate the point that the TCMA is "just software". I haven't seen anyone dispute the suggestion that the thing 'common' to all 4 channels of the TCMA is 4 copies of software. In the earlier thread there was a statement about the 'obsession' of some with TCMA. I'm not 'obsessed' with it, but confess a prejudice towards trying to find a cause that is not a result of crew error. I therefore also have an attraction towards fuel contamination, but have difficulty in believing that fuel contamination would result in such a 'clean', immediate and simultaneous reduction in thrust from both engines after they'd operated normally during the take off roll. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC Fuel (All) Takeoff Roll |
Lead Balloon
June 21, 2025, 13:25:00 GMT permalink Post: 11907749 |
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.
First, whilst it may be that every system that monitors and makes decisions about whether the aircraft is 'in the air' does so on the basis of exactly the same sensor inputs, that may not be true and I'd appreciate someone with the expert knowledge on the 78 to confirm or refute the correctness of the assumption, particularly in relation to, for example, FADEC functions compared with undercarriage control functions. Secondly and probably more importantly, what happens if one of the sensors being used to determine 'in air' versus 'on ground' gives an erroneous 'on ground' signal after - maybe just seconds after - every one of those sensors has given the 'in air' signal? Reference was made earlier in this thread to a 'latched' in air FADEC condition that resulted in engine shut downs after the aircraft involved landed and was therefore actually on the ground. But what if some sensor failure had resulted in the aircraft systems believing that the aircraft was now on the ground when it was not? I also note that after the 2009 B737-800 incident at Schiphol – actually 1.5 kms away, where the aircraft crashed in a field during approach - the investigation ascertained that a RADALT system suddenly sent an erroneous minus 8’ height reading to the automatic throttle control system. The conceptual description of the TCMA says that the channels monitor the “position of thrust lever” – no surprises there – “engine power level” – no surprises there – and “several other digital inputs via digital ARINC data buses”. WoW should of course be one of those "digital inputs" and be a 1 or 0. But I haven't seen any authoritative post about whether the change in state on the 78 requires only one sensor to signal WoW or if, as is more likely, there are (at least) two sensors – one on each MLG leg – both of which have to be ‘weight off’ before a weight off wheels state signal is sent. Maybe a sensor on each leg sends inputs to the ARINC data and the systems reading the data decide what to do about the different WoW signals, as between 00, 01, 10 and 11. There is authoritative information to the effect that RADALT is also one of the “digital inputs” to the TCMA. The RADALTs presumably output height data (that is of course variable with height) and I don’t know whether the RADALT hardware involved has a separate 1 or 0 output that says that, so far as the RADALT is concerned, the aircraft to which it is strapped is, in fact, ‘in the air’ at ‘some’ height, with the actual height being so high as to be irrelevant to the systems using that input (if that input is in fact generated and there are, in fact, systems that use that 1 or 0). If we now consider the ‘worst case scenario will be preferred’ concept that apparently applies to the TCMA design so as to achieve redundancy, the number of sensor inputs it’s monitoring to decide whether, and can change its decision whether, the aircraft is on the ground, becomes a very important matter. The TCMA is only supposed to save the day on the ground, if the pilots select idle thrust on a rejected take off but one or both of the engines fail to respond. In the ‘worst case’ (in my view) scenario, both TCMA channels on both engines will be monitoring/affected by every WoW sensor output and every RADALT output data and, if any one of them says ‘on ground’, that will result in both engines’ TCMAs being enabled to command fuel shut off, even though the aircraft may, in fact, be in the air. Of course it’s true that the TCMA’s being enabled is not, of itself, sufficient to cause fuel cut off to an engine. That depends on a further glitch or failure in the system or software monitoring engine power and thrust lever position, or an actual ‘too much thrust compared to thrust lever position’ situation. But I can’t see why, on balance, it’s prudent to increase the albeit extraordinarily remote risk of an ‘in air’ TCMA commanded engine or double engine shut down due to multiple sensor failure – just one in-air / on-ground sensor and one of either the thrust lever sensor/s or engine power sensor/s – or, in the case of an actual in air ‘too much thrust compared to thrust lever position situation’, why that ‘problem’ could not be handled by the crew shutting down the engine when the crew decides it’s necessary. Once in the air, too much thrust than desired is a much better problem to have than no thrust. The latter is precisely what would happen if all ‘on ground / in air’ sensors were functioning properly and some ‘too much thrust’ condition occurred. Hopefully the design processes, and particularly the DO-178B/C software design processes done by people with much bigger brains than mine, have built in enough sanity checking and error checking into the system, followed by exhaustive testing, so as to render my thoughts on the subject academic. Last edited by Lead Balloon; 21st June 2025 at 14:02 . Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ARINC FADEC Fuel (All) Fuel Cutoff Fuel Cutoff Switches |
Lead Balloon
June 21, 2025, 23:27:00 GMT permalink Post: 11908149 |
Let us assume a simple, hypothetical WoW sensor arrangement: One sensor per main landing gear. One of those sensors is indicating weight OFF wheels and the other is indicating weight ON wheels. What does the TCMA in each engine interpret that ostensibly contradictory sensor information to mean? (Note: For the time being, ignore the question whether the information is erroneous. It may be true.) Are both engine TCMA's in the 'in the air' state, are both 'on the ground', or is one 'on the ground' and the other 'in the air'? Given the purpose of the TCMA, I would have thought that any 'doubt' in this case would be resolved in favour of the 'on ground' state for both TCMAs. But maybe it's the other way around. Maybe any 'doubt' would be resolved in favour of both TCMA's being in the 'in the air' state. I have difficulty in envisaging any advantage in the TCMA system being designed such that one engine's TCMA is in the 'in the air' state and the engine's 'on the ground'. Whichever the design and outcome, there will be benefits and there will be risks. Subjects: None |
Lead Balloon
June 22, 2025, 00:29:00 GMT permalink Post: 11908185 |
This was already addressed in one of tdracer's posts about the TCMA system: the air/ground decision is made by the aircraft itself (using multiple redundant inputs and voting logic), and only a single air/ground binary state is provided to the EEC(FADEC). Further, he also stated that the EEC assumes "air", as that is the safer state given the nature of its operations.
Based on this, both engines will get the same air/ground indication from the aircraft and hence will always make the same TCMA decisions (subject to their individual throttle positions and thrust outputs). I will suggest some amendments to your last sentence, though: Based on this, both engines Let's not lose sight of the fact that a 787 has had a TCMA 'commanded' double engine shut down, luckily only during the landing roll. That double shut down was not in circumstances of a rejected take-off where one or both engines delivered 'too much' thrust despite thrust levers being set to idle or 'low power'. Some might say incredible. But it's fact. The best designed systems and software sometimes do strange, unexpected things even when everything is working 'properly', and even stranger things when some defect or damage occurs. Subjects: None |
Lead Balloon
June 22, 2025, 04:12:00 GMT permalink Post: 11908275 |
Yes, all true. And I didn't think your earlier post was incredible, just that it was an exercise not intended to explain
everything
about air/ground logic. I think that, in the real world, it's most likely that the air/ground decision will take inputs from other sensors, not just WoW. Radio altimeters seem the most likely choice and we've been told they've been used on earlier Boeings (which I think I already knew or assumed). I'd certainly feel safer with that arrangement.
Subjects: None |
Lead Balloon
July 10, 2025, 08:26:00 GMT permalink Post: 11918827 |
It is not inconceivable to me that a human being who THINKS they've had a dual engine failure at possibly the worst time imaginable (correctly or incorrectly) and has not taken the time to confirm, or take it all in and has immediately launched into memory items. I could certainly foresee one being rather startled by the energy state and the rapidly approaching buildings.
I'm not saying that this happened to this crew but it certainly could happen to someone. People do weird !!!! under high stress. There is an initial "oh !!!!, what's going on" then the training kicks in. Often at super fast rate and the challenge becomes slowing it all down. The bloody master warning on the Airbus for smoke in the forward Lav used to get me everytime. Was always at night over the ocean too. ![]() Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Dual Engine Failure Engine Failure (All) Fuel (All) Fuel Cutoff Fuel Cutoff Switches Memory Items |
Lead Balloon
July 12, 2025, 09:28:00 GMT permalink Post: 11920415 |
Why do investigative bodies insist on publishing "transcripts" of recordings - CVR, ATC, Centre etc - rather than the actual recording? I've seen "transcripts" that, on any interpretation whatsoever that is open to anyone reading it, disclose errors by at least one person, which errors don't feature in the report.
Simple example of a "transcript" of CVR audio from a Centre transmission in an actual investigation report: "Visibility 999". What does that "transcript" tell us about what was actually said by Centre? Was it: "nine hundred and ninety nine"? Was it: "nine nine nine"? Was it: "niner niner niner"? If any of those alternatives were true, it would surely follow that an error was made on the part of Centre. Or maybe there's an error in the purported transcription of the recording. Maybe Centre said: "niner niner niner niner". Or maybe Centre said: "in excess of 10 kilometres". Solving the mystery of this tragedy depends on what was actually said in the cockpit - the actual words used - by whom - precisely - and exactly when. Yet we still don't even have a published recording of the radio calls between the aircraft and ATC. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): CVR |
Lead Balloon
July 13, 2025, 08:33:00 GMT permalink Post: 11921133 |
The short answer is that we wouldn't have CVR recordings if that was possible.
Basically, the cockpit voice recorder records the pilots incriminating themselves. It was only possible to get pilots to agree to have a CVR in the cockpit by assuring them it would only be used in accident investigations. For example, on the 787's EAFR you can read out the data on a laptop connected to the onboard network, but you can't read out the CVR unless you physically access the device. Air accident investigations must safeguard that status. Their success depends on the guarantee that the investigation results can't be used to incriminate the pilots legally. But while courts cannot subpoena the CVR recording from the accident investigation, they wouldn't have to if the board released a full recording or even just a full transcript. In my opinion, that is why this preliminary report is vague on who said what, and what exactly was said. The CVR must not become a constant "anything you say can and will be used against you in a court of law" in the cockpit. I'd be happy if any lawyers in the thread (e.g. WillowRun 6-3 ) could correct or confirm. I understand, to some extent, the reasoning for not publishing the actual recording as a general rule, but from my perspective the usual outcome is speculation that can be just as critical of the actions and skills of the crew, and be just as inviting to 'ambulance chasers' keen on litigation, as ripping the band aide off the sore and dealing with the truth. I remain of the view that the least bad way to get to the awful truth - whatever it may be in the circumstances of this tragedy - includes publication of the raw recordings of the cockpit and ATC. As many have already pointed out - correctly in my view - so much depends on the nuances of the language spoken, who said what, in what order, the cultural or other status of those in the conversation, the other sounds in the environment, all assessed in the context of the timeline of flight data recorded. All one needs to do is consider the different meanings of "yeah nah" or "yeah right" in the Australian vernacular, which meanings depend, crucially, on context and tone and inflection and emphasis. Without that level of detail, paraphrasing or even quotes in transcripts are more often the source of increased speculation rather than the resolution of uncertainty. Subjects (links are to this post in the relevant subject page so that this post can be seen in context): CVR EAFR Preliminary Report |
Lead Balloon
July 13, 2025, 09:15:00 GMT permalink Post: 11921167 |
No. As amply demonstrated over and over on this forum, 95% of people have NO IDEA what goes on in commercial big-jet aviation, and a release of the raw-recordings would just cause chaos for the family of those left behind, the crew if there were any left eg a survivable midair, as well as friends and colleagues. Social media would go crazy. For no benefit. And I can assure you that from that point on, every pilot would keep their trap shut about anything to do with safety for fear of incriminating themselves. Safety would be put back decades.
I merely observe that many of the awful things you identify as potential consequences of releasing the raw-recordings seem to me to be what's already happened, and continues to happen, as a potential consequence of not releasing that recording. Perhaps crews would be less concerned about "incriminating" themselves if they comprehended that the raw recording, the content of which cannot be used as evidence in proceedings - at least in jurisdictions in which I have professional expertise - might immediately absolve them of any responsibility. Subjects: None |