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"

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.

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?

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.

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

Do you have anything else?

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.

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

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.

Dozy,

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

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

UAS faster detection and precise diagnosis
 

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:

:ok: 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)

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.

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

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,

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

A brief "cold" in the probes put A/C + crew FUBAR
 

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

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?

Maybe the ECAM should be,

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

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.

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.

TTex600

What about NAVADR disagree is insufficient? Is it that if a problem is encountered, the computer presents possibilities? Shouldn't there be isolated cue for AS?

As to reporting an A/S problem, wouldn't digital readouts in line abreast be expected, to mimic the position on the airframe of each report's pitot?

Lyman, Im not certain what you are asking. In my opinion, NAVADR is insufficient because it points to NAV. NAV might make perfect sense to the engineer who designed the systems, but to a pilot - NAV is NAV. Airspeed, vertical speed, altitude...those are not NAV. The Autoflight disconnected, that's not a NAV problem.

Additionally, NAVADR requires interpretation, it requires recognition. A NAVADR annunciation complicates the situation. IMHO, AF447 would have been better off with NO ECAM. Then, at least, Robert might have diagnosed the true environment rather than be a slave to performing ECAM actions.

Yes, an isolated cue for UAS would be desirable.

Since all pitot inputs are fed into computers, I'm not sure that a line abreast display would make any difference. That's one of the things I've tried to relate to the non airbus pilots in this string. It's ALL computer generated. Who knows what to believe? The only thing a pilot can truly trust is what he sees out the front windscreen.

Tex

"Since all pitot inputs are fed into computers, I'm not sure that a line abreast display would make any difference."

My thought is that airspeed could be displayed direct to the panel, pre computer.
This alleviates isolating one seat from the other by ias. Both crew would see both airspeeds, plus ISIS. However speedy the computer, the pilots should know instantly what each pitot is giving, and then PF would select, or not, one or none, the computer might even act after a sharp pilot in deselecting the a/p, etc.

Or is airspeed presented in real time? As a pilot, why would anyone want such critical data that is seconds old?

Another thing that actually has not come up in three years. In turbulence, deviating for Wx, and fresh discussions of RecMax, exactly how startled do you think the crew were? There are handling limits for this autopilot, and I cannot imagine a pilot not already thinking about something similar that may happen.

This was a busy transit of the ITCZ, without ATC, and myriad challenges, plus a fresh consult with the cabin.

You think these pilots were shocked by the cavalry and caution?

Edit. Not my gremlin up there....

Seeing that the mere thought of the software being given the opportunity to determine what is and what is not faulty with AD and IR components essential for the safe conduct of any flight, is a step too far, I'm sure you wont mind being reminded that the "B" outfit configured their 777 / 787's to sort the mess out and present the correct data on each PFD.
http://oi47.tinypic.com/2w2lmva.jpg
So there you are; you are shown the correct data, and if all has "gone to hell in a handcart" the Fault Arbitration system will let you know - I suspect in no uncertain terms.http://images.ibsrv.net/ibsrv/res/sr...lies/wink2.gif

I would think a big red cross over thecspeed tape to be quite a visual indicator...

There seems to be at least two schools of thought here re speed awareness via the computer. One: The pilots acknowledged speeds loss, so what is the big deal? Two: We only know for certain that it happened at eleven seconds into the Law Change, and the consequent cascade of ECAM, aural alerts, etc.

It is reasonable to assume it was available at loss of auto, but the discussion is centered on the quality of data and its immediacy, not trying to push the agenda that no improvements are needed.....that is not a good tack, imo.

TTex600

You have hit the nail on the head. Why can’t the computer say what it is doing. These are the speeds provided by the speed sensors. I cannot compute this information – over to you. It seems the system designers have decided the pilots don’t need to know what is actually wrong with the plane. “Oh,the pilot doesn’t need to know this” How arrogant can they be? The pilot has ultimate and full responsibility for the plane so you would think the designers would be decent enough to tell the pilot what the plane is doing. That way he can understand what is happening and have a better chance of resolving any difficulty he may get into. If you understand somethingyou don’t have a problem with it.

