Posts about: "TCMA (Air-ground Logic)" [Posts: 60 Pages: 3]

The wiring between the two (per engine) FADEC channels is separate and isolated from each other. In the areas potentially subject to cross engine rotor burst damage, that wiring is physically separated by a considerable distance. About the only place where the Channel A and B thrust lever resolver wiring is close proximity is in the thrust lever quadrant. We've been designing FADEC aircraft for 40 years - and the requirements for isolation are detailed and well understood.

I've repeatedly posted I don't know the details of the 787/GEnx-1B FADEC air/ground logic - and I know even less about the 787 air/ground system architecture. That being said, I think the whole air/ground is a bit of a red herring - even with a false air/ground indication, it's going to take a very major flaw in the FADEC logic for TCMA to activate without several other things happening (such as the thrust levers being moved to idle - which all by itself is going to make for a bad day if it's done at rotation).

The 787-8 landing gear retraction is primarily hydraulic, using the center hydraulic system for the main operation. However, the alternate gear extension system utilizes a dedicated electric pump to pressurize fluid from the center hydraulic system for gear extension. Obviously due its size and weight and staged retraction, the effort required to raise and stow the gear greatly exceeds that required for extension.

The main gear retraction/extension is controlled by the center hydraulic system.

It is apparent that the hydraulics failed when the engines shut down after breaking the down-locks and leaving the Main Landing gear bogeys in the tilt position, ready for a next step internal stowage and door closure (that was now never to happen). It is therefore apparent that the dual engine failure and consequent automated RAT extension was precipitated by this gear selection or retraction cycle and thus likely to be either WoW micro-switch or 5G Radar altimeter-effect associated. Due to accumulator depletion, the electric pump load would have spiked to replenish it. This may have precipitated the dual engine shutdown due to an unfiltered electrical surge affecting the Ground/Air microswitches (or a local 5G transmission affecting the RADALT) and resetting the TCMA.

The RADALT? Another plausibility? Because of the furore over a spasticated frequency allocation by the US FCC, the US FAA had finally “bought in” and declared that individual nations and their airline operators were responsible for their own 5G frequency spectrum allocations and for taking essential steps to ensure mitigation of the interference effects upon aircraft automated landings and other critical systems caused by their own national approved 5G spectrum decisions. It was admittedly a situation calling for extensive modifications to (and shielding for) the three radar altimeters fitted for redundancy considerations to all modern airliners... for Category 3 ILS approach and landing in zero/zero visibility conditions. The RADALT also features in many air-ground sensing applications. (eg the 747-8).

This was an unusual FAA “passing of the buck” to manufacturers such as Honeywell etc. (to sort out with client operators). But then again, it was not the US FCC’s right to dictate the specific 5G frequencies internationally. These spectrum allocations now vary over the wide selection of 5G phones available (and also nationally). 5G Radar Altimeters constitute a part of the ground/Air sensing that changes the TCMA from ground mode (able to fuel-chop engines) to the air mode (inhibited from doing so)... Ground activation is acceptable ...where fuel chopping of uncommanded thrust can prevent runway sideways excursions or runway length overruns. The question now becomes: “Is it more (or less) safe having an automated fuel-chopping capability on BOTH your left and right, rather than leaving it to the pilot to react via his center console fuel cut-off switches... in the unlikely event of a runaway engine after landing (or during an abandoned take-off)?

5G Frequency Variations

The frequencies of 5G phones vary nationally based on the frequency bands allocated and used by different carriers in each country. In the United States, for example, carriers such as AT&T, Verizon, T-Mobile, and others use a combination of low-band, mid-band, and high-band 5G frequencies. Low-band 5G frequencies typically range from 600 MHz to 1 GHz, mid-band 5G frequencies range from 1.7 GHz to 2.5 GHz, and high-band 5G (mmWave) frequencies start at 24 GHz and go up to 40 GHz . These frequencies are allocated by regulatory bodies such as the Federal Communications Commission (FCC) and can vary between countries based on spectrum availability and regulatory decisions. In other countries, the specific frequency bands used for 5G may differ, leading to variations in the frequencies supported by 5G phones. Additionally, the deployment of 5G networks can also influence the frequencies used, with some countries focusing more on sub-6 GHz bands while others prioritize mmWave technology.

