Re RADALT, there is the 2009 B737-800 incident at Schiphol – actually 1.5 kms away, where the aircraft crashed in a field during approach. All three pilots, one member of the cabin crew and five of the 128 passengers were killed, 10 passengers and two cabin crew were seriously injured and 107 passengers and one of the cabin crew sustained minor injuries. Six passengers were uninjured.

The investigation ascertained that one of the RADALT systems suddenly sent an erroneous minus 8’ height reading to the automatic throttle control system. Quote from here:

tdracer I would think that the stock B747 air/ground sense of 2 MLG untilt would be very robust and reliable. After all you are counting 2 of 4 to give the signal.

May I ask one more question, please, specifically referring to the extensive testing (as mentioned by tdracer in the context of the certification phase). What is the threshold where this flight test must be repeated (re-certification), following a change in the rest of the FADEC "firmware" (for performance improvement, or for mitigation of some observed problem, etc)?

Having just read that report, blaming the RadAlt fault for this event is stretching it a bit.
From the report.

Who “blamed” the RADALT? In the tragedy in question the RADALT was, in fact, a single point of failure which resulted in the thrust levers automatically moving to idle.

I don’t comment on pilot competence issues because I don’t think it’s appropriate for me to do so.

The air/ground indication was originally envisioned as a single analog wire (similar to how min/approach idle was selected on 747s prior to the -8) - so a broken or shorted wire would result in an incorrect indication. Yes, we could have made it potentially more robust by using two discretes - one from each prox sensor unit (at the cost of additional wire weight), but we never really got that far into the implementation. I'd already formulated an idea for getting additional aircraft information to the FADECs by using EICAS as a 'data concentrator' - replacing the ARINC 429 busses from the Air Data Computers with ARINC busses from the EIUs (EICAS Interface Units) - going so far as feasibility discussions with my EICAS counterparts, but knew it would be a hard sell due to the increased EICAS work statements.

But then, we ran into a big (unrelated) issue which I could easily solve with the change that I'd already looked into of letting EICAS send the information to the FADECs - and I was able to justify the additional costs by solving that unrelated issue. Ultimately made for a much better FADEC installation, and I was a bit of a hero with the Propulsion Integration team because I was able to save ~200 lbs. of FADEC wire weight with the changes I'd come up with :ok:

Level A software has a prescribed process for certification of any software changes - as documented in DO-178. Even very minor "one line of code" changes have to be completely recertified. This involves a whole bunch of testing and documentation by the engine company to obtain Part 33 certification - not just testing the 'changed' portions but doing 'regression' testing to make sure there are no unintended changes to other parts of the software. Boeing then does a defined set of testing in our FADEC integration lab, followed by a certification flight test with the s/w installed on a single engine - there is a defined set of test conditions for the flight test that has been agreed to between the FAA and Boeing, with additional conditions added as needed to demonstrate whatever changes are in that particular s/w change.

My understand was that the cost of doing the entire cert process for even a 'simple' Level A s/w change is around $1 million. On occasion, it was faster and cheaper to modify the hardware to compensate for an issue with the s/w that it was to go back and modify/recertify the software to correct the issue.

I see this in the context of certain systems, in this case the fuel shutoff valves. Isn't this an admission of the intent to bypass the flight crew in determining when to turn off the engines? Instead, shouldn't "TCMA" be a Thrust Control Malfunction WARNING, i.e., an alert to the folks with actual skin in the game at that moment? It occurs to me that software designers are taking on too much responsibility without the associated risk. Designing automatic reactions that affect hundreds of lives shouldn't be equivalent to software for a glorified autonomous pizza delivering vehicle with no pilot aboard, should it? Airline captains, since Crew Resource Management (CRM) was invented, nowadays solicit input from crewmembers who in turn assert themselves with their own wisdom born of experience. For engineers to draw irrevocable battle plans well in advance seems to be a regression from the principle that "two heads are better than one."

Btw, I've been lurking over the Air India 171 crash and appreciate your time given to explain these systems and your lifelong experience in related software design. Thank you very much.

The FAA mandated a system that would operate - shut off the engine when the delta between the thrust lever position and thrust output on the ground was sufficiently large for a sufficiently long period - autonomously of the pilots.