If my wife has a problem but she does not say what the problem is we have difficulties. If she doesn’t tell me she dinged the car but she goes on about taking a bus to work tomorrow I will be a little confused.

It’s no wonder these guys were having difficulty trying to figure things out.

coolguys

Do not take it too far, there is no assurance the pilots will grok the problem. What is important, is that instantly, as the computer goes into assess (doubt) mode, the pilots are alerted, and not be held up until the computer makes a conclusion and automatically disconnects the ap.

There will be pilots, who, knowing the beginnings of UAS are underway, will out think the aircraft, and act prior to the autos. That may or may not be a good thing, but the truly important thing is that UAS is in the complete loop, and there will be no ground for excuses to be made. That is good for the flight path.

There is room to believe that neither pilot was aware that speeds were duff until eleven seconds post auto disconnect.

That is a scary thing.

Exactly.

@mm43 - The "B" system is the same as the "A" system. The square needing to be circled here is what should be done in the event of two pitot tubes, or even all three, icing over. Both situations defeat the voting logic employed in both systems.

@Cool Guys - As Hunter says, the PFD speed tape is blanked out with a big red X over it when UAS is detected, and ECAM shows that there has been an air data fault. The system *does* tell the pilots what has gone wrong.

"@Cool Guys - As Hunter says, the PFD speed tape is blanked out with a big red X over it when UAS is detected, and ECAM shows that there has been an air data fault. The system *does* tell the pilots what has gone wrong."

Nope. You are not wrong, but you are creating the wrong impression. You claim it took several seconds for the computer to determine UAS. DETERMINE being the operant. The pilot is privy to the result of the computation, not its inception.

Who cares if B or AB both do it or do it wrong. There is a reason to consider the current practice can use some updating. A red X on the tape? What a clumsy and open ended cue is that? If only a short span, the pilots, BOTH of them, should know instantly the speeds are being reviewed for failure. All three speeds should be displayed to both pilots, separately, for a concurrency that ennables CRM, not isolates each.

@DozyWannabe,Not exactly. The "B" system also calculates the Vsyn and therefore has the essential Vref to sort out which AD is telling porkies. The B78 uses the Vsyn if the pitots have a disagreement.

I concur. But as far as my input into this discussion goes, you and almost everyone else is failing to see my point. We're seeing the trees and missing the forest.

I am not asking for the software to determine what is faulty or not. I'm only asking for the software to recognize ANY broad area of airdata failure and give me a broad warning regarding suspect airdata information. I'll be happy to let Dozy design me a system if it does just that, identifies suspect airdata/aircraft control instrumentation and gives me an unequivocal message to the effect that airdata/control data is unreliable. At that point, I can go ahead and play pilot.

As I stated earlier, the computer knows that it has insufficient/incorrect data and that it can no longer control the aircraft. If the reason for automation disconnect includes any possibility that airspeed, altitude, vertical speed or pitch attitude is suspect (such as any ADIRU problem), then I think it reasonable for the software to present an UNRELIABLE speed/attitude/etc message. At that point, again, I can go ahead and play pilot. I no longer have to troubleshoot a software package, I can immediately go into pitch and power mode, which is after all the only real way to identify which input is presenting the problem.

Or, Airbus and the world aviation regulating bodies could just change the training to consider any, I mean ANY, ADIRU, ADR, pitot, static, etc, issue OR any unexpected Autopilot disconnect - as requiring the immediate implementation of the UAS procedure. At the present, most of the COM procedures for these malfunctions/abnormalities are systems issues. IOW, training builds a "do the ECAM's and fix the systems" mindset into Airbus pilots. The ECAM, and procedure, focus on pushing buttons and moving switches, not on flying the airplane. For all we know, Bonin was only trying to maintain some sort of basic control while he waited for Robert to "restore" a system they both believed to be in failure mode.