5G interference? It may be an avenue worth exploring?

The issue with 5G was the potential for interference with some models of radio altimeter. I think we have been told that RA is used in 787 air/ground logic. We have also been told that air/ground state is used to enable TCMA.

I think it very unlikely that 5G interference was a contributing factor but I can see why someone would be interested in asking the question.

I think the cellphone interference concern is indeed partly focused on radio altimeters, and also on some voice comms. 5G shouldn't be problematic for the altimeters though. Modern ones operate at around 4.2-4.4 GHz, IIRC, and that's pretty far from any of the three bands 5G uses. I seem to remember reading that EASA tested for 5G interference and that it permits 5G use in the cabin. Whether that's true or not I don't know. And it wouldn't be easy, or even realistic, to police it in an airliner cabin.

Very interesting. Pal of mine used to fly. Caught up with him last night over text. This is what he said:

\x93An aircraft can be in service for many years before supposedly 'random' failures are discovered. We had a 747-400 departing JNB many years ago, and during the take off roll, the inboard leading edge flaps (flaps on the Jumbo, not slats) retracted. The only indication of this was the flaps secondary display popping up and crosses appearing over the inboard LE flaps. No Master Caution, no warnings of any kind. Apparently the system was working exactly as 'designed\x92!

During the landing roll, when Reverse is selected, the inboard LE flaps automatically retract, to avoid damage from any debris blown up by the effect of the reverse thrust.

In this take off scenario, due to maintenance work being carried out earlier in the day, the aircraft thought the reversers had been selected, and 'correctly' retracted the flaps. At rotation, the stick shaker activated, and the aircraft struggled to get airborne. The passengers got lucky, as the First Officer, who was Pilot Handling, was an experienced aerobatic pilot, and was able to keep the aircraft airborne, flying in heavy buffet and with the stick shaker activated until the air-ground logic finally caught up after gear retraction, and the LE flaps deployed again.

Not something that most regular guys would cope with, particularly at night, with no outside horizon for reference. Pilots who\x92ve operated around Africa will know what I'm talking about.

They dumped fuel and returned to JNB.
This happened on May 11th 2009 (Google it) - just how long had the Jumbo, of all variants, been in service before this 'glitch' was discovered?

The actual issue was that during the earlier maintenance, the engineers had cycled the thrust levers, with the engines off, all the way through the reverse gates, and back again (the aircraft had arrived earlier that day, and a reverser had failed to deploy). What no one knew, was that the action of moving the thrust levers through the reverse gate, would latch a bit of software logic in one of the computers on board, causing a near catastrophic sequence of events.

We all know and love the Jim Reason Swiss cheese model - I suspect we're going to discover some previously unknown holes.\x94

I find it rather a coincidence that this aircraft had so many electrical problems, had, not been retrofitted to solve one electrical issues like all 787s in the US had, and suffered what appears to be some kind of electrical failure.

Software Engineer here. IMO software glitches are more likely than mechanical failures and pilot error, and I would say increasingly more so, particularly with Boeings. I have good reasons, experience and expertise for saying this that I\x92m not going to get into here because it\x92s too long winded and will no doubt upset some people who will mistake facts for rule and let it hurt their feelings.

In 2019 I think it was, an ANA 787 had a TMCA dual engine shutdown just after landing. There was also a bug that shut down all AC power on 787s powered on for 248+ days (integer overflow causing GCU failsafe) that was supposed to be remedied on 2019. Can\x92t find any information confirming that it was implemented on all 787s. These are just two examples of software bugs. There are placed of others, and it\x92s highly likely there are ones we don\x92t know about, either in the original software or in the updates.

