Lyman

Dozy

"The ADR fault detection consequent to the blocked pitot tubes. If there's an air data fault, AP and A/THR are automatically disconnected."

Nomenclature. The ADR(s) were not faulty. That is a mistake made by someone who cannot separate a sensor from a computation.

Pedantic? NO WAY. The level of stress can be directly related to an assessment of what is wrong. If the pilots think the computers are faulty, that is different than an iced pitot probe.

This aircraft takes things for granted that are serious, and in this case, may have allowed the pilots to believe the flight computer was duff, not Ice in the probes. It also prevents the pilots from being aware instantly of a possible problem with these speeds. They are too unimportant to know something may be wrong with airspeeds? Do we not want to frighten them?

Is it possible for pilots to make a mistake by thinking something is more seriously wrong than the reality? I would say, yes. If, on top of that, there was a delay, sufficient to cement some confIrmation bias, in the awareness of bad speeds, is it possibly too late to correct this mistake in assessment?

Possible...

"tres turbelences, n'estce pas?" the ride was bumpy, it may be the pilot is even entertaining loss of the autopilot. When it does go, he is sure that is the case.
So now he must hand fly, a challenge...

"No worries, we remain in Normal Law, and have protection. What is with the
Roll? VERY turbulent, then." "Aah, we are protected in PITCH, at least"

DozyWannabe

And your basis for that conclusion is?

No, the FCOMs are pretty clear on the term "fault" being synonymous with "rejected", and as such can mean either in this case. The source of the problem is immaterial - all that matters is the data cannot be relied upon.

Have a look at HN39's post and look closely at the times:

Then look at the link I posted a short while ago. The time between the onset of the problem and the systems working out the problem (that's from normal > single ADR out > multi ADR out > UAS) is approximately 5 seconds - and it only took that long because the detection algorithms must determine a trend. The human brain would have to process that same information and divine what it meant visually, and that's presuming looking straight at the indication. There's simply no way displaying the speeds from each would have made any difference.

The "ALTERNATE LAW" call was made by the PNF, and the PF should have been listening. The idea that the turbulence would have caused AP disconnection is utter fiction.

TTex600

You're admitting that the systems can work out a problem. ( which is btw, self evident in the AP AT disconnect).

I only want to know why ECAM can't use that conclusion to display " consider applying UAS procedures"? Why deny that info to the pilot?

bubbers44

The problem they had was a simple solution. Start out with 2.5 degrees nose up, cruise power and hold altitude because the altimiters were fine. But they couldn't do it, sad. Please let them hand fly. Monitoring an autopilot does not make you a pilot. I don't care how many thousands of hours you have monitoring an autopilot, you should still be able to fly if it quits.

TTex600

Bubbers, by your criteria, they would have pranged it in for their first landing. But they obviously did not.

Do you have anything else?

bubbers44

TT, I think you have to know that pilots that land is the basic solo flying skills. Then they know how to fly by instruments. Flying an airliner at altitude required basic flying skills. These two didn't have it. Simple.

bubbers44

If you have UAS it is quite obvious. Do our modern day pilots need a notice?

DozyWannabe

ECAM isn't meant to be used in that way - it will give advice on technical issues and parameters that should not be exceeded, but it can't tell the pilots how to fly the aircraft. Call it "denying info" if you like, but no other airliner does anything similar, and for all it's worth I don't think it should.

What it *will* say is "ADR FAULT" or "ADR DISAGREE", the latter of which implies strongly that UAS procedures should be followed.

HazelNuts39

Dozy,

Could it perhaps be more specific, e.g. "IAS DISAGREE" or "AoA DISAGREE"?

DozyWannabe

Hi HN39 - the link in my post #318 goes through the different meanings of the messages and what causes them (and the relevant FCOM references).

RR_NDB

TTex600:

Quote:

Why deny that info to the pilot?

In other words: Why not inform CLEARLY, IMMEDIATELY?

Why pilots must diagnose it by System "output"? As per Airbus SAS paper?

Considering that UAS is an important "input" ?

bubbers44:

We all agree!



Why not provide just after UAS onset, a single display of the three speeds in order to precisely observe what´s going on with this important parameter.

In summary:

1) UAS detection (automatic detector sampling Capt, FO and St by probes)
2) Chime and Display of the three parameters (parallel vertical tapes)