Don't forget, the UAS procedure does not require any action other than AP, AT and FD OFF. A pilots ability to do just that and maintain control at a safe level could be easily determined in a sim check. It can be drilled in training and become as close to second nature as are V1 cut procedures. It couldn't hurt.

On the B787 yes, not the T7.

I wouldn't be surprised if there was something similar in the A380, like I said - because the hardware has come on in the last couple of decades.

Not an unreasonable request.

Dozy wont need to design much, the data required is all onboard the aircraft and just needs assimilation to provide x,y,z vectors corresponding to the actual air-data provided on a "good" day. On a "bad" day the disparity between an AD's CAS/TAS and Vsyn will result in the warning you require along with identifying the faulty AD(s). No common mode problems or polling!

@DozyWannabe,
The origin of Vsyn is a derivative of the Speed Stability - US Patent 4767085 - taken out by Boeing in 1989.

A big red X over the data not to be used leaves absolutely no room for interpretation: DO NOT USE THIS DATA. Crude? Yes. But absolutely in fashion with even cruder systems like a red flag as in mechanical instruments. After all it is an aircraft, not an i-pad...

You get an X over the speed tape, the autopilot disconnects and all you have to do is follow the procedures for UAS. Of course, if you don't it gets tricky. Do you really need to know why exactly the speed is not available? To what gain?

Existence of a patent and existence of a fully-functioning system are two different things. Good on Boeing for working it out though!

Sitting in the back with only theoretical knowledge of how it is flown, but having read most of the threads on this, that idea, frankly, scares the :mad: out of me.

Said "UAS procedure" has been discussed to death and dissected over hundreds (at a guess) of posts, and even then there seems to be little consensus among pilots as to what several bits of it actually mean ("if safe conduct..." for a start). In fact, one of the most common theories is that when PF stuck the nose in the air he was actually following part of this procedure. I don't know if that theory is correct (none of us do) but it has as much credibility as any other I've seen as to why PF pulled up.

That procedure could well have doomed 447, and you want every PF to be told to execute it at every AP disconnect :confused:

These guys knew they had UAS (cvr) and what they did was pull up into a stall. Telling them they had UAS 10s earlier helps how ? Surely it just shortens the flight by 10s ?

Good job too since the patent is for an "inherently unstable aircraft" :)

On the other hand, if Vsyn is derived from speed stability, which is processed from other airdata using gains (claim 2) based on mach number... where's mach number coming from ?

Sitting in the front with: theoretical knowledge, actual knowledge, training, and experience in multiple transport category aircraft....... I think that your fear is unfounded.

The fact that prior to AF447 UAS was infrequently trained, and the fact that the procedure is to do NOTHING except in cases where safety of flight is in doubt should be your clue that judging UAS procedures by this accident is faulty.

There is nothing wrong with the UAS procedure. If you know what the AF447 crew was attempting to do, please tell us, but they weren't following the UAS procedure - at least not the UAS procedure I was taught in the months following their accident.

One might judge AirFrance procedures and culture by this accident, but the Airbus procedure is straightforward. The pitch and power settings Bonin apparently followed were only applicable from rotation to acceleration altitude. If he was trying to follow the procedure, he missed the first caution and the first three memory items. That's not the procedures fault.

Pilots have mis-applied the procedure to use after engine failure at V1, and incorrectly performed high speed aborts as well, but those failures don't damn the procedure. Usually, they damn the training the pilots received.

But this is all basically a moot point. Airbus won't change much because the statistical chances of this happening again are so close zero that everyone is willing to take a chance.

Too bad. In the mean time, rest easy sitting in the back. The pilots are running those ECAM procedures in expert fashion. You just need to hope that they remember to fly the aircraft while they piece together the puzzle the aircraft lays on their table.

If the aircraft, any aircraft was flying fine at 2.5 degrees nose up and cruise power why wouldn't you leave it there if the autopilot disconnects? You are 35,000 ft over the ocean so safety of flight is not an issue. Pulling up into a stall is not trained by any airline. Nobody I have ever flown with would have done that.