You sound like you know what you’re talking about. I’m a software engineer. I think software glitches are more common for this type of event than mechanical failures or pilot errors. It can take years before software errors are discovered.

I read one post in here of a 747 flaps retracting on takeoff. No Master Caution, no warnings. Apparently, due to some maintenance triggering a software glitch, the computer thought reverse thrust had been activated during a take off. Whether it was still in ground mode I don’t know.

Point is, being a software glitch in TMCA has already shut down two engines on a 787, I don’t see why the same or another software glitch in TMCA or somewhere else couldn’t do the same. Hadn’t this plane just been in for maintenance?

*On the ground* you get into a latched state, once TCMA deploys: after activation the relays stay latched to prevent a re-runaway. A full power reset of the affected EEC channel(s) and relay logic - normally done only at the gate - is required before fuel can flow again. So you can\x92t easily relight.

DISCLAIMER: Poster (a) is one of the (apparently quite numerous) lawyers following this thread; (b) a long-time forum lurker and aviation enthusiast who loves studying FCOMs for fun (to each his own, I guess); (c) has followed and read this thread from the start.

What I cannot do is add new theories or uncover any new facts the actual experts have not already thought of. However, since summarizing and structuring information is one thing lawyers tend to regularly do (and sometimes even do well), here is my attempt at a useful contribution to this thread: an attempt to summarize the main theories discussed here since day one (which I think hasn't been done for quite some time) in the hope that a birds-eye view will be helpful to those who have not read everything since the beginning or might even trigger some new flash of inspiration for someone more knowledgable than me. I have focused on the cons since there does not seem to be enough evidence to come to any positive conclusion.

I shall try to be concise and to refrain from personal evaluations of my own. Of course, no disrespect whatsoever is intended towards all those who have contributed to this thread and to the individual theories, one or combinations of which may turn out to have led to this tragic outcome. That arguments can be made against every single theory that has been propagated seems to be the result of the highly improbable and unusual nature of this deplorable event and certainly not due to any lack of knowledge or reasoning skills in this forum.

DEAR MODS: If I have distorted anything or if, meaning well, should have achieved the opposite \x96 I guess you know where the delete button is\x85

Anyway, here goes:

A. Misconfiguration or wrong takeoff data
Widely refuted, since

• rotation, takeoff and initial climb seem normal;
• likely extreme errors would have been required to have such tragic effect (the fuel tanks should have been only about half full, so not close to MTOW);
• there is strong evidence that at least some flaps were extended for takeoff (post-crash photo, perhaps also visible in video from behind)

B. Flaps retracted post-takeoff instead of gear
Still brought up from time to time. However, widely disregarded due to

• the fact that with two working engines an inadvertent flap retraction should easily be recoverable, even with gear down;
• strong indications that hydraulic and electric power were lost (audible/visible indications of RAT extension, survivor statement, lack of engine noise, position of MLG bogies).

For a while, the forward tilt of the bogies as first part of the retraction cycle was seen as additional evidence that the gear had been selected up. However, it has been pointed out that the forward tilt and the opening of the gear doors occur almost simultaneously so that it seems unlikely that hydraulic power was lost in the split second between bogie tilt and gear door actuation. It is now assumed the forward tilt of the bogies was merely a consequence of the hydraulic power loss.
It should be pointed out that the question of "RAT in or out" was for a while the most contentious in this thread.

C. Low-altitude capture
Still argued, even if refuted by many since

• inconsistent with apparent loss of hydraulic/electric power;
• PF would have been flying manually (however, A/T reaction would have been unexpected for the PF);
• should have been recoverable (unless one assumes that the crew (a) remained unaware of the changed FMA annunciations although alerted by the unexpected FD commands; and (b) was so startled that an A/T thrust reduction was not noticed and corrected, even though the PF was apparently sufficiently alert not to follow the FD commands).

D. Loss of both engines at or shortly after rotation
Various possible reasons for this have been discussed:

I. Bird strike/FOD

• Would have to have occurred simultaneously due to lack of rudder/aileron input indicating symmetric thrust.
• No remains/traces on runway, no visual indications (flocks of birds, flames, structural engine damage).

II. Fuel-related III. Improper maintenance
Unclear which maintenance measures could possibly have been performed that would have resulted in simultaneous loss of both engines. No apparent relationships between malfunctions reported by previous passengers and essential systems.

IV. Large-scale electrical fault (e.g. due to water in E&E bay)
The engines will continue to run if electrical power is lost. FADECs are powered independently.

V. Shutdown of engines by TCMA
A parallel is drawn to the ANA incident. However, this would require not only a fault in the air/ground logic but also a sensed discrepancy between T/L position (not necessarily idle) and thrust output on both engines simultaneously.

VI. (Inadvertent) shutdown by flight crew VII. Malfunction/mishandling of the fuel cutoff switches (most recent)

A good round-up of dominant themes, including this:

You may be at risk of assuming that the air/ground control logic is in some way hard-wired, as opposed to being a function of software. I don't believe we (yet) know this to be true.

We know there has been a bug in the Generator Control Unit software (an overflowing counter) that could lead to simultaneous shut down of all generators and a total loss of all AC power (the 248 days bug).

In the interests of completeness, we should perhaps also consider the possibility of some other previously-unknown software issue capable of creating an uncommanded dual engine shutdown. TCMS is the most likely candidate due to the deliberate separation of other systems from being able to achieve this outcome. The question then isn't whether there's some odd combination of input faults that would confuse TCMS into believing it were on the ground, but rather whether there's any way in which the software side could crash in such a way as to create an anomalous state within the system leading to engine failure. For instance, another overlooked software counter with an unwelcome failure mode.

Or even just a "dirty power supply" (cf all the reports of dodgy passenger-side electrics on this a/c) leading to spurious inputs and unexpected consequences.

Whatever is the cause will likely turn out to be have been a very low-probability event. But unless we have a TCMS expert who can state canonically that (say) the WoW sensor electrically disables TCMS when airborne (as opposed to merely being an input to the TCMS logic) then we cannot say with certainty that multiple inputs would have to have failed / been corrupted in order to reach the end state of this flight.

Yes. I simplified. The point stands that the throttle needs to be pulled back, as it was in the ANA event, because that was a landing and not a take-off.

First, you posted a good summary. I'd have added "unanticipated hardware fault" and "unanticipated software fault" as generic causes.

Note that the thrust lever actuators are wired to the FADECs, and that the TCMA gets the T/L position from that. For TCMA to trigger, it has to determine that its FADEC (on that engine) failed to achieve a commanded reduction in thrust. So we're either looking at a weird, unprecedented edge case, or a FADEC failure, or both.

It has been mentioned before that this capability existed as part of the N2 overspeed protection: the FADEC would shut down a runaway engine by cutting its fuel before it disintegrates.
The thrust lever sensors are wired directly to the FADEC (and hence the TCMA). No data bus is involved with this item.

With a MCAS crash, it required a hardware problem with an AOA sensor, used as input to a correctly working MCAS, to cause the aircraft to behave erratically. With a correctly working TCMA, I believe it'd require two hardware problems to get TCMA to shut down the engine, as there'd have to be an implausible thrust lever reading, and a FADEC/engine failure to process it within the TCMA allowed range ("contour"?). On both engines, separately and simultaneously.

That leaves a software problem; it's not hard to imagine. The issue is, at this point it's just that: imagination. I could detail a possible software failure chain, but without examining the actual code, it's impossible to verify. We simply don't have the evidence.
I could just as well imagine a microwave gun frying the electronics on both engines. An escaped hamster under the floor peeing on important contacts. A timed device installed by a psychopathic mechanic. There's no evidence for that, either.

This process is a way to psychologically cope with the unexplained accident, but because it lacks evidence, it's not likely to identify the actual cause. We've run the evidence down to "most likely both engines failed or shut off close to rotation, and the cause for that is inside the aircraft". Since the take-off looked normal until that failure, we have no clues as to the cause hidden inside the aircraft. We need to rely on the official investigation to discover and analyse sufficient evidence. The post-crash fire is going to make that difficult.

"Both engines failed or shut off close to rotation" explains all of the evidence : it explains an unremarkable take-off roll, loss of lift, absence of pronounced yaw, loss of electrical power, loss of the ADS-B transponder, RAT deployment, the noise of the RAT banging into place and revving up, emergency signs lighting up, a possible mayday call reporting loss of thrust/power/lift, and a physically plausible glide from a little over 200 ft AAL to the crash site 50 feet (?) below aerodrome elevation .
It explains what we saw on the videos, what the witness reported, where the aircraft ended up, and the ensuing sudden catastrophe.

I don't believe we have evidence for anything else right now—I'd be happily corrected on that.

-----
Edit: the evidence of the crash photo with the open APU inlet door, and the main gear bogeys tilted forward, are also explained by the dual engine failure/shut off.

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.

There has been another incident of a TCMA equivalent function shutting down both engines. An airBaltic airbus a220 in July 2021 (YL- AAQ) had both PW1500 engines shut down by \x93TCM\x94 logic in the FADEC immediately upon landing.

This seems to have been caused by a mismatch between actual and commanded thrust caused by rapid throttle movement that was \x93saved up\x94 until TCM was subsequently activated by its air/ground logic.

A description can be found on flightglobal but I have too few posts to include a url - So google a220 revised software engine shutdown

Further to the (logical in my view) points you make in response to AAKEE's ostensibly logical conclusion that the commencement of undercarriage retraction (if it did commence) is conclusive of the aircraft being 'in the air' for aircraft systems purposes, including TCMA purposes, I make the following points:

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.

I read the whole threads, keeping my hands on the mousewheel so far since I'm not a pilot, just a EE / safety / systems engineer.
The hamsterwheel ist spinning a lot here, and of course it could be anything including some VHDL FPGA code line or a broken RAM cell in a cheap memory bar within the computer it was compiled with. Anything is possible, but to be honest: development processes, if followed, are usually pushing the probability to a level where it becomes pure theory. BOSCH uses FPGA+\xb5C on the brake control box of cars. They sold 100 millions of those, used 4000h each (car lifetime) without error, with less strict development process. Most errors are made on requirement level, not code.

Also, so far there is no evidence I've seen regarding the 'chicken-egg' problem, did the engines fall below idle (fuel, stall...) and this caused an electrical blackout (-> battery, RAT...) or did an EE problem cause the engines to reduce thrust (FADEC, SW bug...). And where is the common cause in all this?
There has to be a systematic error common to both engines, an external failure affecting both or a dependent fault with one affecting the other within seconds. This is the only thing I think everyone agrees here. And I refuse to beleave the external failure or dependent fault was sitting in the cockpit.
I think it is something not common to every aircraft type for the last 50 years.
So I started searching and found a candidate.

I read myself into the EE architecture of this unique 'bleed-less' design and it's megawatt powergrid since this is the part where I may be able to contribute (and I'm most curious about). Generators on the 787 are >250kW instead of <100kW each and there are two per engine instead of just one. In fact, they can go up to 516 kW and shear off the gearbox at >2200Nm (equal to >2 MW, per generator).
https://www.easa.europa.eu/en/downloads/7641/en (page 11)
So while on any other aircraft the generator is more like the dynamo on your bicycle, those generators are massive (x10).
The gearbox is connected to the HP shaft (N2) on the GEnx. I learned from Wikipedia that RR moved this gearbox to the IP shaft on the Trend 1000. And RR is happy that the A330neo Trend 7000 uses bleed air and less load on the gearbox, since this maintains stability on the HP shaft at light load (also Wikipedia).
Those generators are not in phase and frequency sync, or in other words: If you parallel them, they fight each other, it's like a short. They will almost block if this is not handled by the control box if possible (or some melting fuse blows at some point).
787 electrical system - variable frequency generators?
Somehow I find it hard to believe that they are not able to disturb the engines despite that everyone here so far is claiming that there is no way an electrical problem could influence them because FADEC has it's own supply. I read that one is sufficent to start the engine, usually both are used.
In my mind I find lot's of ways this could influence both engines simultanously. If just the BTBs on the 230V grid got some humidity (hot, no AC, water cooling...) and went up in one big arc (I think they made them semiconductor relays, too).
Could those gearboxes and engines handle 4500Nm / almost 5 MW on each HP shaft, applied within a fraction of a second without any problem?
Or if the engines were in a condition not far from compressor stall, one was stalling and 400kW load jumped from one engines generators to the other...
I did some rough estimation and one of the generators could push N2 below idle in a second or less without fuel just with its normal 250kW load (just inertia).
This is one point which is unique to this airplane model, so maybe worth a closer look.

