Posts about: "Weight on Wheels" [Posts: 41 Pages: 3]

Where does the logic block that takes the WoW and other inputs to generate the singe air/ground indication live? Is it somewhere that would be affected by the aircraft power systems? Could a failure in the aircraft power cause a false ground indication to be sent to the FADECs?

OK, another hour spent going through all the posts since I was on last night...
I won't quote the relevant posts as they go back ~15 pages, but a few more comments:

TAT errors affecting N1 power set: The FADEC logic (BTW, this is pretty much common on all Boeing FADEC) will use aircraft TAT if it agrees with the dedicated engine inlet temp probe - but if they differ it will use the engine probe . The GE inlet temp probe is relatively simple and unheated, so (unlike a heated probe) a blocked or contaminated probe will still read accurately - just with greater 'lag' to actual temperature changes.

TCMA - first off, I have to admit that this does look rather like an improper TCMA activation, but that is very, very unlikely. For those who don't know, TCMA is a system to shutdown a runaway engine that's not responding to the thrust lever - basic logic is an engine at high power with the thrust lever at/near idle, and the engine not decelerating. However, TCMA is only active on the ground (unfamiliar with the 787/GEnx TCMA air/ground logic - on the 747-8 we used 5 sources of air/ground - three Radio Altimeters and two Weight on Wheels - at least one of each had to indicate ground to enable TCMA). TCMA will shutdown the engine via the N2 overspeed protection - nearly instantaneous. For this to be TCMA, it would require at least two major failures - improper air ground indication or logic, and improper TCMA activation logic (completely separate software paths in the FADEC). Like I said, very, very unlikely.

Fuel contamination/filter blockage: The fuel filters have a bypass - if the delta P across the filter becomes excessive, the filter bypasses and provides the contaminated fuel to the engine. Now this contaminated fuel could easy foul up the fuel metering unit causing a flameout, but to happen to two engines at virtually the same time would be tremendous unlikely.

Auto Thrust thrust lever retard - the TO lockup in the logic makes this very unlikely (it won't unlock below (IIRC) 400 ft., and even that requires a separate pilot action such as a mode select change or thrust lever movement). And if it did somehow happen, all the pilot needs to do is push the levers back up.

Engine parameters on the FDR: I don't know what exactly is on the 787 FDR with regards to engine parameters, but rest assured that there is plenty of engine data that gets recorded - most at one/second. Getting the FDR readout from a modern FDR is almost an embarrassment of riches. Assuming the data is intact, we'll soon have a very good idea of what the engines were doing

Keeping track of this thread is tiring - again, my sympathies to the mods, as tiring as I find it, it must be far worse for them )
Apologies for a few terse posts last night, but a couple of inane posts (by a usual suspect) really set me off. I've never used the 'ignore' function, but I may need to revisit that.

