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.