I know that those engines are burning at >100MW at full power, but how fragile in the balance between compressor load and this one turbine stage on the HP shaft / N2, without the inertia of a 2.8 meter fan? This is just out of my background, any thermodynamic expert here?
Of course I also have no insight in SW and communication within the control boxes, how much they are talking to each other, delaying/ramping load redistribution etc. If FADEC recognizes a flameout, could it instantly command the generators to cut the load, even above idle rpm?

I would assume that some fuel contamination, valve blockade, even compressor stall would pop up slower. But such a generator could kick in within milliseconds.

As a safety guy I learned that one tends to look first at things one is familiar with (SW, HW, mechanics, pilot behaviour, maintainance, depending on one's profession) and in the end it's often the interface and dependent faults within which are not carefully considered (e.g. takeoff situation vs. thermodynamics vs. mechanics vs. power generation vs. humidity vs. generator control...) together with transient behaviour. It was the same with MCAS (safety culture vs. pilot training vs. SW design (repeated action) vs. single AOA input vs. bird strike probability close to ground vs. trim loading/blockade vs. stickshaker noise/distraction).
In fact, I was trying to find information on all those systems and directly found slides on how the engines and generators could be simulated and the power grid tested in a HIL (hardware in the loop) environment. My experience from automotive is that such simulated environments are often far from reality and HIL environment programming finished after the product is already at the customer. But of course its far easier and cheaper to apply and test faults there. But then, some programmer programms what he thinks the reaction of the engine would be.
This 'bleed-less' design was some massive change in airplane EE architecture with hugh consequences on the whole airplane design and extremely hard to fully analyze.

I'm just asking questions and hope that we all learn a lot and this was fully considered or just not an issue. It's just an aspect I found worth mentioning and not only spinning the wheel.

PS: I doubt it was TCMA. The air/ground decision is done in a different box, evaluating 5 inputs in a 1/3 and 1/2 decision according to this discussion. This is then safely sent to the FADEC (as one input) and combined with the thrust lever position and N2. But if the thrust lever position is sensed (redundant and direct) close to idle, you do not need TCMA or ground mode to expect reduced thrust.

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

Thanks Chernobyl. I had understood trdracer's posts to be qualified on the basis of experience on types other than the 78, but I may be mistaken and, in any event, the 78 design may be exactly the same as those types.

I will suggest some amendments to your last sentence, though: Based on this, both engines will should get the same air/ground indication from the aircraft and hence will should always make the same TCMA decisions (subject to their individual throttle positions and thrust outputs).

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.

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.

That's kind of you to say. However, I have to concede that my surmising that any one sensor failure in the 'on the ground' versus 'in the air' logic would result in an 'on the ground' state in both TCMA was waaaay off track.

Without knowing the 787-8 gear system, we know that is is supposed to be hydraulically moved from \x94nose up\x94 to nose down as the first step in the gear up sequence. But do we know that it would end up \x94nose down\x94 without hyd pressure?

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?