I posted this previously, but it was about 70 pages ago, so I understand not going back that far, or forgetting that tidbit amongst all the noise.
In short, I'm not familiar with the specific air/ground logic on the 787/GEnx-1B - the logic I posted (3 radio altimeters, 2 Weight on Wheels, at least one of each must indicate 'on-ground) is for the 747-8 (which I'm intimately familiar with). I have a vague recollection of a discussion with my GEnx-1B counterpart 10 or more years ago that suggested that the 787 was not as complex as the 747-8, but I don't recall any details. Basic FADEC logic (BTW, as someone else noted - it's "Full Authority", not "Autonomous") is to default to 'air' if in doubt, as it's considered to be 'safer'.
The only real hardware in the TCMA system is the N2 overspeed shutdown system - which goes through a BITE style functional test on every engine start. Everything else is in software - with the only aircraft inputs being Air/Ground and thrust lever position.

As I've posted previously, the FADEC is powered by a dedicated Permanant Magnet Alternator (PMA) - aircraft power is used only as a backup for starting or if the PMA fails. If the FADEC determines it is running on aircraft power with engine running (i.e. the PMA has failed), it sets a 'No Dispatch" fault message.

On the 747, Weight on Wheels (WoW) depends on prox sensors on the landing gear (i.e. gear compression). I don't know how that's done on the 787.
The reason we used both Radio Alt and WoW is that both can give erroneous indications on certain conditions - RA can be 'fooled' by dense rain or even really dense fog (the signals bounce off the water and falsely indicate on-ground), the prox sensor system can subject to HIRF/Lightning interference.

TCMA acts quickly, but it does require some persistence, so an input glitch won't activate it (mainly N1, which is measured every 15 milliseconds).

What sort of 'confirmation' do you have in mind - the regulator mandate that resulted in TCMA basically says we can't take credit for the flight crew.

I preface this post by acknowledging all the previous posts in this, and the now-closed thread, about the TCMA, in particular the excellent posts by tdracer. (Ditto the noise analyses by Kraftstoffvondesibel and First Principal.)

I also note that the primary source of the information on which I’m basing my post is the content of Boeing’s patent application which, of course, does not contain any of the actual wiring diagrams or modification details of the TCMA, even assuming it has been implemented. (I understand from the now-closed thread, that there is an unresolved question as to whether a petition for an exemption from the TCMA requirement had been successful.)

The point of my post is to get other’s thoughts on one of the design principles of the TCMA system proposed in the patent application.

The ostensibly simple and elegant concept is described in the schematic of the system at figure 1 of the patent application. A copy of figure 1 is below.

The TCMA is the part of the schematic inside the dotted box numbered 16 , sitting with the EEC (others would call it the FADEC) in the solid box numbered 18 .

The heart of the TCMA comprises two switch relays, numbered 22 and 28 in the schematic, wired in series. Each of those switch relays is controlled by its own, dedicated engine control malfunction software, identified as the blobs numbered 130 . (The patent application identifies component 34 as a dedicated processor and 32 as the diode connected to the switch relays, but that is evidently a mistake. Component 34 is the diode and I can’t find a component number 32 anywhere in the schematics.)

Each relay switch and its controlling software is described as a ‘channel’, one A and one B. Both channels run continuously, monitoring throttle position (36 in the schematic) versus engine data fed from ARINC data bus lines (46 in the schematic) and “dedicated input sensors” not shown in the schematic. Those sensors presumably detect things like weight on wheels and perhaps RADALT.

This design is said to achieve redundancy, because if only one ‘channel’ detects the engine is producing excessive thrust while the throttle is set to idle, that channel will set its switch relay to CUTOFF and that is enough to change the state of the high pressure fuel shut off valve (58 in the schematic). No more motion lotion. In the words of the patent application: Both channels are “always actively monitoring engine function and independently have the capability of shutting down the engine.”

That arrangement wrinkled my crusty old avtech brow. In my mind – and this is why I’m seeking other’s thoughts – the advantage of redundancy arising from the two channels, either or both of which can shut the engine down, is not without risk. If it is possible for one of the channels to have some ‘glitch’ or hardware failure such that it does not detect an actual out of envelope condition justifying immediate shut down, with the other channel detecting the condition and shutting the engine down, it inexorably follows – does it not – that it is possible for one (or both) of the channels to have a ‘glitch’ or hardware failure that results in a shut down when there is no out of envelope condition?

Further, even if there are completely separate, duplicated sensors telling each channel things like the position of the throttle and whether or not there is weight on wheels, there remains the possibility of a combination of sensor failures/disconnects resulting in one channel being ‘convinced’ that an out of envelope condition exists, with a consequential cutoff of fuel to the engine.

I of course acknowledge the valid observations made about the remote probabilities of these kinds of glitches and failures.

I’ve heard rumours that there was much resistance to the mandating of TCMA systems. Having seen many, many strange faults caused by random shorts, open circuits, liquid ingress and other foreign objects, I can understand why there was that resistance. Every time you add something to a system and that added thing has electronic components and software and electrical connections and data inputs, you add risk of that thing malfunctioning or working perfectly but with erroneous inputs. In this case, there are effectively two added new things: two channels, each one of which has the ability to shut off the motion lotion to the engine to which they are strapped.

I make no comment on whether TCMA systems, if fitted, have anything to do with this tragedy.

My profound condolences to the families and friends of those killed or injured. My thoughts also go out to the many people who will be agonising over the potential causes and responsibility for it. And thanks to those who are working out the causes.

...

This is one of the reasons for the valid theoretical points about probabilities not necessarily being valid as a matter of practicality. It's entirely reasonable to argue that, for example, the probabilities of a weight on wheels sensor failing at the same time as a throttle position sensor are vanishingly remote. But try predicting what will happen if a cup of coffee is spilt over a control console, or a piece of loose swarf in a connector shorts unrelated system wires or...

The scenarios are nearly infinite and it is impossible to predict the consequences of all of them.

Back to the subject of the TCMA, in order for the four channels (A and B for engine 1 and A and B for engine 2) to be truly independent, there would have to be, for example, four, separate weight on wheels sensors and two, separate throttle position sensors per throttle. I would be extraordinarily surprised if that's what has been implemented, but will happily stand corrected.

You'd be half right (or if you prefer, half wrong). Each channel of the FADEC has its own thrust lever position resolver. In other Boeing aircraft, there is a single resolver per engine, with dual electrical coils (i.e. electrically isolated but mechanically connected). But in order to go for full compliance with a (in my opinion) rather extreme FAA position regarding 'single failures' and 25.901(c), the 787 thrust lever actually has dual load paths, feeding to different thrust lever resolvers for each channel.

Well, I was looking at the drawings of the MD-11 thrust control module and there certainly are two sensors on each thrust lever. The sensors are implemented as a dual resolver on a common shaft. This level of redundancy is well understood by those who specify, design, test, and certify critical aircraft systems.

Edit - tdracer posted as I was typing. It seems 787 has even greater sensor separation.

And a sensor per channel per engine for actual thrust, and sensor inputs in addition to WoW switches to validate on-ground state (perhaps radio altimeters, as described by tdracer for some of the 74s, which I misread as 787s). I, too would be surprised \x97 stunned \x97 if all of that had been implemented. I really want to know what exactly was implemented, and when and in which specific airplanes/engines. What I expect, though, is that when we learn all of that, we'll decide that it really is exceedingly unlikely that TCMA shut down those engines in Ahmedabad the other day. But it sure looks like something did.

The statistics that apply to such a situation are Bayesian statistics.
Rather than looking at the absolute probability of a scenario, these statistics look at relative probabilities given a set of pre-conditions or given a set of post-conditions.
In the present case, it's the post-conditions that matter: "The airplane has crashed".

The main formula in this area of mathematics is
P(A|B) * P(B) = P(B|A) * P(A)
where the functions P(x) are probability density functions (if the variation of possible events is continuous) or are matrices of probability numbers (if the possible values of events are discrete values). It reads:
P(A|B) = probability of A knowing that B occurred,
P(B|A) = probability of B knowing that A occurred,
P(A) = probability of A independently of B,
P(B) = probability of B independently of A,

I'll make up an oversimplified example in the context of aviation accidents:
Suppose that the fault A1 has a probability of 0.000001 per million hours of flight, fault A2 has a probability of 0.000002 per million hours of flight, and fault A3 has a probability of 0.000007 per million hours of flight,
Suppose that faults A1, A2, and A3 have each 50% change of producing a crash and there is no causality relation between A1, A2 and A3.
(In other words, P(A1|A2) = P(A1) and similar for all permutations of A1, A2, A3)
If you know that a crash occurred in circumstances that could only be caused by A1, A2 or A3, then the probabilities that the cause is A1, A2 or A3 is respectively 10%, 20% and 70%.
Of course, these results are obvious and trivial.
You can state that B is the post-condition "the plane crashed" and the fact that it did happen is written P(B) = 1.
The relative probabilities become:
P(A1|B) * 1 = 50% * 0.000001 = 0.0000005
P(A2|B) * 1 = 50% * 0.000002 = 0.0000010
P(A3|B) * 1 = 50% * 0.000007 = 0.0000035
And since A1, A2 and A3 are the only possibilities in this example, their sum must be 1: the relative probabilities need to be "renormalised" by dividing them by their sum.
P(A1|B) = 0.0000005 / 0.0000050 = 10%
P(A2|B) = 0.0000010 / 0.0000050 = 20%
P(A3|B) = 0.0000035 / 0.0000050 = 70%
Again, this is trivial.
But if the probabilities of the 3 causes A1, A2, A3 of causing a crash are not a flat 50%, or if some causes or events are varying continuously (for instance the time elapsed between 2 events), or if you factor many more causality factors, you can still make a probability calculation using these concepts and the formulas.

This type of statistics has, for instance, been used during the COVID pandemic for computing the basic reproduction number R0 and the effective reproduction number Re (or Rt) of the virus in a population given the number of person hospitalised and deceased per day. The hospitalisation rate and the moritality rate are the post-conditions and the effective reproduction number at a given time is the computed probability given some resulting known event.
Since the effective reproduction number is affected by the measures taken to limit contagion, these calculations were computing the effectiveness of the measures.

Baysian statistics play no role here, for the reason Lead Balloon identified: there are too many variables at play. Worse, Simpson's paradox identifies that, even in the circumstance where you know the key variables at play, you've still got to think clearly through what is going on.

You did stipulate that more causality factors can be calculated using Baysian means, but so what? Back to LB's first point: calculating all of them is not practical.

While the general public (i.e. The Simpsons) can be impressed with statements like "A billion flight hours without a mishap" what matters is the precise combination of factors that caused the earlier mishap, and how similar current circumstances are to that mishap. Viewed with such insight, mishaps are almost ordinarily common (aviation example being 178 seconds to live for a VFR pilot going VMC into IMC).

I have read most of the thread (old and new). As a lawyer working in forensic investigations, I am constantly involved in problem-solving. My field of work also includes complex investigations related to insolvencies, which almost always require an analysis of the causes behind a specific, established outcome. In doing so, I naturally also have to deal with probabilities. However, it often turns out that the most likely or plausible explanation does not reflect what actually happened.

Many of the considerations I’ve read fail because the simultaneous failure of both engines is extremely unlikely, leading to a constant search for higher-order causes. It was suggested that an incorrect altitude setting led to an early thrust reduction. However, this would not explain the deployment of the RAT (Ram Air Turbine), especially since the thrust could have been readjusted. FADEC and TCAM are highly redundant systems, and TCAM failure is unlikely due to WOW (Weight on Wheels) logic, making a simultaneous engine failure after VR equally improbable.

With that said, and with regard to my question concerning the AD that relates to the fuel control switches (FCS), my thought—and it was nothing more than that—was that their activation becomes more probable if it can occur accidentally. That’s how I came across SAIB: NM-18-33.

Another user then brought up an iPhone. That notion would, of course, be dramatic—but how unlikely is it really that after approximately 10,000 actuations between December 2013 and June 2025, the two FCS no longer lock perfectly? Considering all of this, I find it quite conceivable that the A/T slightly reduced thrust in the first seconds after VR (e.g., if an incorrect target altitude had been entered) and that an object lying between the thrust levers and the FCS could have pushed the FCS into the “Off” position. Due to the buttons on top of the switches, which provide some resistance, it’s even possible that the object both pulled and pushed them.

But all of this is speculation. The investigation report will bring clarity.

Even if my theory is not confirmed, I still believe that the positioning and mechanism of the FCS are suboptimal. Switches of such critical importance should be better protected, and movements in the area in front of the switches (like reducing thrust) should not follow the same direction as shutting off the fuel supply. A different switching direction alone would provide more safety—especially considering that the FCS are protected laterally by metal plates.

It is probable that the switches are becoming easier to move across the gate after 10,000 operations. Something falling on them would be a possibility to cause that. And there is certainly an argument to be had whether down=on is a safer way for them to operate.

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?

Interesting thread towards the end, regarding the previous TCMA malfunction on landing : (pprune archived thread 617426, can\x92t post links yet)

according to Dave Therhino who claimed to have seen a detailed report, the TCMA would initialise the thrust contour logic when touching the ground. This was nominally not an issue, as the throttles and engine would be close to idle. However, if the reverser was briefly deployed right before weight on wheels, and then cancelled when the wheels touched, TCMA would see high thrust but throttles at idle and trigger.

But this was supposedly fixed and all FADECs updated. Plus, during take-off there should not be such large fluctuation in throttle position or thrust, so intermittent switching of ground-air-ground should not cause an issue.

Also, according to tdracer V2 overspeed protection cuts thrust so quickly, that if it triggered (via TCMA or whatever other reason) it was likely after the plane had lifted off the ground. I wonder though if there\x92s still enough kinetic energy to fly the profile of the incident flight with the engines cut right around rotation.

Also, would hydraulics go out so quickly, that wheels would not retract? Wonder if a faulty WoW sensor could be a contributing factor and would also not manifest itself as the wheels not retracting :thinking

If power failed first,
What happens to TCMA sensors like Weight on Wheels? Radio altimeter? Is there one Weight on Wheels per engine? Is there one radio altimeter per engine? If not, why not? Are the TCMA sensors directly powered as part of FADEC? If not, why not?
Is it possible that there was a noticeable loss of thrust caused by loss of fuel pumps and the pilot responded by cycling thrust to zero and back, trying to clear the problem, inadvertently triggering the TCMA?

It sure is a head scratcher and when you think you're on the right track "BOOM"
I'm of the view that this was most likely a commanded shutdown of both engines that occurred at or between liftoff and gear up selection.
That in the case of automatically that the conditions on the list of criteria were met and that one or more of those conditions was in opposite sense, weight on wheels would most likley be one of them.
I believe that in at least the first 10 seconds from Vr the crew would have continued to do exactly what they were trained to do without deviation.

For example
Both Engines at Takeoff Thrust
TL Position, Thrust Command, unknown or last known flight idle
Gear Selector, Overriden UP

I don't think ‘worst case scenario will be preferred’ is the philosophy they use. The way tdracer explained it, there can't be any single failure that leads to uncommanded high thrust on the ground. Presumably, each FADEC channel is treated as a single 'fault isolation area.' That's why the inactive channel has to be able to effect a shutdown in case the active channel causes a runaway.

For the sake of argument, imagine if every air/ground sensor had to say 'ground' to enable TCMA. That should still meet the 'no single failure' requirement since you'd need at least 2 failures to get a runaway engine: the original thrust control problem, and a faulty air/ground sensor.

IIRC, he said that the 747-8 looks at weight on wheels, gear truck tilt, and radio altimeters. At least one of each has to say 'ground' for TCMA to be enabled.

The equipment on RAT/battery is limited:


(from the online 2010 FCOM)


(from the maintenance training )

The 787 battery fire report says the two recorders are on the left and right 28VDC buses. I don't think those get powered on RAT by the looks of it. I would wager you get whatever is on the 235VAC 'backup bus', plus the captain's and F/O's instrument buses via C1/C2 TRUs. You won't get all of that (like the F/O's screens) because the 787 energises/de-energises specific bits of equipment, not just whole buses.

Losing recorder power looks entirely expected.


400VAC/540VDC (+-270V) is not really known for blowing past input protection in the same way as actual HV or lightning. I would expect some optocouplers and/or transformers to be both present and adequate. There's definitely some big MOVs scattered around the main 235VAC buses.

Weight on wheels appears to go into data concentrators that go into the common core system (i.e. data network).

Presumably there is a set of comms buses between the FADECs and the CCS to allow all the pretty indicators and EICAS alerts in the cockpit to work. The WoW sensors might flow back via that, or via dedicated digital inputs from whatever the reverse of a data concentrator is called (surely they have need for field actuators other than big motors?). Either way, left and right engine data should come from completely different computers, that are in the fwd e/e bay (or concentrators/repeaters in the wings, maybe) rather than in with the big power stuff in the aft e/e bay.

Sorted by topic, this is from the thread wiki, to outline what has already been discussed:
https://paulross.github.io/pprune-th...171/index.html

(I think Weight on Wheels covers posts which outline the ground/air mode discussions so far).