My apologies, as you brought it up, in the context of RadAlt reliability, I mistook your intent.
We digress, but the failure of the RadAlt isn't what I would describe as a single point of failure.

No need to apologise, as my hastily drafted posts sometimes don’t convey, well, what I intend.

In the context of this thread and the ‘other’ event, I thought it was relevant to point out that a single erroneous sensor output could cause the automatic movement of both thrust levers to idle, in the air (but not ‘very high’), in a ‘modern’ transport category-certified Boeing jet.

Perhaps the correct description is not ‘single point of failure’, but that a single erroneous sensor output put a big hole in one of the pieces of Swiss cheese.

The risk that TCMA is meant to address is thrust imbalance while landing or aborting take-off. The NTSB was involved in an uncommanded high thrust (UHT) event in Saudi Arabia 1997; the aircraft left the runway and eventually burned out (after it was successfully evacuated). Basically, the pilots expect the engines to be at idle, and if one of the engines still delivers significant thrust, that interferes with braking, and also wants to steer the aircraft to the side, while at the same time rudder effectivity diminishes as the aircraft slows down and airflow across the rudder decreases.
At the same time, this is a high-workload situation where the pilots' attention is focused elsewhere, and things are really happening fast. You are assuming that when the pilots notice the aircraft yawing off the centerline, one of them will always check the display for a potential alert, confirm that it is valid, and then shut the engine off immediately. How much time is that supposed to take?
And if the pilot sees the alert and shuts the engine off without thinking, to save time, wouldn't it be better to have the engine off automatically in the first place?

Please also remember that, until today, TCMA activation has always been safe even when it was unwarranted, i.e. the aircraft had touched down and the pilots were able to successfully stop the plane.

There is speculation that TCMA is somehow involved in the Air India crash, but at this point there is zero evidence for it. If it was involved, then the contributing factors would need to be analysed, and conclusions would be forthcoming; but we don't even know that it is involved. For comparison, with MCAS, the contributing factors were a maintenance issue with the AOA sensor; MCAS relied on a single sensor when the aircraft has two; the aircraft did not indicate the AOA sensor failure; and crew training was inadequate. All of these issues have been addressed, and MCAS is still there. For TCMA, we don't even know of any contributing factor yet; if it did fail (remember, we have no evidence it did), it's a complete mystery why it malfunctioned.

Your scenario of the pilots having a leisurely pow-wow troubleshooting why the aircraft drags off center as they're slowing down seems to be a tad unrealistic to me. ;)

TCMA is meant to address the risk of “thrust imbalance while landing” (or RTO)? Reference for the quoted bit please, with a definition of the period and height ranges that constitute “while landing”.

”Zero evidence” for some TCMA-related double engine shut down? Zero is a big call. There is some circumstantial evidence of both engines ceasing to deliver any significant thrust, simultaneously or almost simultaneously. It’s ‘in’ until some more credible evidence - like EADR data - moves it from infinitesimally remote to zero.

These seems to be one of the most relevant posts:

See also from an early 787 FCOM:

I think we already knew all that?

You were asking for a reference as to what TCMA is for. The certification exemption seems to summarise the situation nicely, even if Musician was being slightly loose with words (UHT is a hazard during landings and RTOs, TCMA only protects during the on-ground portions of them).

(edit: depending on the situation, the hazard could be thrust imbalance, excess total thrust, or both. I have not seen significant discussion of this and I don't think it's really necessary)

That clears everything up then.

Thank you, Someone Somewhere !
If you really want to know more, look at section 2 of https://www.researchgate.net/publica...Civil_Airplane for a list of scenarios. If you can find the FAA memorandom that's based on, I'd be grateful if you shared a link to it.

We have ample evidence that AI171 suffered a loss of thrust on both engines. That's not the point.
My point is that we shouldn't assume TCMA is a serious hazard until we have evidence that it is.

Agreed, but my point was that they shouldn't have. A mechanical solution to limit the thrust possible would be better.

You’re not alone in having that opinion. But our opinions are now academic. It’s been mandated, designed, implemented and certified.