TTex600

I'm not asking for the machine to tell me how to fly the airplane. I'm asking for the machine to tell me why it gave up and gave control to me!

If ECAM can tell me to consider Unreliable Speed procedures after a pitot heat failure, why can't it tell me to consider same when the data is corrupt? If it knows it doesnt have good enough data to fly itself, why not just make the first line of ECAM, "UAS procedure - Apply" ?

People like you want to have it both ways. You want for me, the pilot, to be able to pull your design butt out of the fire when the all knowing automation doesn't know all.....this after you've spent thousands of words explaining to me why I need the automation in the first place.

You need me in the cockpit, but you don't want me there.

In the end, I take solace in the knowledge that you need me more than I need your technology.

Turbine D

TTEX600,
I am confused. Isn't what you are asking for the same as the machine telling you how to fly the airplane?

gums

Thank you, Tex!

When the plane is doing so much, and the pilot(s) less, then this is what we get.

A simple caution light when the AP/AT disconnected would have been very useful to this old dinosaur - "Hey, Gums, your pitot system is FUBAR!"

later,

CONF iture

I believe the ECAM message NAV IAS DISCREPANCY was already available in 2009.
had F-GZCP been modified ?
Would that caution message have been displayed at the earliest stage of the event ?

BEA report is far too thin ...

RR_NDB

Quote:

"Hey, Gums, your pitot system is FUBAR!"

Actually a temporarily and brief data inconsistency between 3 redundant probes made the overall System (A/C+crew) FUBAR.

Just a crew issue or a critical System? And how to improve the original design?

IMHO through an immediate and clear information (not just in ECAM) on UAS onset. And you decide what to do after a precise (assisted by System) assessment.

The AS probes and ADR after the brief "cold" operated again perfectly. It was a single occurrence of an intermittent failure well documented earlier...

TTex600

I can see where a non pilot would think so.

One must know the Airbus UAS procedure in order for the kind of ECAM I suggest to make sense. The ECAM could say that, it could just use GUMS's words and announce "hey pilot, your pitot system is FUBAR", or many other clear and plain messages. Whatever message might be used, the reference to apply the UAS procedure will alert the pilot to the need to turn the automation off and to fly pitch and power. That's all.

I'm asking for the airplane, an entity that knows it can't fly itself anymore because of pitot/static problems, to tell me that it can no longer do so. Those ADR messages demand interpretation and might lead the crew to focus on diagnosis vs aircraft control (just as it appears happened to FO Robert)

A simple "Consider/Apply UAS" would be more appropriate than "NAV ADR Disagree". If the system knows enough to announce ADR disagree, it knows enough to announce "Consider/Apply UAS procedure". That ECAM should stay on top until the entire list has been dealt with.

Were your family in the back of AF447, what would you have wanted on the ECAM? NAV ADR Disagree, or Consider UAS?

TTex600

Maybe the ECAM should be,

"AUTOFLT A/P Disconnect - Pitot/Static Anomaly - Consider UAS Procedure"

bubbers44

Hey Gums, remember back in the 80's when we were happy the autopilot even worked most of the time in the old 737 100's and 200's. We got a chime and light when it clicked off and fixing the problem was easy, hand fly until it engages again, no big deal. Had to fly one round trip flight in a 737 from LAS to MSP as a new captain with a first month FO in an airplane with engines we hadn't flown before because it was new with no autopilot so were reading the manual to see how high we could fly and max landing weights enroute.

The company expected us to be able to do it and we did. It doesn't happen much any more.

Linktrained

RR-NDB #336

Quote:

" The AS probes and ADR after the brief " cold" operated PERFECTLY. It was a single occurrence of an intermittent failure well documented earlier."

How was a pilot to know that the AS and ADR were NOW back working PERFECTLY ?

A display of the three Pitot ASIs should help, but since the tape display of the change of altitude was not remarked on before " 10,000ft..." (on the CVR), perhaps some other way of readily comparing what may be three very different indicated speeds might be considered as an alternative to tape displays.