AF 447 Thread No. 10

[OK465]

[Note: from subsequent discussion I take this to read “with full forward SS and with the system gains set at their 330 kts values”]

Actually that was really what I was trying to determine...

For a particular ADR related malfunctions, did I really get a simulated change in gains.

So first step was to check elevator deflection in Normal specifically at 330K using a full ND SS input. The logic behind checking with full ND SS as opposed to some intermediate position was that I could be sure I was duplicating the exact same SS input in Alternate. I noted the elevator deflection as a baseline for FCC commands at 330K.

Next I inserted the particular ADR malfunction I wanted to check as resulting in fixed 330K gains.

Then I applied full ND SS at both 330K & 200K, expecting to see the exact same deflection as in Normal at 330K. I indeed did. Then I checked full ND SS at 200K in Normal, expecting to see more elevator deflection with active gains. Once again I did.

I drew from this that indeed the particular ADR malfunction was also faithful to the change in gains.

Maybe my logic here is flawed.

The specific amount of elevator deflection observed was just an offshoot of the purpose of the exercise, but it brought other questions to mind. But I doubt I held the input for the up to 7 seconds as mentioned earlier, and the validity depends on simulation fidelity regarding the flight control system. Maybe not enough time for 'gee' feedback to the FCC's if in fact or to what extent they use it with gains fixed?

More work to do. I have been surprised (educated) before at various control surface deflections commanded by the FCC's in particular circumstances. Rarely do you see full control surface deflections for full SS inputs. And of course, day to day, actual flying you will probably never see full SS input. Which is a good thing. :}

edit: BTW if 9 degrees of NU elevator commands a delta gee of +1.5 (2.5 absolute) at 260 knots, I would think it would not be a stretch that 4 degrees of ND elevator (1/4) could command a delta gee of -2 (-1 absolute), 70 knots faster at 330K.

[rudderrudderrat]

Hi OK465,
Rarely do you see full control surface deflections for full SS inputs. And of course, day to day, actual flying you will probably never see full SS input. Which is a good thing.
I think it would be a good idea to know how much control surface defection is being applied - especially when the flight computers decide to only give me half - A320__Hamburg-Cross wind landing.pdf (http://www.bfu-web.de/cln_005/nn_223532/EN/Publications/Investigation_20Report/2008/Report__08__5X003__A320__Hamburg-Crosswindlanding,templateId=raw,property=publicationFile.pdf/Report_08_5X003_A320_Hamburg-Crosswindlanding.pdf) page 46
"During the next few seconds the aircraft rolled to a 23° left wing down attitude in spite of the full right deflection of both sidesticks and application of right rudder. The switch to Ground Law limited the effect of roll control corrections. The left main landing gear again made contact with the runway. At about the same instant, the left wingtip made contact with the runway."

[Owain Glyndwr]

Hi OK465

Let's see if we can put together some sort of explanation that will reconcile what we have.

Bearing in mind that your original question related to full ND in a developed stall.

If the system gains default to 330 kts values then full ND SS will give an initial elevator deflection of about 4 degrees at all speeds.
If the aircraft were genuinely at 330 kts this would be just about right to produce a delta gee of 2.0 taking the aircraft to the manoeuvre limit of -1g.
If the aircraft was in a developed stall (say 155 kts) then this elevator would, using back of envelope scaling, give a delta gee of only - 0.44.
The system would then see that this result did not conform to the expected delta gee which goes with the SS position and would apply additional ND elevator until it got a match or the elevator hit the stops.
If you cut off your observations before this second phase came into play then you would only see about 1/4 ND elevator applied.
Had you let things develop then you would have seen bigger deflections which would be consistent with what I saw on the other simulations.
If the elevator were deflected to full travel (15 deg ND) then the available delta gee would have been about - 0.75 until the THS started to move.

Does this make sense?

[DozyWannabe]

I'd be interested to know how tailwind enters into the equation?

I'm a little cautious about going too far off-topic when the conversation has suddenly become interesting again, but given my basic understanding, the function from which the alpha protection AoA is derived provides a small buffer zone between that value and alpha max - the reason being that alpha max is the highest AoA the wing can achieve while continuing to provide sufficient lift (as an aside, the alpha floor trigger function computes an AoA between the alpha prot AoA and alpha max).

If the Normal Law protections were to stop dead on alpha max, then even a relatively minor change in the airflow over the wing could conceivably cause the AoA to exceed alpha max and consequently stall the wing. I used tailwind only as an example of change in airflow.

[OK465]

If you cut off your observations before this second phase came into play then you would only see about 1/4 ND elevator applied.

Does this make sense?

Yes, it certainly does. Thanks OG.

Timing comparisons with active versus fixed, good idea...:)

(As they say, timing is everything....getting to the second phase....chrono start....patience, patience. :})

[HazelNuts39]

OG, OK465:

Just for comparison:

In the QF72 involuntary pitch-down 10° ND elevator was applied during about 1 second (2 seconds including ramps). The airplane pitched down from 2.1° NU to 8.4° ND and the normal acceleration reached -0.8 g.
Flight condition FL370, M.815, 265 kCAS, c.g. 25%.

[CONF iture]

the reason being that alpha max is the highest AoA the wing can achieve while continuing to provide sufficient lift
Negative.
Alpha Max is the limit Airbus gave to its protective system, and they were not fool enough to put that limit on the edge.
If they wanted it on the edge they would have put Alpha Max at Alpha Stall where the lift coefficient is the highest.

For the tailwind ... I don't see where you're going ...

[DozyWannabe]

Alpha Max is the limit Airbus gave to its protective system, and they were not fool enough to put that limit on the edge.
If they wanted it on the edge they would have put Alpha Max at Alpha Stall where the lift coefficient is the highest.


Probably not the greatest source, but the best I could find at short notice:

A320 Flight Controls flashcards | Quizlet (http://quizlet.com/4858580/a320-flight-controls-flash-cards/)

Alpha max is the highest alpha that the flight control computers will allow for a given configuration and weight; it provides the max lift coefficient.

For the tailwind ... I don't see where you're going ...

OK, I'll try to illustrate by way of example. As I understand it, a large amount of following airflow can be sufficient to reduce the amount of lift generated by a wing, which is why the third phase of a microburst encounter is just as, if not more, dangerous than the second phase where the downdraught forces the aircraft down. If you have an aircraft with a wing at the max lift coefficient which subsequently encounters a strong airflow from behind, then the lift may no longer be sufficient to keep the aircraft aloft.

If I've got this backwards, fine - but it seems to make sense to me...

[EDIT - I wasn't kidding about going too far off-topic, I really don't want to derail a discussion on an accident where the protections were inhibited by talking about protections...]

[roulishollandais]

If autoflight is on, then autoflight commands flightpath. If it isn't, then flightpath is manual and determined/commanded by the crew. Both are commanded - as far as the flight control logic is concerned it doesn't matter whether the command comes from the autopilot or the human crew.

Some may disagree, but in commonly understood terminology autotrim is not automation in the classic sense because it does not determine flightpath independently. Instead it is slaved to the control inputs of the autopilot or the human pilot depending on which is in control.

Hi Dozy,

You know that in the closed loop with feedback like the autotrim system, in automation we use to say (in french) : "on pilote l'erreur" said in common but acurate language "the input is not the human command, but the difference between the command and the output", and that input is not human but computed.

So I suggest to use here in PPRuNe the word "automation" for the autotrim, which is more similar from the common sense from "stupid" pilots !!! :O

[DozyWannabe]

said in common but acurate language "the input is not the human command, but the difference between the command and the output", and that input is not human but computed.

I'd say that's not entirely accurate. The *output* of the autotrim system is computed based on three primary inputs - elevator position, THS position and command from the flight controls. When hand-flown, the last of these inputs is indeed human.

So I suggest to use here in PPRuNe the word "automation" for the autotrim, which is more similar from the common sense from "stupid" pilots !!! :O

"Common sense" is by its very nature subjective, and if the discussion here is any guide there seems to be no significant barrier to pilots understanding the terminology.

That statement is loaded anyway - no part of the Airbus FBW system, and that goes for the PFC design, digital flight control system and the protections exists because anyone thought pilots were "stupid". The press liked to play that angle up because stirring up distrust between pilots and engineers means controversy, and controversy means more column inches. It exists in part because technology reached a point whereby the more mind-numbing aspects of aviation could be performed reliably, thus reducing workload on a two-man crew, and that in the case of a non-technical emergency, the pilot could perform manoeuvres safely without worrying about staying within the envelope. For management there were commercial benefits too, but that's outside the scope of what we're discussing here.

Anyway, that aside - I think autotrim should be considered distinct from the more traditional definition of automation because when under human control it simply determines the optimum placement of the THS based on the inputs it is given. Unlike autoflight it does not attempt to alter flightpath on its own. An admittedly rough analogy would be like power steering on a car.

[jcjeant]

Alpha max is the highest alpha that the flight control computers will allow for a given configuration and weight; it provides the max lift coefficient. It would be surprising Airbus have not taken into account a safety margin
For me I read through this to mean:
Alpha max is the highest alpha that the flight control computers will allow for a given configuration and weight; it provides the max lift coefficient (with a safety margin)
In all constructions or system .. it's always a safety margin ... (factor)
DW
When hand-flown, the last of these inputs is indeed human.I suppose you mean First instead Last
You have First is Last in a single command when pulleys and cables are used for transmit the inputs

[Lyman]

Technically, the impetus for control deflection is commanded by code created by a surrogate, a human. So first is last....

[DozyWannabe]

It would be surprising Airbus have not taken into account a safety margin
For me I read through this to mean:
Alpha max is the highest alpha that the flight control computers will allow for a given configuration and weight; it provides the max lift coefficient (with a safety margin)

You might be right, but to my reading the difference between the alpha protection threshold and alpha max *is* the safety margin. In fact it's the primary safety margin. There is a secondary safety margin between alpha prot and alpha max, which is the alpha floor trigger value.

None of this is relevant to AF447 though, because protections were out of scope.

DW
I suppose you mean First instead Last
You have First is Last in a single command when pulleys and cables are used for transmit the inputs

I wasn't talking about that sense, I listed three primary inputs to the autotrim system, of which the third (and last) was the flight control commands which are human under hand flight:


IN PROCESS OUT

Elv.Position|------------|
----------->|Autotrim |Trim Cmd

THS Position| |------>
----------->| |(to THS &
Pr.Flt.Ctl | System | trim wheels)
----------->|------------|


(Yes it's a gross oversimplification, but I hope it makes what I was trying to say clearer... - EDIT : Apologies for it being a little wonky - the code tag seems to behave differently between preview and posting for real...)

A Primary Flight Control input which is neutral is still an input to the autotrim system - it cannot make flightpath decisions in isolation (unlike autoflight).

[bubbers44]

None of this applies to this incident. Two pilots let an aircraft go into a full stall for no reason because the autopilot clicked off. End of story.

[jcjeant]

None of this applies to this incident. Two pilots let an aircraft go into a full stall for no reason because the autopilot clicked off. End of story.
Methink .. all have agreed with your motto since the release of the BEA interim report N°3
This was indeed the end of the story for all the human souls aboard AF447
I think the mean of the discussion(s) is to know (or analyze) why this happend ....
IMHO

[DozyWannabe]

None of this applies to this incident. Two pilots let an aircraft go into a full stall for no reason because the autopilot clicked off. End of story.

Bubbers, it's not that simple. It may be comforting to paint it as a symptom of degrading flying skills in the "Magenta Line" era, but some of the evidence contradicts this. For example, the PF was a sailplane pilot (ref: Final Report [English] p.28) and by rights should have had a better working knowledge of aerodynamics and flight envelopes than many on the line.

I've been a dedicated follower of aviation and aviation safety for most of my life, and one of the things I've come to realise over the years is that most fatal accidents that do not have a direct technical cause are not indicative of the crews in those cases being generally sub-par, but tend to stem from making an error or series of errors that they would not normally make. I like to think this is because the minimum level of competence in a line pilot is actually pretty high by the standards of a lot of professions (case in point, the Captain of ColganAir 3407 was considered to be of below-average ability and yet it took levels of fatigue that would not be permitted in any other safety-critical industry to get him to make a fatal mistake).

So the big question is as it has always been - why? Why did the PF pull up into a zoom climb, pull up into a stall and for the most part keep pulling up all the way down? Why did neither of the other crew members try to stop him? Why the seemingly complete breakdown of CRM?

Unfortunately, like other accidents in which some crew actions seem -at least at first glance - so aberrant as to border on inexplicable, I don't think there'll ever be answers to these questions that will satisfy a majority of people, let alone everyone.

[CONF iture]

[EDIT - I wasn't kidding about going too far off-topic, I really don't want to derail a discussion on an accident where the protections were inhibited by talking about protections...]
Don't expect to write anything on the subject (http://www.pprune.org/7389192-post206.html) without being challenged (http://www.pprune.org/7389302-post209.html) at least.

Probably not the greatest source, but the best I could find at short notice:
At long notice, anything better ?

[DozyWannabe]

The "challenge" isn't incompatible with anything I've said - Alpha Max is the (effective) constant, Alpha Prot and Alpha Floor thresholds are variables computed from Alpha Max taking the aircraft's attitude and flightpath into account.

The FBW system does not have any concept of "stall" or "operational ceiling" programmed into it as discrete entities, even in Normal Law (it's not that 'smart'!) - just a set of variables that should not be exceeded. Doing so will trigger protections in Normal Law and warnings in Alternate and below.

[CONF iture]

The "challenge" isn't incompatible with anything I've said
Yes it is.
Same reply (http://www.pprune.org/7389656-post216.html) ...

[HazelNuts39]

Alpha Prot and Alpha Floor thresholds are variables computed from Alpha Max taking the aircraft's attitude and flightpath into account. Just out of interest: are you sure the margin between alpha-prot and alpha-max varies with attitude and flightpath?
EDIT:: Perhaps you are referring to the phase-advance of the angle of attack signal?

[Hunter58]

Dozy

Just because the PF was also a glider pilot does not mean he did make the mental transition from aerodynamic knowledge of gliders into his big metal as you take to assume. Same as you don't make that same transmission from a standard car into a truck.

I do not believe that someone can make such an intellectual shift from one thing to another under stress so easily, especially when the environment and 'feel' of the location is so completely different to one another.

[Linktrained]

PF was a glider pilot... but it is not clear at what level. A French Brevet B used to require a flight making two turns before landing. A Brevet C required a longer flight with a gain of height for 5 minutes, both followed by a safe landing. PF already held a professional pilots licence, so these first two grades should be easy. He may have done more. I do not know. (It may be that a very, very high performance glider must have Mach limitations, too...)

PF was concerned apparently, about speed and "odd speed/ sounds" (my words) .

It was noted several months ago that the power was reduced from TOGA to 61% N1 for a couple of seconds and the NU decreased for this short time, IIRC.

Then power was restored to TOGA for the remainder of the flight. Were any comments made, by BEA on this or is it mentioned on the CVR ?

[hetfield]

For how many (more) years will this be discussed here?

The two pilots up front goofed it up!
They goofed it up in many ways.

You know it, I know it, this accident was totally avoidable!!!!

No rocket science, just basic flying skills.

[RetiredF4]

hetfield
For how many (more) years will this be discussed here?

Until the next accident happens?

The two pilots up front goofed it up!
They goofed it up in many ways.

The captain as well, or what reason do you have to let him of the hook?

You know it, I know it, this accident was totally avoidable!!!!

No rocket science, just basic flying skills.

There are no unavoidable accidents. Any accident has a cause and contributing factors.

When everything is that clear to you, then you may answer those questions,

-why their company didn´t know about this lack of abilities,
-why no simulator session uncovered those deficiencies,
-why the different captains and FO´s who flew with them didn´t notice any deficiencies,
-why department responsible for issueing the licences didn´t see anything unusual,
- why the regulating agencies didnt see any need for change with AF??

And what is your suggestion to change for accident avoidance in the future?
The crew? The training? The manuals? The procedures? Some systems? Some other ideas?

That´s what the ppruner are discussing here, to get something like lessons learned. That´s a legal achievement imho on an open forum.

[hetfield]

Franzl,

all I want to point out is, get away with all that tech stuff.

The aircraft, like others, has its flaws.

BUT, BASIC FLYING SKILLS WOULD HAVE PREVENTED THIS VERY ACCIDENT.

There were plenty similar events with a different outcome....

So, if you ask me for suggestions....
PILOTS SELECTION AND TRAINING AND A BETTER MORAL AT AF FLIGHT TRAINING DEAPARTEMENT!!!!!!!!!

Costs money, I know and some skulls:rolleyes:

[Organfreak]

There were plenty similar events with a different outcome....

Like this one....oh, it turned out the same....

Mayday - S11E02 The Plane That Flew Too High - YouTube (http://youtu.be/Qm2mqazJ_u4) :eek: :uhoh: :yuk:

(Caveat: I know full well that these programs leave something to be desired, and yet, the facts seem straightforward here.)

[john_tullamarine]

You know it, I know it, this accident was totally avoidable!!!! No rocket science, just basic flying skills.

Not criticising the post at all - the value of this series of threads is the challenge and head scratching which has been on-going. Lessons for all of us along the way, methinks.

However, while many of us may have a view about things .. I don't see any of us expressing a desire to have swapped with the mishap crew for the purpose of demonstrating our presumed superior skills ?

[bubbers44]

I flew sailplanes too and towed them. It helps you learn unpowered flight and energy management but doesn't help much in an airliner. Sully flew sailplanes too but it had little to do with his successful Hudson landing. Not stalling the airplane was the answer, but they did.

[Peter H]

I flew sailplanes too and towed them. It helps you learn unpowered flight and energy management but doesn't help much in an airliner. Sully flew sailplanes too but it had little to do with his successful Hudson landing.

Are you sure? I had always understood that his choice to ditch in the Hudson, rather than aim for a tantalisingly close airport was the critical point in the emergency.

So Sully quickly came up with a good overall strategy [ditch]. Which both pilots then executed admirably.

IMHO a willingness to consider [perhaps even to recognise] alternate landing sites is a necessary part of glider flying. So Sully's background could have influenced him here.

AFAIR experiments on the simulator confirmed the importance of the strategy. Attempts at landing at the airport were mostly unsuccessful -- especially at the first attempt!

[HazelNuts39]

A French Brevet B used to require a flight making two turns before landing. A Brevet C required a longer flight with a gain of height for 5 minutes,Just for accuracy: these brevets are sports grades (pupil level), and have no relation to a glider pilot's license.

[bubbers44]

I read his book and though I agree making powerless landings would help your confidence level in a situation like Sully's he doesn't credit it to his success.

[Linktrained]

HN39
Thank you for the corrections on French gliding licences. ( I did say "used..." I should have added that this was in the early 1950s. Things change...) I held a Brevet D, there was no question of a licence, then, as an option or a requirement at three National Centres.

It would be reasonable to suppose that PF WAS quite experienced as a glider pilot.

On three different Fight Engineered aircraft that I flew, it was usual for the pilot flying that leg, (now called PF) to have his hand forward of the throttles until V1, so that he could cut the power quickly. For the rest of the flight the F/E would control the power following verbal orders, "Zero boost", "30 inches " or "300 Torque", depending on type. If a constant powered approach was made then this would be something similar to a glide approach ( but with that constant power - and never below a certain figure, to allow for a low overshoot.)

[Lonewolf_50]

Conf: I apologize for the poor explanation. It is only the last (fourth) stage of degradation that takes the boost cylinder our of the AFCS servo package (perhaps more like "direct law) while the previous three work you to something more like varoius ALT laws, with SAS off being closer to Alt 2 or Alt 2 B in terms of flight control sensitivity.

Again, a very difficult to make comparison, but the issue with " you have to fly more manually" and "it will feel very different" is the issue at hand, not precisely the detail of which system has run amok.

I admit that I was being a bit apples to oranges. :O

[DozyWannabe]

Just out of interest: are you sure the margin between alpha-prot and alpha-max varies with attitude and flightpath?
EDIT:: Perhaps you are referring to the phase-advance of the angle of attack signal?

Could well be - it's a dim and distant memory, but I was distinctly told that the maximum attitudes were computed and held at the limit before transmission to the flight surfaces rather than the other way round (which makes sense as it's a far less process bandwidth-intensive way of doing it).

CONF might be right and the THS might be an exception (I still haven't got to the bottom of the sim behaviour), but I do know that the general design was to hold attitude with all flight surfaces available rather than put a hard limit on the flight surfaces themselves.

[TTex600]

Slight change of direction.

On the 320, an ECAM Instructing the pilots to perform UAS procedures is displayed after a pitot failure.

If the system can come to that logical conclusion, could it not also make a reliable determination of plugged pitot's?

If the answer is buried in another string, please point me there.

[DozyWannabe]

On the 320, an ECAM Instructing the pilots to perform UAS procedures is displayed after a pitot failure.

If the system can come to that logical conclusion, could it not also make a reliable determination of plugged pitot's?

What kind of determination? That there has been a problem with the pitot tubes, or an attempt to ascertain which of them is correct?

The problem with the latter is that you have three data sources - enough for a quorum, but limited in what can be applied. Earlier in the threads it was pointed out that were two to fail simultaneously, a risk is run of the systems interpreting the failed pair as correct and voting out the one that's still working. Now - the chances of this happening are miniscule, but it limits what can be done with that data.

Do you have to hand the ECAM message to which you refer?

Thanks.

[TTex600]

What kind of determination? That there has been a problem with the pitot tubes, or an attempt to ascertain which of them is correct?


Do you have to hand the ECAM message to which you refer?

Doesn't really matter. If the system can sense a pitot problem, would it not be prudent to suggest the UAS procedure? Remember, the UAS procedure does not demand action as long as safety of flight is not affected, so applying it can only help.


ANTI ICE Capt and FO Pitot is the ECAM.

Edit: I should have not asked the question in the way I did. I was trying to ask why the ECAM couldn't suggest the UAS procedure in a pitot failure.

[DozyWannabe]

@TTex600 - with you.

OK, so if I've got this right that ECAM message relates to the failure of the anti-ice system on the pitot tube rather than the pitot tube itself. Being an internal systems failure it can be easily determined which of the three, or which combination of the three have failed.

A blocked pitot tube scenario involves a failure from outside the system, so it cannot reliably monitor where the failure is. Having the ECAM suggest or instruct UAS procedure might be technically feasible, but I'd be inclined to worry about edge cases, such as a false indication scenario or a point in the flightpath where a strict interpretation of UAS procedure might be inadvisable.

[OK465]

or a point in the flightpath where a strict interpretation of UAS procedure might be inadvisable.

I would think you could conduct an entire flight using UAS procedures.

[mm43]

@ Dozy,

I would have thought that a comparison of change in relative differences between the Inertial and Air data sources would give a reliable indication of single or multiple pitot failures, be they external or internal.

All to do with what you "trust".

[DozyWannabe]

I would think you could conduct an entire flight using UAS procedures.

Possibly, but there are times when it's better than others to do so - remember we're talking edge cases here.

One thing I should have said is that ECAM is there to help the flight crew diagnose technical problems and occasionally suggest remedies to those technical problems - it was never intended as a guide to how the aircraft should be flown.

@mm43 - Feasibly, but how far would you trust it? Remember that the inertial sensors could have problems simultaneously... As a "computer guy" I'd still be more inclined to trust a human pilot with a pitch/power chart.

[Peter H]

I was trying to ask why the ECAM couldn't suggest the UAS procedure in a pitot failure.

Obviously it could suggest the UAS procedure. In hindsight it does look like a better option (to a non-pilot).

I suspect that it doesn't suggest the UAS procedure because nobody anticipated common mode pitot failures. Nor thought about their implications after they started to happen.

Personally I think that the warning could/should be given even earlier in the process, when the computer first recognised that a pitot failure may have occurred
. I think you might gain a few tens of seconds that way.

... during which time it might be a good idea if the pilots were encouraged to disengage the autopilot, until they can see that all is well. I doubt that autopilots should be relied on in situations where UAS may occur.

* I suspect that there is some intentional delay in the process. Not least to smooth over transient failures when the plane has just "flown through a puddle" and overloaded the pitots.

[andianjul]

The voting logic as described makes sense, unless as postulated two pitots block simultaneously and the remaining good pitot is out-voted by the logic. However, this approach is decidedly simplistic and I propose that it’s possible that the explanation of the voting system lacks a thorough knowledge of the low-level workings of the system. I do not possess such knowledge, however, if I were to design an air-speed sensing system one of the features (the design of which has been possible and therefore available to aviation designers/engineers virtually since the invention of the transistor) that I would incorporate is ‘signature’analysis. Basically, the electrical ‘signature’ of a valid signal from any pitot that is being impacted by air molecules will appear decidedly different to the ‘signature’ from a blocked pitot. Essentially, the signal from the blocked pitot will lack the ‘noise’ of the unblocked pitot. Sure, the block pitot can yield data, albeit invalid, and may function more as an altimeter than a speed sensor; but the absence of the minutia of the electrical information from the transducer that is being bombarded by air molecules is something for which the designers can easily test and its absence should inform the system to preclude the data from the ‘known’ blocked pitot. Then the notion of simultaneously blocked pitots being used to out-vote a functioning pitot is rendered moot.

[bubbers44]

OK, I agree, all they had to do was hold about 2.5 degrees nose up and hold altitude because the altimiter worked. Maintain cruise power and fly out of the precipitation.

However I don't think either of these pilots knew how to hand fly. That was the problem. Cost analysis says hire the new guys cheap because this is an automatic airplane. You don't need real pilots.

[Lyman]

@ andianjul...

"However, this approach is decidedly simplistic and I propose that it’s possible that the explanation of the voting system lacks a thorough knowledge of the low-level workings of the system."

precisely...

The time to initiate a pilot cue inre suspect ias is when the initial sensing is suspect, not after the data is displayed as a product (airspeed).

+1 for the man from Australia...

[RR_NDB]

Hi,

This paper is from the design group:

" By Joelle Barthe
Flight Operations Engineer

Published on SafetyFirst #5
December 2007

1 Introduction

Unreliable speed is one of the difficul situations that a pilot has to face. Once the failure has been identified, a procedure, based on pitch angles and thrst settings, will assist the pilot in safely flying the aircraft.

But the main difficulty is to rapidly detect an unreliable speed situation. Reaction time is crucial, since the aircraft may stall and overspeed conditions could cause aircraft damage.

The effects of pitot probes obstruction on ground

It intended to make ground and flight crew more sensitive to the consequences of obstructed probes, and to prevent take-off with unriliable speed.

But once airborne, how can the crew handle an unreliable speed situation?

This article is based on A320/A330/A340 design. Cockpit effects, identification and troublshooting, remains similar for wide body aircraft and A380, with some specificities covered in the operational documentation.

2 Effects and consequences in the cockpit

Water, ice, dust, ashes, etc. may pratially or totally block pitot probes and static ports. Equally,tubes misconncected to the Air Data Modules (ADM), plastic covers not removed from probes, insect nest, radome damage, may lead to enrroneous pressure measurements.

The consequences of this erroous pressure information, once used by the ADRs, and/or the standby instruments, are the computation and the display of unreliable speed and/or altitude for all users.

Erroneous speed or altitude indications can be suspected, among others, in the following cases:

- Speed discrepancy (between ADR 1, 2, 3 and standby indication),
- The flutuction of the Indicated Air Speed or of the Pressure Altitude.
- Abnormal correlation between basic flight parameters (IAS, attitude, pitch, thrst, climb rate),
- abnormal AP/FD/ATHR behaviour,
- STALL and OVERSPEED warnings or FLAP RELIEF on ECAM that are in contradiction with ar least one of the indicated airspeeds,
- Inconsistency between radio altitude and pressure altitude,
- Impossibility of extending the landing gear by the normal landing gear system.

Nevertheless, it should be emphasized that identifying an unreliable speed indication is not wlways obvious: no single rule can be givien to conclusively identify all possible erroneous indications and the display of contradictory information may confuse the flight crew. Pilots should therefore be aware of unreliable speed symptoms and consequences.

Depending on the effected probe, i. e. pitot probe os static port, differente indications in the cockpit will become unreliable. Therefore the crew should be aware that some of the usual cues to fly could be unreliable as indicated:




3 Identification and Handling of Unreliable Speed situations

Airbus has developed procedures and guidelines to help crews identify and handle an unreliable speed situation.

The Volume 3 of the FCOM and QRH provide the UNRELIABLE SPEED INDIC / ADR CHECK PROC procedure.

In addition, Airbus has developed training material in the Flight Crew Training Manual ( FCTM, available for A320/A330/A340/A380). The FCTM provides information about the causes and consequences of unreliable ADR computations. It also provides information on how to apply the UNRELIABLE SPEED INDIC / ADR CHECK PROC of the QRH.

An interative trainin tool, the e-Briefing, is also available on https://w3.airbus.com/ in the Flight Operations community, under ther heading "Safety and Operational materials".

4 - Procedures

As soon as a doubt about airspeed indication arises, or a relevant ECAM alert is triggered (relative to ADRs failure or discrepancy for instance), the UNRELIABLE SPEED INDICATION/ADR CHECK PROC procedure should be applied by the crew, following this sequence:

1) If the safe conduct of the flight is affected, APPLY THE MEMORY ITEMS, i. e. fly a pitch with TOGA or CLB thrust,

2) If the safe conduct of the flight is not affected, or once the memory items have been applied, LEVEL OFF, if necessaru, and start TROUBLESHOOTING,

3) If the affected ADR can be identified, fly with the remaining ADR.

4) If the affected ADR cannot be identified or all airspeed indications remain unreliable, FLY WITH PITCH/THRUST REFERENCES.

4.1 Memory Items

If the safe conduct of the flight is affected, the flight crew applies the memory items: theses allow "safe flight conditions" to be rapidly established in all flight phases (take-off, clim, cruise) and aircraft configurations (weight and slats/flaps). The memory items apply more particularly when a failure apprears just after take-off.
Once the target pitch attitude and thrust values have been stabilized at or above minimum safe atltitude, or when the safe conduct of the flight is nor affected, the flight crew enter the 2nd part of the QRH procedure: level off the aircraft and perform troubleshooting.

4.2 Troubleshooting and isolation

The table provided in the QRH gives the pitch (º) and thrust (%N1) to be applied to level off the aircraft according to its weight, altitude and configuration, along with flying technique advices.
In situations where most primary flight data are erroneous, some indications may stil remain correct and should consequentely be used to help the crew stabilize the flight path. This is the case for the Flight Path Vector (FPV), reliable if the static ports are not blocked, and for the GPS altitude displayed on the MCDU, when GPS is installed.

When the flight path is stabilized, the flight crew will start the troubleshooting, keeping in mind that sometimes two or even all three ADRs might provide identical but erroneous data (e.g. due to icing conditions, flight in volcanic ashes, etc).Therefore, do not instinctivelu reject an ADR that is suspected to be affected.


If the troubleshooting procedure enables the crew to identify the affected ADRs, then a normal situation can be. resumed.

But if the affected ADR cannot be identified, or all ADRs are affected, then the flight crew will fly without speed reference, using the pitch and thrust tables.

4.3 Flying using pitch/thrust tables

First, the crew has to switch OFF two ADRs and keep one ADR ON, to keep the Stall Warning Protection.
Then, the crew will [bold] fly the aircraft without speed references, using pitch (º) and thrust (%N1) settings.

To fly the aircraft using pitch and thrust settings, the crew will find in the QRH the tables relative to each phase of flight: Climb, Cruise, Descent and Approach, talking into account the aircraft weight, configuration and altitude. With theses tables, the crew will be able to safety land the aircraft.

5 Back UP Speed Scale (BUSS)

In order to dedrease the crew workload in case of unreliable speed, Airbus has developed the Back-UP Speed Scale (BUSS) that replaces the pitch and thrust table. The BUSS is optional on A320/A330/A340. It is basic on A380, being part of the ADR Monitoring functions.

This indication is based on angle of atack (AOA) sensor information, and is therefore not affected by erroneous pressure measumements.

The BUSS comes with a new ADIUR standar (among other new system standards), where the AOA information is provided through the IRs and nor through the ADRs. This enables selecting all ADRs off without loosing the STALL WARNING PROTECTION.
The AOA information provides a guidance area in place of the speed scale. When the crew selects all ADRs OFF, then:

- The Back-Up Speed Scale replaces the PFD speed scale on both PFDs,

- GPS Altitude replaces the Altitude Scale on both PFDs.

The Back-Up Speed Scale then enables to fly at a safe speed, i. e. above stall speeds, by adjusting thrust and pitch.
The BUSS will be displayed once all ADRs are switched OFF. Therefore, on aircraft that have the BUSS, when the flight crew cannot identify the faulty ADR(s) when performing the troubleshooting, or when all ADRs are affected, the flight crew will switch OFF ADRs, and will fly the green area of the BUSS.

However, if the safe conduct of the flight is affected, the memory items must still be applied before troubleshooting.
As the BUSS is associated to the ADR monitoring funcitions, some unreliable speed situations can be automatically detected (e. g. new ECAM warning "NAV ADR 1+2+3 FAULT"), and some ECAM procedures will lead to the BUSS activation by requesting to switch OFF all ADRs.


6 Conclusion

An unreliable speed situatio may be difficult to identify, due to the multiple scenarios that can lead to it. Therefore, training is a key element: indeed the flight crew's ability to rapid detected the abnormal situation, and to correctely handle it, is cricial.

In case of any doubt, the pilot should apply the pitch/thrust memory items, and then refer to the QRH to safely fly the aircraft, and to positively determine the faulty source(s) before eliminating it (them).

In addition, to further assit the pilot in detecting the failure and safely fly the aircraft, Airbus has developed the BUSS, which provides a safe flying range indication.

Finaly, to reduze the probally of experiencing unreliable speed situations, on-ground actions, such as comprehensive maintenance and through pre-flight exterior inspection, should be stressed. "

[Lonewolf_50]

In Re RR NDB's post of a 2007 discussion of Unreliable Airspeed in the Airbus family ...
But the main difficulty is to rapidly detect an unreliable speed situation. Reaction time is crucial, since the aircraft may stall and overspeed conditions could cause aircraft damage.
Did the gent in the right seat interpret "safe conduct of the flight" to mean "don't overspeed the aircraft?" There have been a number of estimates that a concern of his was overspeed, and wanting to not do so.

But if the affected ADR cannot be identified, or all ADRs are affected, then the flight crew will fly without speed reference, using the pitch and thrust tables. ... snip a bit ... 4.3 Flying using pitch/thrust tables
The crew never got into the logic tree of methodical trouble shooting that got to this decision point, if their lack of discussion on "which ADR is out at this point" is an indicator.

An unreliable speed situatio may be difficult to identify, due to the multiple scenarios that can lead to it. Therefore, training is a key element: indeed the flight crew's ability to rapid detected the abnormal situation, and to correctely handle it, is cricial.
Anyone at AF have a handle on how to train for this? Some lawyers are probably contemplating villas in St Tropez, betting on the answer being no.

In case of any doubt, the pilot should apply the pitch/thrust memory items, and then refer to the QRH to safely fly the aircraft, and to positively determine the faulty source(s) before eliminating it (them).
WHICH memory items? The ones for TOGA and nose up?

Granted, as has been discussed over and over, most succinctly by PJ2 but also by others, at their flight level, pitch and power for level flight is what was called for, to allow them time to trouble shoot and work through the systems faults. But what was the pilot trained for, and what was his most recent training scenario regarding this malfunction?

This takes us back to question 1, which is what the guy at the controls believed the risks to be to the flight.

[RR_NDB]

But the main difficulty is to rapidly detect an unreliable speed situation. Reaction time is crucial, since the aircraft may stall and overspeed conditions could cause aircraft damage. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-15.html#post7400127)

Worse than that is complete loss of SA due (partially) misleading info presented by the System to a (non properly trained) crew after erratic and inconsistent data contaminated System

My rationale simply is:

Delegate to the crew the task (as per Airbus SAS) is an error. Using proven DSP techniques an A/C subsystem may warn on impending UAS. And deterministically inform of an important issue.

I posted several times this earlier

DSP and Signature analysis comment by andianjul:

Basically, the electrical ‘signature’ of a valid signal from any pitot that is being impacted by air molecules will appear decidedly different to the ‘signature’ from a blocked pitot. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-15.html#post7399076)

:ok:

[DozyWannabe]

Do you think you could meet the reliability requirements? Remember that adding complexity adds potential points of failure.

[RetiredF4]

DozyWannabe
Do you think you could meet the reliability requirements? Remember that adding complexity adds potential points of failure.

Is this an honest question in relation to technical feasability or in relation to beancounters available assets?

Just remeber, the moon landing was 43 years ago.

[Lyman]

Doze...

You miss the point completely. Adding complexity (sic), is done by the ADRs, when they act on deviant raw data at the pitot aperture, then synthesize and report to the pilots a value that is already known to be false.

By the time the aircrew heard the Cavalry and Saw Master Caution, the computer had been stumped for ten seconds. Had the crew been privy to an amber caution the instant the ADR was evaluating, we may not be here three years later. Add to that a Law degrade that is annunciated after the fact, and the stage is set.

Basic cf at the interface....

[RR_NDB]

Hi,

Few days ago we celebrated (http://www.imagens.tv/) the RTW in a PA46 (piston powered) (http://en.wikipedia.org/wiki/Piper_PA-46#PA-46R-350T_Matrix) of a friend (20) and my third son (23) both aviation students.

During the mission preparation, flying to met an aviation ace in Rio de Janeiro i emphasized to them on the limitations of the A/C instruments.

And when flying in russia (single pilot due ferry tank weight) the Capt. faced a serious engine oil issue, when overhead UEMO PSN bound to Yakutsk airport.

The plane landed there in emergency conditions and during the analysis of the incident discussing with the pilot we concluded on the convenience to have an oil level meter.

To learn on low oil level just by oil pressure indications is very dangerous.

So, what this relates to F-GZCP?

To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies.

In both cases, the Signature analysis of the analog signals can provide to the crew a very useful information in order to allow a good crisis management, before worms could infect the scenario.

Some posters here worked with DSP (Digital Signal Processing) and know how feasible is a subsystem capable to help decisively at UAS onset.


In the carter oil Liquidometer case it seems in a first analysis you may have a pretty good signature by some temp. sensors installed in the carter. The splash is distinct at decaying oil levels during long flights.

RTW1 (http://www.pprune.org/private-flying/488196-around-world-single-engine-piston-plane-part-1-mission-preparation.html#post7250779)

RTW2 (http://www.earthrounders.com/)

[RetiredF4]

RR_NDB
Few days ago we celebrated the RTW in a PA46 (piston powered) of a friend (20) and my third son (23) both aviation students.

You should be very proud of your sun and his friend!
Congrats!

[Lyman]

"To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies."

That is my point, exactly. It is more than that, it speaks of an ignorance at the most basic level of how things work, and how a pilot needs to assimilate data.

More than any other "improvement", the logic needs a laundering. Positioning a stick to a percentage, to gain a deflection, and waiting for the response of the airframe is lunacy.

At the most basic level, the airbus forestalls the decision a pilot must make immediately, or....Pay the consequences of starting behind, and having to catch up.

36 prior UAS? Nothing to exonerate the bus there, no specific procedure, mostly dumb luck...
How does a pilot stay ahead of the airbus?

[DozyWannabe]

Is this an honest question in relation to technical feasability or in relation to beancounters available assets?

Just remeber, the moon landing was 40 years ago.

I don't doubt for a second that it's technically feasible to do, but the level of reliability required to meet certification necessitated the use of simplistic logic.

I know it's a good-natured joke, but this is where the "HAL" references stop being funny and start being a serious barrier to understanding. The reason for this is that the fictitious HAL was a central computer that had very complex programming and sole control over the entire vessel. What you have in aircraft like the Airbus and Boeing FBW types is a network of computers that are constantly cross-checking each other. The subsystems within are essentially a collection of finite state machines - each one not much more complex than those you'd find in your washing machine, but interlinked together to build a complex interoperating system out of simple parts.

These parts had to be rigorously tested individually and gradually pieced together in a programme that took the best part of a year. My old prof's class started with tales of making safety-critical software reliable and the exciting stuff software could be used for, but most of it was spent poring over graphs from the various regression tests that were run during that programme in order to prove the technology and determining with algebraic functions whether they would meet the stringent reliability requirements imposed by the aviation system.

It's funny that you should mention Apollo, because I've been diving into that a lot recently - Apollo 14 in fact holds the distinction of being the first software patch applied to a mission-critical system on an aircraft, and they did it *in space*. But the Apollo crews were almost all engineering test pilots with the ability to call on 400,000 people to help them solve any issue that came up, and they all accepted a significant degree of risk in order to attempt the journey. That's a far cry from being a line pilot out over the ocean, responsible for a couple of hundred lives and some distance from technical assistance. And as such, the systems need to look after themselves to a greater degree in that situation.

To be honest, I'd be surprised if the A380 systems haven't had a significant upgrade in that area compared to the older types, and the A320NEO will probably have systems derived from that work. But the original FBW series will still be using hardware of a mid-80s vintage, and I doubt it would have excess process bandwidth to cope with such a function - which is why Airbus produced the BUSS option (which can be retrofitted) as a stopgap.

[infrequentflyer789]

I haven't had time to be on here for a while, looks like it's got interesting and informative again, but the magic "DSP" solution is getting a bit silly.



Worse than that is complete loss of SA due (partially) misleading info presented by the System to a (non properly trained) crew after erratic and inconsistent data contaminated System


Exactly what misleading info was displayed prior to the stall ?

As far as I can see the only misleading info at that point would have been speeds which were briefly too low before they disappeared. Why would seeing a suddenly low speed lead PF to stick the nose 15deg up ? If, prior to close of monitoring window, the indicated speed had been M1.5 then I could see a point, but it wasn't.


Delegate to the crew the task (as per Airbus SAS) is an error. Using proven DSP techniques an A/C subsystem may warn on impending UAS.


What proven DSP techniques would this be ? You keep mentioning DSP as if it were some kind of magic that Airbus engineers have never heard of. It's not magic, and of course they have.

Read the Airbus text properly - it states that one human cannot explain to another the set of rules for determining UAS, because it is too complex . Yet with your "proven DSP techniques" the machine can solve a decision problem that humans can't.:confused:

That's not DSP, it's AI, and it doesn't exist (at least that we know of). I doubt very much that we will have it any time soon either (I may have been out of DSP research for 20 odd years but I know people still in the field, and in machine learning / AI).

It's not a beancounter problem that we don't have this kind of tech either - the amount of money and brain power thrown at it is enormous - it is hard (and maybe impossible).


And deterministically inform of an important issue.


And how exactly does that stop the crew stalling the a/c when so informed ? How deterministic ? What level of false alarms ? How would crew reaction to a false UAS alarm be different to crew reaction to a real one cause] ?

What exactly is the rest of the a/c system going to do when it gets your DSP warning / alarm ?

- drop the a/p (you can't keep it in on suspected-invalid speeds) ?
- drop the protections (ditto) ?
- change control law (you aren't proposing a new FCC, just a new UAS detection, right) ?

And is that not exactly what happened ? And what did the crew do as a result ?



I posted several times this earlier

PS2

DSP and Signature analysis comment by andianjul:


If only repeating it made it right, or made it that simple.

Let's try some real info shall we ?

https://data.epo.org/publication-server/pdf-document?pn=2453245&ki=A1&cc=EP

Note that:

1. It's a patent so it's a PITA to read - but it gives us the benefit that its contents are legally stated under penalty of perjury (I think - may vary a bit with jurisdiction).

2. Note the filing date. This is state of the art, and post-447.

3. From the background statements on P3:

There is currently no reliable system and method for detecting whether a pitot tube and/or static port is
either malfunctioning or is indeed blocked by any of the
aforesaid debris


4. The technical detail clearly states at least one reason why the suggestions you've made and linked to above are somewhat over-simplistic (being kind).

5. The proposed solution is not DSP (it might use it but it is so insignificant that DSP is not mentioned). It's about the sensors and the physics. Always assuming this idea even works at all and at an acceptable error rate [neither of which is a requirement for filing a patent]



Finally, this crew knew they had UAS - [I]"we’ve lost the speeds". That isn't the problem.

To what level of conciousness that knowledge penetrated at that time of night may be relevant - neither pilot seems to have processed "15degrees up at MAX ALT".

More relevant, however, is that when correct speed information came back (30s) and needed to be acted upon (in the window before they went so far out of the envelope that all airdata was bunk), it was (probably) not believed.

Detecting and alerting UAS is only (or less than) half the problem - you also need to detect and inform when the UAS event has ceased.

Feel free to post your patent number when you file :-)

[RR_NDB]

Hi,

infrequentflyer789 (http://www.pprune.org/members/214043-infrequentflyer789):

...but the magic "DSP" solution is getting a bit silly.
(http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-16.html#post7400995)

I am here looking for aviation safety and motivated to discuss concepts, etc. related to it. I am a R&D professional always motivated to look for solutions. Your comment sounds a little bit "non motivating" for me to reply in detail on the improvement that IMO can be made to the important UAS issue. Anyway i will try to explain something feasible.

You need to process the analog signals before entering the System. Doing that you may have an information very useful mostly if System degrades the A/C and (currently) not present properly the reason for. The idea is to have an analog signal processing helping the crew with a redundant information. False positives would not cause problems and the sensitivity could be adjusted.

I dont´t like the approach to just rely on System output to diagnose what´s going on.

Yet with your "proven DSP techniques" the machine can solve a decision problem that humans can't.The UAS processor would not be there to solve anything. The machine would be an extra (IMO important early warning) resource to help the diagnose.

I mentioned the Airbus SAS paper but the other companies could also benefit from this approach, for the crew decision making. (The subsystem just presenting information to the crew)

What exactly is the rest of the a/c system going to do when it gets your DSP warning / alarm ?.Nothing automatically.

There is currently no reliable system and method
for detecting whether a pitot tube and/or static port is
either malfunctioning or is indeed blocked by any of the
aforesaid debris.No method? :mad:

somewhat over-simplisticThe concept is simple: Process the analog signals and present it to the crew, immediately. How? There are simple and effective ways to do.

Detecting and alerting UAS is only (or less than) half the problem A "half" that triggered a cascade of events

...you also need to detect and inform when the UAS event has ceased.No problem

Feel free to post your patent number when you file :-) Some ideas an R&D professional could publicly with the sole intent to a faster implementation. :) (IBM PC x Mac, as an example).

Not magic, just a powerful processing to help the crew. This can be implemented!

I am not in this business. And no intentions to invest in it, currently.

On the "misleading", this is to be covered in another Thread. Will do it ASAP.

[RR_NDB]

Hi,

infrequentflyer789 (http://www.pprune.org/members/214043-infrequentflyer789):

Finally, this crew knew they had UAS - "we’ve lost the speeds". That isn't the problem. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-16.html#post7400995)

IMO, problem is When you lost confidence in the machine you are operating.

If you bury (or not present assertively) an information of this magnitude you may have a situation when a non properly trained crew could be confused. I commented in an early post on the Albert Schweitzer quote. "Confidence is the greatest asset of any successful enterprise..."

[gums]

Gotta admit, but detecting the pitot-staic failures due to icing and bugs or tape over the ports is different than detecting an electrical failure to the probes.

Only incident I had was a static freeze as I descended thru icing conditions ( heaters had failed). Was a no-brainer, as altitude on the steam gauges froze and IAS increased as I descended at a constant pitch. The HUD flight path marker stayed where it was supposed to, so very obvious what the problem was.

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day.

Comparing inertial/GPS data with the pitot-static measurements is hard in the cruise mode. The inertial data is noisy with altitude, and GPS altitude data is worse. The best display for we pilots is a flight path marker that shows what we are doing WRT the local horizontal. Don't even need AOA.

No comment/critique on PF actions, especially after comment "lost speeds".

[RR_NDB]

Hi,

gums:

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-16.html#post7401088)

:ok:

[Hunter58]

Following procedures from the start certainly would have as well...

[BOAC]

Hunter is absolutely right. Round and round we go trying to produce the foolproof system, and we need to remember what they say about those.

As I said on 27 Aug here - all jolly good stuff, but we have - as 'standard' - 2 pilots and triple sets of instruments to allow us to try and determine the 'valid' indication, using Human intelligence. Trying to present yet another 'AI' system which will 'solve' the problem is asking for trouble, and also assuming that the human part of the system is:-
a) Going to notice
b) Going to understand
c) Do the right thing.

AF447 blows that out of the equation. Here you all are looking presumably at yet another set of chimes/mail or female voice messages/ECAM indications/flashing lights whatever. I suspect all would have been wasted in AF447 and they would have hit the SA with even more warnings.

Icarus rules, in a way? Don't fly too high, son.

[Lyman]

BOAC

a) Going to notice
b) Going to understand
c) Do the right thing.

No new chimes, no new nuthin. 'Display the results from each Pitot head'* and let the pilot consider turbulence, Windshear, P-Heat, etc. for the cause of the discrepancies.

447 did NOT have a redundant air sampling system. It was repetitive, not redundant, there is a major blunder in merging data from three sources that use the same equipment in three different locations. Using different models would only be partially better. If all the computer is doing is averaging within parameters, that isn't Ai at all, it is not even modern computing.

Would you be happy with a common N1? An average heading? Listening to two radios on different freqs?

* displaying separate results to the pilots as well as the computer is redundancy.

[BOAC]

No new chimes, no new nuthin. 'Display the results from each Pitot head'* and let the pilot consider turbulence, Windshear, P-Heat, etc. for the cause of the discrepancies - think about that - these guys could not even read an AI or altimeter..air sampling system. - you have lost me there - wtf is one of those?
Would you be happy with a common N1? An average heading? Listening to two radios on different freqs? I don't believe there was a problem with N1 (apart from 'too many') or heading? Radios - did it a lot of the time. Most pilots do. Lost me again!

[BOAC]

Lyman - I think I'm going to have to pass on your posts:ugh:

[HazelNuts39]

Lyman,

sure you know the difference between the median and the mean?

[TTex600]

What told the AP and AT to disconnect?

[DozyWannabe]

What told the AP and AT to disconnect?

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

Chapter 10. Navigation (http://www.hursts.eclipse.co.uk/airbus-nonnormal/html/ch10.html#adr-faults)

[Lyman]

TTex600


TTex600 What told the AP and AT to disconnect?


There's a civil question. My question from the beginning, since it is likely that the crew had more experience with autopilot loss due to exceeded control limits than
"UAS". "vitesse douteuse". At 447's date with fate, the abnormal was called

Unreliable speed.

Tex, I believe the crew did NOT know exactly what caused the loss of autopilot, not immediately. Immediately is the standard. It was referenced at 2:16.0, when the PNF said "lost the speeds". It was at 2:22.0 when the PNF said " Alternate Law".

Rather than repeat the propaganda that has most here believing the speeds problem was known right away, I will simply say that bit is not known except at those two indexed times, from the CVR.

So it occurs to me that a conference among computers should have extended an invitation to the flightcrew to be privy...

If, since the timing is not known except at 2:16:0, the PF may have thought the a/p quit due to its computed conclusion that it was unable to command sufficient controls deflection by its Parameters of operation. There was turbulence, and it would have been a possible determination. Possible.

A casual look at the graph of Vertical speeds and g shows a heavy moving around like a trainer, at least possibly. Possible.

PF could have missed the speeds issue on his PFD, he also could have missed the Law degrade, which is very important. It is important because when the a/p quits due handling in turbulence, on this aircraft, it remains in NORMAL LAW.

Was this possibly his foundation? Possible?

[HazelNuts39]

What told the AP and AT to disconnect?Final report:
1.16.3.1 Analysis of the initial sequence
Analysis of the FDR parameters and of the data contained in the two FMGECs’ nonvolatile memories showed that:
ˆˆ The ADR 2 speed fell between 2 h 10 min 03.5 et 2 h 10 min 05;
ˆˆ the ADR 1speed fell for less than one second from 2 h 10 min 04 s to 2 h 10 min 05, causing:
- the disconnection of the autopilot,
- the triggering of “PITOT PROBE” monitoring in the FCPC causing the transition to alternate 2B law;
ˆˆ The ADR 3 speed fell temporarily from 2 h 10 min 07 s to 2 h 10 min 10 s, causing, in the following second, the loss of autothrust and the disappearance of the Flight Directors; it then fell again at 2 h 10 min 14,
ˆˆ The speed on ADR 1 fell again at about 2 h 10 min 08 s, causing the loss of the autothrust and of the flight directors within the next second.

[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]

There's a civil question. My question from the beginning, since it is likely that the crew had more experience with autopilot loss due to exceeded control limits than "UAS".

And your basis for that conclusion is?

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

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.

So it occurs to me that a conference among computers should have extended an invitation to the flightcrew to be privy...

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

ˆˆ The ADR 2 speed fell between 2 h 10 min 03.5 et 2 h 10 min 05;
ˆˆ the ADR 1speed fell for less than one second from 2 h 10 min 04 s to 2 h 10 min 05, causing:
- the disconnection of the autopilot,
- the triggering of “PITOT PROBE” monitoring in the FCPC causing the transition to alternate 2B law;
ˆˆ The ADR 3 speed fell temporarily from 2 h 10 min 07 s to 2 h 10 min 10 s, causing, in the following second, the loss of autothrust and the disappearance of the Flight Directors; it then fell again at 2 h 10 min 14,
ˆˆ The speed on ADR 1 fell again at about 2 h 10 min 08 s, causing the loss of the autothrust and of the flight directors within the next second.

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]

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

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]

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?

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 (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-16.html#post7402181) goes through the different meanings of the messages and what causes them (and the relevant FCOM references).

[RR_NDB]

TTex600:

Why deny that info to the pilot? (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-17.html#post7402544)

In other words: Why not inform CLEARLY, IMMEDIATELY?

Why pilots must diagnose it by System "output"? As per Airbus SAS paper? (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-15.html#post7399126)

Considering that UAS is an important "input" ?

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. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-17.html#post7402827)

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

[TTex600]

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.


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'm not asking for the machine to tell me how to fly the airplane.

Machine says: "ADR FAULT" or "ADR DISAGREE"

why not just make the first line of ECAM, "UAS procedure - Apply" ?
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!

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!

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]

Could it perhaps be more specific, e.g. "IAS DISAGREE" or "AoA DISAGREE"?
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]

"Hey, Gums, your pitot system is FUBAR!" (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-17.html#post7404049)

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 am confused. Isn't what you are asking for the same as the machine telling you how to fly the airplane?


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.

[Lyman]

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?

[TTex600]

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.

[Lyman]

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

[mm43]

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/src:www.pprune.org/get/images/smilies/wink2.gif

[Hunter58]

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

[Lyman]

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.

[Cool Guys]

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.

[Lyman]

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.

[DozyWannabe]

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

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.

[Lyman]

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

[mm43]

@DozyWannabe,The "B" system is the same as the "A" system.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.

[TTex600]

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

[DozyWannabe]

@DozyWanabe,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.

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.

[mm43]

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

[Hunter58]

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?

[DozyWannabe]

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

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

[infrequentflyer789]

I mean ANY, ADIRU, ADR, pitot, static, etc, issue OR any unexpected Autopilot disconnect - as requiring the immediate implementation of the UAS procedure.

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 ?

[infrequentflyer789]

Existence of a patent and existence of a fully-functioning system are two different things.

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 ?

[TTex600]

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

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 ?

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.

[bubbers44]

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.

[CONF iture]

These guys knew they had UAS (cvr)
It is not what the CVR tells (http://www.pprune.org/7129482-post2.html).
If the guys knew, why the PNF would have said :
Fais attention à ta vitesse - Fais attention à ta vitesse

As the BEA attributes to the NAV ADR DISAGREE ECAM MSG the first priority after the AUTO FLT AP OFF, why that message did show up only 2 minutes later ?

[bubbers44]

I think letting automation taking away your pilot skills because the company wants you to fly on autopilot all of the time is the problem. You forget how to fly manually.

[gums]

Thanks, Tex and Bubbers

I look at the transcript and see the PNF call out repeatedly that "we are climbing".

yet the nugget in the other seat keeps pulling and pulling except for a few forward stick movements.

BEAM ME UP!

A basic altitude/speed indicator steam gauge would not have helped in this case due to all the other things the crew believed that HAL was doing to "protect" plus various audio alerts and such. Then there's questionable flight director cues. Gotta admit that if I had thot about UAS from reading previous incidents reports, I would prolly just hold what I had and slow down on any drastic stick inputs. Hell, wasn't like we were gonna hit the ground in a few seconds. That's just my gut reaction.

A simple warning that the air data was questionable for HAL could have allowed the crew to revert to manual flying, ya think?

[Hunter58]

Gums

Thenred cross over the speed takes tells you that the info is not available, neither for you nor for the HALs. What else do you need?

A felt 5000 pages of the threads talk abou infinitely fine details of many variations, but there is no real discussion to the real issue: why did the PF pull the stick like a madman and why did four eyes in other heads not capture basic instrument indications?

There were a number of other, smilar events REPORTED, where the crew obviously understood what to do. And we can assume that there were another many UNREPORTEd events as well. There are many airlines who still classify UAS events as non-reportable.

The question remains. Why did the PF pull?

[Lyman]

If you want a conclusive answer, you are out of luck. A likely one(s), is right in front of us, confusion re: STALLWARN, STARTLE, INCORRECT Approach to STALL recovery, TOO MUCH information, FATIGUE, WEATHER, lack of experience in the domain, lack of understanding/training in the abnormal, poor FD design, poor STALLWARN design, CRAP CRM, Captain in the wrong part of the aircraft, animosity instead of teamwork, ET CETERA.

Any one of these could fluster anyone, and those who brag differently, are blowing smoke.

Start with: PF's initial NU was proper, its continuance was not.

[RR_NDB]

Hi,

TTex600:

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. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-18.html#post7409061)

:} :mad:

I would prefer to learn what HAL receives before it presents the puzzle. When it receives garbage it will present processed garbage. Richer, more complex. :}

Lyman:

...lack of understanding/training in the abnormal, poor FD design, poor STALLWARN design,...

(http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-19.html#post7410299)

Lack of understanding on UAS was the trigger in this case

Hunter58:

Thenred cross over the speed takes tells you that the info is not available, neither for you nor for the HALs. What else do you need?
(http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-19.html#post7410259)

Why not a retrofit? No HAL bandwidth problems, convenient redundancy, low cost implementation, etc. Why not?

We know the answer. :sad: (another set of HUMAN FACTORS) :mad:

[jcjeant]

AF pilots like stall ?
http://www.pprune.org/rumours-news/495368-af-321-close-stall-2.html#post7410668

[gums]

Thanks, Hunter. The same question that haunts me.

I see a PNF telling the nugget that "we are climbing". a few times

I realize that a "crewed" plane has to allow for experience and a clear chain of command. I do not see this with the AF477 crew. Not having flown a jet with more than one pilot ( me), I have trouble understanding the mentality of the "crewed" planes. My VooDoo experience had a RIO in the back seat with no flight controls, so the guy told me where to go, and "turn left", "climb", etc. I could also tell if I was pressing the envelope by his breathng rate on hot mike. Heh heh.

It is easy for us to say what we would have done. My guess is that the PNF was trying to decode all the ECAM messages and such, but still pointed out to the nugget that "we are climbing". I also believe that the PNF should have exerted his "seniority" in a forceful manner. But never having flown a jet with two "pilots", I am not "in the zone" with you heavy pilots.

[DozyWannabe]

...due to all the other things the crew believed that [the systems were] doing to "protect"...

To be fair gums, that's speculation on the part of the PF's assumptions. Also, we know that the PNF called Alternate Law and should thus have been aware that there were no hard protections any more.

I suspect that the PNF didn't spend any more time than necessary "heads-down" in the ECAM, because shortly after making those calls he's verbally correcting the PF on his flightpath. If he saw "ALTERNATE LAW (NO PROT)", then it's likely he would have seen the preceding "NAV ADR DISAGREE" too.

I can't be certain, but I have to say that I don't think it's a question of inadequate annunciation of the UAS problem. The evidence suggests to me that the result of the PF's immediate instinctive action on AP disconnect quickly became a greater threat to the safety of the flight than the UAS, and it was that which caused confusion and indecision in the PNF. From that point onwards it becomes purely a CRM issue.

[gums]

Problem I see as a dinosaur from single seat planes is lack of authority from the more experienced PNF. Hell, I was the aircraft commander for my whole career. Only had about 4,000 hours, but damned near that many landings, maybe more. I used the A/P all the time to allow me to scan an approach plate, set my IFF, etc. I even allowed HAL to follow the ILS when in the VooDoo. Just to see how good he was. My 100/one-eigth landing was pure manual, with super talk vrom a Navy chief on the PAR scope.

As with others, I can't believe the nugget would pull back and hold it for so long. I completely understand the insidious approach to stall and then actually getting into the stall. The plane obviously has great aero, so no severe shaking or wing rock or....... Hell, the F-102 I flew a hundred years ago and the Concorde just had increased sink rate as you slowed down or pulled hard. BFD. The Deuce was so docile that one of my classmates damaged the main gear by trying to "flare" and then having a severe sink rate at touchdown. I think that the Mirage pilots here will have similar war stories.

I shall still maintain that the PF and the PNF were thinking that HAL would "protect" them from extreme AoA, even tho' the stall warning was displayed over and over.

'twas a sad day/night. I assign some fault to the plethora of warnings/cautions and such, with no clear indications of what was FUBAR. But my main feeling is what Bubbers and others have opined - hold what you got and take a few seconds to get squared away.

that;s my feelings, folks....

[DozyWannabe]

I shall still maintain that the PF and the PNF were thinking that HAL would "protect" them from extreme AoA, even tho' the stall warning was displayed over and over.

I say again - the PNF knew they were in Alternate, so he should (and probably did) know that there were no hard protections from that point.

The grey areas are where procedures and drills meet human psychology, especially the facet of human psychology that instinctively tries to deny that the problem or danger could be as great as it is. We saw it at Tenerife when the F/O and F/E let the Captain take off despite both of them being unsure of their safety, we saw it with Birgenair 301 when the two F/Os could see what was happening and yet did not physically take control and - outside of aviation - we saw it twice at Chernobyl when the shift leader refused to believe that his bungling the safety test could have destroyed the reactor, and later when the plant director ignored the level of radiation leakage from the portable equipment (which indicated 15,000 roentgens/hr), instead preferring to believe that it was at a relatively safe level as indicated by the plant's equipment (which went off the scale at 3.6 roentgens/hr).

Another potential HF issue recalls the Kegworth crash, when radio calls distracted the crew from performing troubleshooting that could have clued them into shutting the wrong engine down. The AF447 PNF was clearly monitoring the ECAM initially, but his attention was drawn away by the attitude of the aircraft following the PF's stick inputs.

[Lonewolf_50]

should thus have been aware that there were no hard protections any more.
Dozy, you say this in retrospect, and with the benefit of three years, plus, of dicsussion of this issue.

You are making an assumption unsupported by any evidence we have.

It cannot be known that he
a) knew that
b) associated that at the moment with his immediate flight problem.

Whatever he knew

as opposed to whatever was or wasn't written in various manuals, was or wasn't covered in training, was or wasn't reinforced in various training

he may have also made an assumption about what the PF knew (as you are doing with him). This would shed some light on why it seems to have taken him a while to realize that something other than a bit of basic airwork was the problem over there in the right seat.

If he ever grasped that.

The AF447 PNF was clearly monitoring the ECAM initially, but his attention was drawn away by the attitude of the aircraft following the PF's stick inputs.
Could be, and likely ECAM and multiple screens took up much of his attention.

That leaves us lacking in understanding why a particular procedure was not called out and executed: the UAS drill that has been much discussed for the past year or so.

According to you, he knew that too.

Knowledge not applied often appears equivalent to ignorance, eh?

(See also Scripture, from the Book of James: Faith without works is dead. Or as they say in Missouri: Show me!).

Aviate-Navigate-Communicate is the order of operations for the crew, not just the guy with stick in hand. If the other gent is having trouble flying, you help him do that first, get the rest of it sorted out later.

Well, that's what I was taught in CRM.

And to ice that cake, I'll never forget the day another crew member, in an aircraft with retractable gear, reminded BOTH of us pilots up front that "we ought to have the gear down to land" just before we began our flare. We took his advice, and he drank for free for more than one day.

Basics first.

By the whole CREW.

[DozyWannabe]

@LW50

I appreciate what you're saying and you may be right. However, the fact is that once outside of Normal Law, there are no protections which will hold the aircraft in a safe attitude in spite of the PFC input. 2-3k hours on type mostly in autopilot can explain the lack of manual handling ability, but it cannot explain the lack of knowledge of the systems on which they relied.

The loss of hard protections in *any* Alternate Law mode is down in black and white in the FCOMs and should be basic required knowledge when flying the type. This is why I found the hamster wheel regarding the Alternate modes so baffling, because in any flight law outside of Normal, the aircraft will follow PFC input right through Alpha Prot and Alpha Max if that input is sustained.

I'm speculating openly on HF issues with possible regard to this accident - I'm not claiming any certainty over what might have happened.

You mention a timely reminder to lower the gear - and I'm absolutely with you on that whole sentiment regarding A-N-C and CRM. That's why I'm speculating that the second the PNF noticed the unusual attitude, it effectively drew his attention away from the technical troubleshooting and quickly became his overriding concern (hence saying it was a CRM issue from that point onwards!)

[gums]

Thanks, Wolf.

Sure glad Doze ain't up front analyzing all the data and trusting HAL. Whew!

Hell, the thing is acting like we designed it. It's "their fault". etc, etc.

The AoA "protections" should have remained in force, as actual CAS never got below 60 knots. Many ways to verify the AoA inputs, and AoA is prolly the most important flight parameter for all phases of flight.

I re-read the CVR and see the PNF reminding the nugget that "we're climbing", two or three times. No clue as to what the PNF did after that or during that. But the nugget kept pulling, maybe believng that HAL would prevent a stall AoA.

[CONF iture]

then it's likely he would have seen the preceding "NAV ADR DISAGREE" too.
That message was not preceding anything ... it came up much later, far too late to give valuable information to the crew.

[DozyWannabe]

@gums:

"HAL" told the crew that - for the moment - it couldn't deal with the speeds, and the PNF seems to have been aware of that fact. The flight control system never did anything untrustworthy - the annunciator system used the <60kts value to inhibit Stall Warning (albeit very late in the sequence), but I suspect that it would have been the same in any other modern type.

Maybe I'm expressing myself in a way that's hard to understand, but I'd like to know where you get the "Dozy trusts HAL" idea from, when it has no bearing on anything I've said.

As soon as Alternate Law is triggered and latched - even if the AoA protections remain in force - they cannot counteract a sustained PFC input because the system is designed to defer to the human pilot if Normal Law cannot be maintained. If I recall correctly if the aircraft is flying the soft protections will attempt to return the aircraft to a safe attitude if the stick is released, but in this case the stick was never released.

It's possible that the PF either never heard or failed to understand the consequences of the PNF's "Alternate Law" call, but the idea that the PF believed the hard protections were still active can never be anything more than speculation.

@CONF iture - reference? [EDIT : You're right - NAV ADR DISAGREE came sometime around 02:12:44 - so it must have been an ADR FAULT triggering ALTERNATE 2. Nevertheless, the PNF seems to have been aware that pulling up was not the correct response...]

[Lyman]

gums, " But the nugget kept pulling, maybe believing that HAL would prevent a stall AoA."

Is there another way to see it?

The report is cherry picked sufficient to lend it to simplistic statements such as this. Gums, "nugget" is not a terribly professional term...

Dozy, this flight path went South in the first 20 seconds, tops. That is 2:10:25.
Speeds were acknowledged as duff at 2:10:16, and (generic) Alternate Law six seconds later, at 2:10:22. Not AL2.

PNF quickly stopped correcting PF, and ended up confused, telling Captain "We have tried everything, what do we do?"

Failing a complete CVR, and the true "nuggets", BEA has not made a case for a more complete picture.

I do not trust that BEA have redacted only irrelevant commentary and audio signals from the CVR for the public record....

That is not a widespread belief, but it is mine.

regards

[CONF iture]

so it must have been an ADR FAULT triggering ALTERNATE 2
No ADR FAULT.
The speed fall by ADR 2 and 1 were enough to disconnect the AP and cause the transition to ALT LAW but why the system is not telling the crew the reason for which it takes these steps ?
NAV IAS DISCREPANCY or SUDDEN CHANGE or UAS ...
This could be a serious help to the crew to understand what's happening and switch to the appropriate procedure.

I have not read the BEA mentioning the NAV IAS DISCREPANCY ecam msg ... did I miss it ?
Was it available on F-GZCP ?

[Lyman]

What could possibly have caused the a/c to be unable to hold a heading? I think there was a reason for the NAV glitch.

Ref: BEA trace of leaky turn to starboard....

[jcjeant]

Hi,

DW
It's possible that the PF either never heard or failed to understand the consequences of the PNF's "Alternate Law" call, but the idea that the PF believed the hard protections were still active can never be anything more than speculation.This speculation seems to still be the most plausible
In fact it is supported by the fact that the pilot continues pulling on the stick despite the stall alarm and the remarks of the PNF
More .. the PF never acknowledge verbally the PNF "Alternate law"
A "normal" pilot (pilot knowing the Airbus flight laws) can do this if it has (or thinks) the protection in force

[Lonewolf_50]

Gums, "nugget" is not a terribly professional term... Lyman, given how much stick and rudder time your average long haul pilot seems to get, "nugget" seems most appropriate, particularly when you consider that gums speaks from the PoV of a single seat, stick and rudder kind of pilot. ;)

In the Navy, nugget used to refer to one of our squadron pilots who had yet to complete an operational deployment with an aircraft, or to otherwise have low time in model.

We were all nuggets, once ...

[Lyman]

LoneWolf

Noted. My sense is that it is presumptuous, that a term like nugget is demeaning, and serves in the long run to cement a conclusion that may not be accurate, that the PF was some kind of flustered 'rookie'.

It may have happened that way, but public opinion is wildly vunerable to myth fabricated over time in the media.

My case, in point.

[RR_NDB]

Hi,

CONF iture:

This could be a serious help to the crew to understand what's happening and switch to the appropriate procedure. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-19.html#post7412728)

Any input (to the System) capable to promote important changes in A/C must be informed in real time and clearly to PF.

This is safer, much better than wait a complex System process it and present it´s output(s).

Airbus SAS philosophy relies on System to do this as the Design group paper (mentioned in earlier post) emphasizes.


Bandwidth (System) limitations. No problem: Implement an UAS (simple) device (retrofit).

Question: Pitot´s (and ADR) subsystems would be compatible?

[Lyman]

On a basic level, perhaps a more critical look at the parameters of autopilot in Turbulence? Any situation which presents as requiring manual handling should originate a loss of autopilot and reversion to manual flight. Not only UAS.

We here have consistently exonerated the use of Autopilot in this turbulence.

The pilots admitted they were entering cloud, but more important is the assumed icing up of all three pitots. Of course they were in cloud.

[Cool Guys]

Hey gums, I love your posts. I have to smile every time I read one. Don’t know why the couple of boisterous non pilots here have to push their opinion so much.

Truth is relative, what is real to you may not be to others.

[OK465]

I have not read the BEA mentioning the NAV IAS DISCREPANCY ecam msg ... did I miss it ?

CONF:

This is a good question.

From observation, this ECAM message will only appear if there is a 'single source' discrepany between the two displayed airspeeds. In other words, you're looking at, for example, one PFD at 250K and the other at 200K. One ADR output is erroneous and the message is providing info much in the same manner as the old 'instrument comparators' did. Something's displayed wrong here, you guys check it out.

With the displayed speeds sourced normally from ADR's 1 & 2, an erroneous output from ADR 1 OR ADR 2 (not both) will result in this message (10 second delay). (Conversely, if the problem is with ADR 3 and it is not switched, you won't see this message unless you had a reason to transfer either side to ADR 3.)

Once you get 'multiple' discrepancies (i.e. 2 or 3 ADR's), the message 'downgrades' to the ADR DISAGREE status.

What's interesting is...if this is done in sequence, 1 ADR and corresponding IAS DISCREPANCY, later followed by multiple ADR's and resulting ADR DISAGREE message, the IAS DISCREPANCY message is dropped out of the ECAM string permanently (not recallable), leaving only the ADR DISAGREE actions.

If you have simultaneous ADR problems (within 10 seconds), the ECAM jumps right to ADR DISAGREE & bypasses the IAS DISCREPANCY message completely, which may have been the case here.

With respect to the timing associated with ADR DISAGREE in the report, I recall someone saying in one of the much earlier threads that the times associated with the downlinks were not necessarily the actual times of the message appearance, but I could be wrong about this.

[gums]

Sorry if I offended any of the real pilots here.

Wolf has it right, and USAF called the newbies "Joe Baggodonuts", heh heh. The term "dweebs" had not been invented yet.

I adopted the term "nugget" due to my connections with Nasal Radiators way back then. It is used for the junior pilot or nav until he's in the other seat. No big deal, and the PF on AF447 was the most junior troop. 'nuf said.

All of we pilots were nuggets or less flattering descriptions in the beginning. We learned and we matured and we did just fine or wound up a smoking hole. Some great mentors led us, and we had the benefit of them along the way. Wouldn't be here today if not for them.

[gums]

Re: The Viper and memories of a distant universe


a private message reply to another member of our group after I got his post.

Video of a Viper flight included from my private message, and then one of my own.

PLZ note the tiny stick movements, so I guess that 1/8th inch shows up some of the time, heh heh.

GoPro [COCKPIT VIDEO] F-16 VIPER WEST HERITAGE FLIGHT @ 2012 CALIFORNIA CAPITAL AIR SHOW - YouTube

My reply to a member.....

Thank you xxxxx

Brought back many memories of that neat little jet ( first FBW, and look at stick movements on a replay).

New oxygen connects and the helmet display for off-boresight aiming of the missiles and A-2-ground tgt acquisition, etc.. Whew!

Note the lack of lag when the dude relaxes pressure on the stick.

Think that we had all that back in the late 1970's, and only FBW accidents were related to the power supplies to the confusers.

The thing was magic, and although I had doubts about all the "protections", I became a believer very quickly. They never gave up, and we always had "something" left, even if pitots went FUBAR, and so forth. Not like AF447.

Unlike the 'bus and the Boeing designs, we had zero mechanical connections except to the blow down bottle for nose gear and the throttle cable to the motor. Even the family model did not have mechanical conections to the stick that Joe Baggodonuts was using.

Was a great time, and was blessed to participate.

For viewing enjoyment, try this sucker using Quicktime or Final Media Viewer of my leading edge flap failure landing.

http://www.sluf.org/warbirds/lef-landing.m4v

thanks for the nice words...

[infrequentflyer789]

It is not what the CVR tells (http://www.pprune.org/7129482-post2.html).


In between your PF "gap" though, PNF says in one sentence: "on a
perdu les les les vitesses". Almost reads to me like PNF is completing PF's sentence which PF then confirms. PNF definitely knows and states it.


If the guys knew, why the PNF would have said :
Fais attention à ta vitesse - Fais attention à ta vitesse


But then why is the PF response to that "okay, okay okay je redescends". That line makes no sense to me - maybe PF was saying speed but pointing at altitude :confused:



As the BEA attributes to the NAV ADR DISAGREE ECAM MSG the first priority after the AUTO FLT AP OFF, why that message did show up only 2 minutes later ?

ADR and IAS disagree have been discussed before - both require specific sequences of events to trigger and not every UAS matches that pattern. See e.g. http://www.pprune.org/6597470-post730.html and http://www.pprune.org/tech-log/456874-af-447-thread-no-5-a-32.html#post6592148 but also worth google searching tech-log - there are many more.

IAS disagree might not have been installed on the a/c.

I would expect BEA to comment on any message that should show up but did not, and why any message did show up. Not sure we can expect comment on every message that did not show up because conditions were not met, or any system that wasn't installed - report would be 1000s of pages.

BEA don't comment on BUSS either (like IAS disagree, they don't even tell us if it was installed or not). We know AF didn't take BUSS option, I've seen rumours (maybe here) that they thought it wasn't any good ("useless" above FL26) - but maybe it was just the $$$. Either way, BUSS would in fact have made a difference to the sequence of events - but is not mentioned by BEA because they deal with what was on the a/c, not what could have been.

[CONF iture]

Thanks for the explanation OK365.

What I find disturbing is that the system takes the decision to disconnect the AP and switch to ALT LAW based on its analysis of the ADRs outputs but does not think as necessary to keep the crew informed about the reason it took that very decision ?
With respect to the timing associated with ADR DISAGREE in the report, I recall someone saying in one of the much earlier threads that the times associated with the downlinks were not necessarily the actual times of the message appearance, but I could be wrong about this.
P97 on the Final Report specifies that the NAV ADR DISAGREE ecam msg did appear only at time 02:12:44

IMO it was not related anymore to the initial conditions of UAS, but most probably to the latest flight conditions with high AoA and changing bank, all of it playing on the different probes and sensors.

[CONF iture]

In between your PF "gap" though, PNF says in one sentence: "on a perdu les les les vitesses". Almost reads to me like PNF is completing PF's sentence which PF then confirms. PNF definitely knows and states it.
But "on a perdu les les les vitesses" is more probably related to the disappearance of some speed symbols and is not a positive indication of UAS.

But then why is the PF response to that "okay, okay okay je redescends". That line makes no sense to me - maybe PF was saying speed but pointing at altitude
Because the PF was conscious that he had gained altitude which was detrimental to the speed. He did agree to go back down, but never took the necessary attitude to do so …
IMO they have never understand their initial problem and the reason for the AP A/THR DISC was a case of UAS.
Thanks for the links on the previous threads.

report would be 1000s of pages
It is not a good reason.
Remember, the accident is a consequence of a scenario of UAS initially, so it is imperative for the BEA to develop comment and analyze anything related to that matter. Of course NAV IAS DISCREPANCY ECAM MSG or the BUSS function have to be mentioned. It would require 10 pages at most not 800.

We know AF didn't take BUSS option, I've seen rumours (maybe here) that they thought it wasn't any good ("useless" above FL26)By procedure the BUSS is not to be used above 25000 feet.
IMO that equipment for AF447 would not have done the slightest difference to the outcome.

[UNCTUOUS]

When abstract and abstruse technology runs amok, it needs to be immediately apparent to a flight crew that anything (or everything?) in technoville is becoming unstuck.... or even just on its way out. Fortunately there is (prospectively) a digital way to do that - to "in your face" alert the crew of an imminent GIGO fiasco (GIGO = garbage in/ Garbage out). But more on that in a moment.....

Firstly it always helps to have the captain on the flight deck when faced with the need to intervene manually or interpret some confusing happenstance. It also tends to offload the cruise captain/F.O. and his oppo of the need to resolve any differences of opinion about what to do next. Solution? A klaxon in the captain's crew rest area would tend to galvanize el capitano into instant action. His prompt appearance on the flight deck would serve to defuse the always prevailing angst and uncertainty about actually making an assertive decision - possibly one that properly lies solely in the province of command. Acting resolutely and taking the initiative is laudable when success is the outcome. However when it isn't, it can often be career-shattering. Such is the nature of Monday morning quarter-backing aided by 20:20 hindsight. The fluster factor quotient in a two F/O cruise crew is the facade that lurks. Sudden exposure to an AF447 like scenario can freeze-frame cross-cockpit communications and comprehension. You need a licenced decision-maker on scene. That's what command is all about.

I honestly don't know how a captain can achieve slumber in any situation where two underlings are left to their own devices. It's not about trust, it's more about insecurity. I can recall springing out of an aft bunk and dashing to the flight-station in an Orion because my wakening nightmare had been that we were spinning into the ocean a few thousand feet below. The fact that we were asymmetric and hanging off the three props at endurance speed had a lot to do with my subconscious mindset. We were loiter surveilling a yacht full of drugs enroute to some unknown landfall. Of course, when I burst into the cockpit nothing was happening, yet I've relived that nightmare quite a few times.

So, what to do when the autopilot disconnects suddenly and the beast requires someone to instantly grab the reins? It's never totally apparent WTF is actually happening - what's trustworthy? what's possibly erroneous? what's the state of our automation modality? what's clearly failed? and most importantly, where to next with the trouble-shooting checklist? - particularly when the failure is epicentric and tentacular. The omnibus checklist series that covers all contingencies is yet to be written. Even if it was "to hand", it's never going to just flop open at the page you want. A noisome background of alarms and a panel covered with non-specific warnings serves only to alarm - the alert has already happened.

Failure of a pitot feed or an AoA vane are two exemplars that spring to mind. Reflect upon the accident to 5Y-BEN, an A310 that dropped into the ocean just off the end of the runway at Abidjan. There'd been prior instances elsewhere of the same nasty affliction that that flight-crew faced, a stick-shaker after take-off that just wouldn't stop - and a crew that responded
"properly" by unloading to avoid an imminent stall - but unfortunately terminating their trouble-shooting at sea-level. It appears that some ramp-rash to the AoA vane on the tarmac had gone unreported and went unnoticed on the walk-around.... so the stick-shaker was bogus. But whatever the cause, it's always the instantly apparent "cure" that's linked to a happy outcome.

Statistically, a perplexed crew is around 50% unlikely to come up with a workable solution when suddenly faced with "the unstraightforward". What to do about that?

One of the happier and fortunate aspects of our digitalis era is the ability to include self-check and to clearly report any discrepancies with specificity. BITE (built-in test equipment checks) has been around for decades, but it's normally restricted to a confession to a master warning system that it's not feeling "up to snuff" - and the alert that's forthcoming is always/usually preflight (only) or if inflight, too abstract for direct intervention. It needs time-consuming troubleshooting to some extent. That's where an "in your face" alerts system could step in to fill that conceptual breach. There's nothing like clarity in failure - to point the way forward. An FAQ reference is just not an option once that 4th dimension (time) is in play.

The evident need is always to minimize trouble-shooting. Just saying "aviate, navigate, communicate" is no salve for system self-expression in automation. Automation to date has been designed to alleviate the normal workload. Its next generation and obvious development challenge is to relieve the abnormal workload.

Rather than just "blacking out", it would (IMHO) be infinitely better for a suddenly unreliable instrument or screen to either:
a. show on its face a clear exposition of its failure status (or of faulty input data being out of limits).. or...
b. simply show vertical or horizontal raster (think of the older analogue screens with a faulty vertical hold) - i.e. its "out of action" status.
Just flickering or failing to zero or displaying a false reading or even an unobvious non-annunciating OFF flag is wholly unacceptable - but that's exactly where we are "at" now.

Some failures just lead to a querulous FAQ of WTF (aka: "what's it doing now?"). Some indicators (such as airspeed tape displays instead of round gauges) are just not attention-getting enough.

Digital has always been an infinite resource for safer flight. Its exploitation needs to now include some deeper systemic introspection and a non-misleading advisory capacity. Silently changing flight modes is an insidious deception. Low-side stall warning re-triggers on an attempted exit from a deep-stall condition? There's nothing simplex about that. It's a duplicitous behaviour..... and one that befuddles any human thought process.

Developments in avionics systems now needs to concentrate upon
the human interface. A last-ditch fallback to manual flight is necessary. But it seems to be more akin to falling backwards into a cold pool of uncertainty surrounded by undefined but obviously present further failure-threats. A clean-break reversion to a manual flight mode whose parameters and limits are familiar? That's the way to go.

[john_tullamarine]

I think that your generalisation regarding F/Os is unreasonable but very important in the context of this series of threads.

An half competent, reasonably experienced, F/O ought to be quite capable of addressing any abnormality in the absence of the commander .. else he/she is going to experience great grief during upgrade training.

I am reminded of an old story about a DC3 droning its way from the mainland to Tassie .. or perhaps, vice-versa .. the tale was related to me many years ago..

The legendary Jason H, as normal ops would dictate, was soundly asleep whilst my mate Baz was minding the shop. As luck would happen one noise source ceased making its din and Baz proceeded to do that which was required. Jas woke up due to the change in noise, observed that all was well and under control ... commented "carry on" ... and returned, forthwith, to the land of nod.

Baz recovered the aircraft in the usual manner and life proceeded.

However, there is the underlying presumption that an F/O must be competent and capable ... some of us are wondering whether that tenet was lost somewhere in the transition to automatics upon automatics ?

[RR_NDB]

Hi,

UNCTUOUS:

... - to "in your face" alert the crew of an imminent GIGO fiasco (GIGO = garbage in/ Garbage out) (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-20.html#post7414609)



You need a licenced decision-maker on scene. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-20.html#post7414609)

Capable to understand precisely and fast what´s going on. What requires a lot of multidisciplinary knowledge. Training is enough?

- particularly when the failure is epicentric and tentacular. The omnibus checklist series that covers all contingencies is yet to be written.




:ok:

Statistically, a perplexed crew is around 50% unlikely to come up with a workable solution when suddenly faced with "the unstraightforward".

So, SURPRISES to the crew must be reduced to a minimum. Why not to ALERT CREW IMMEDIATELY when the System will face UAS? This is particularly important because there are risks of GIGO.

The evident need is always to minimize trouble-shooting...Automation to date has been designed to alleviate the normal workload. Its next generation and obvious development challenge is to relieve the abnormal workload.

Congratulations! I was concerned with all this when started this Thread:

Man-machine interface and anomalies
The increasing technological sophistication in FBW planes brings benefits and challenges to the pilots and other 'players". The objective here is to discuss the "interface" and it´s components, specially when facing anomalies.
(http://www.pprune.org/tech-log/481350-man-machine-interface-anomalies.html#post7109348)

Rather than just "blacking out", it would (IMHO) be infinitely better for a suddenly unreliable instrument or screen to either:
a. show on its face a clear exposition of its failure status (or of faulty input data being out of limits).. or...
b. simply show vertical or horizontal raster (think of the older analogue screens with a faulty vertical hold) - i.e. its "out of action" status.
Just flickering or failing to zero or displaying a false reading or even an unobvious non-annunciating OFF flag is wholly unacceptable - but that's exactly where we are "at" now.

:ok:

Its exploitation needs to now include some deeper systemic introspection and a non-misleading advisory capacity.

:ok: (Bold mine)

Developments in avionics systems now needs to concentrate upon
the human interface.

R&D, a complex one, is required.

That's the way to go.

I agree completely!

Thanks for excellent post!

[TTex600]

The evident need is always to minimize trouble-shooting. Just saying "aviate, navigate, communicate" is no salve for system self-expression in automation. Automation to date has been designed to alleviate the normal workload. Its next generation and obvious development challenge is to relieve the abnormal workload.



Dam#%# , I wish I'd written that. EXCELLENT, EXCELLENT point Sir!

The best I ever came up with is that the bus helps me doing things that I can do well already, but is of little use when things go wrong.

Excellent post.

[Lyman]

"The best I ever came up with is that the bus helps me doing things that I can do well already, but is of little use when things go wrong."

My point from the outset. A genIII autopilot. Nothing wrong with that, if everybody, including the pilots, is totally conversant with the way it uncouples. And the ways it behaves in 'uncoupled' flight.

From the length of the thread, and the number of posts from those who fly it, and those who designed it, and their disagreements to this day,

Not so much.

[gums]

great attitude, Tex

The best I ever came up with is that the bus helps me doing things that I can do well already, but is of little use when things go wrong.

Make no mistake, folks here, we single-seaters used the A/P, but we used it to reduce workload and not sit there and "monitor". So I flew almost 2,000 hours in a jets without an A/P, and another 1,500 with a nice A/P, and maybe another 600 with really good A/P features ( mach hold, coupled ILS approaches, even turns directed by GCI to find a target). The big thing was I never used the sucker as a routine way of doing business except on long flights and at constant altitude/heading. Gotta tellya that in crappy weather, and diverting to another field, that the A/P allowed us to find the new approach plate, change IFF, coordinate with wingman, etc. Still had to "monitor", but we didn't have all the cosmic FMS that helps ( but still turns the wrong way as in the Cali accident).

As Tex has opined, the sucker is great for normal ops, but sucks when things go awry. Hell, my Shuttle buddies used the A/P until hitting the heading alignment circle. First 15 or so minutes was 'cause the A/P was faster than them and followed the prescribed trajectory more accurately. I can understand that. But I will guarantee those guys could have followed a good flight director all the way down.

Only HAL help we had in the Viper was when AoA got above 29 or 30 degrees, and then it helped with directional control to keep us outta a spin. Unfortunately, our cee gee was so far aft that all that resulted was settling into the classic "deep stall", heh heh.

Guess it's just a frame of mind for many of us here, but I have grave feelings about simply becoming a "monitor" versus being a "pilot".

[CONF iture]

To expand on that one (http://www.pprune.org/7377012-post93.html) according to the A330 FCOM it is possible to trigger DIR LAW through a TRIPLE PRIM FAIL which allows BOTH SEC still in operation.

[TTex600]

DIR LAW
To expand on that one according to the A330 FCOM it is possible to trigger DIR LAW through a TRIPLE PRIM FAIL which allows BOTH SEC still in operation.



The question is then, what will the aircraft control response be with only spoilers for roll control? Or do the SEC's give aileron control in the 330? I confess, I've gotten lazy and haven't looked up the answer.

My original point was this, it's dam#$%^$ near impossible for a sim instructor to configure a sim in a way to force direct law without also removing control surfaces from the pilots usage. And therefore it's quite difficult for a pilot to experience true direct law in the training environment.

[OK465]

Or do the SEC's give aileron control in the 330?

Yes.

(With only 1 SEC you retain same aileron control as with 2 SEC's when flaps are up, but when flaps are down you lose one outboard aileron with only 1 SEC)

I've gotten lazy and haven't looked up the answer

Real question is, 'where would you find it?'.

[PJ2]

OK465;
Real question is, 'where would you find it?'.
QRH, Ch.5, "Flight Control Architecture".



http://www.smugmug.com/photos/i-QjmbNFp/0/X2/i-QjmbNFp-X2.jpg

[DozyWannabe]

This speculation seems to still be the most plausible
In fact it is supported by the fact that the pilot continues pulling on the stick despite the stall alarm and the remarks of the PNF

I'm not so sure. There are other explanations, chief among which is the known tendency for pilots to pull back when startled by a warning (including a stall warning) - this was written up in the BEA report on the Orly A300 incident.

Added to this, both F/Os are on the CVR shortly before the start of the accident sequence discussing the fact that they're about as high as they can safely go for the conditions - as such, it's fairly unlikely that the PF would have consciously been pulling up - my personal opinon for all it's worth is that it was an unintentional control input initiated by the startle factor. If the PF believed that the protections would allow them to pitch up and climb safely then the whole conversation about altitude was moot.

What I find disturbing is that the system takes the decision to disconnect the AP and switch to ALT LAW based on its analysis of the ADRs outputs but does not think as necessary to keep the crew informed about the reason it took that very decision ?

The big red X on the speed tape and the disappearance of the Vx indicators should have been a significant clue, no?

I was under the impression that troubleshooting via ECAM was intended for when the aircraft is stable rather than during an attempt to regain control. It's also possible that IAS DISAGREE/ADR FAULT was bumped off the ECAM when the ADR DISAGREE appeared, as OK465 attests to.

The ACARS timings are very vague - the final report contains more accurate timings which I'd imagine came from the DFDR.

[AlphaZuluRomeo]

The big thing was I never used the sucker as a routine way of doing business except on long flights and at constant altitude/heading.
Beg your pardon, but that could be a relatively good description of the airliner/transport pilot job, when comparing it to the fighter pilot job...:E

Now... hat, coat... ;)

[DozyWannabe]

... a term like nugget is demeaning, and serves in the long run to cement a conclusion that may not be accurate, that the PF was some kind of flustered 'rookie'.

Not necessarily - remember that even the most competent and experienced pilots have made grave mistakes while under duress.

When abstract and abstruse technology runs amok, it needs to be immediately apparent to a flight crew that anything (or everything?) in technoville is becoming unstuck.... or even just on its way out. Fortunately there is (prospectively) a digital way to do that - to "in your face" alert the crew of an imminent GIGO fiasco (GIGO = garbage in/ Garbage out). But more on that in a moment.....

So, SURPRISES to the crew must be reduced to a minimum. Why not to ALERT CREW IMMEDIATELY when the System will face UAS? This is particularly important because there are risks of GIGO.

Because it's one of the most difficult situations to reliably work out - as has been stated previously. The fact that the CVR transcript has the PNF reporting no speeds at 02:10:15, despite the NAV ADR DISAGREE message not appearing until past 02:12 implies that at least half the crew on the flight deck were well aware what the problem was. This flatly contradicts any assertion that the systems were not providing the relevant information to the crew.

On a basic level, perhaps a more critical look at the parameters of autopilot in Turbulence?

How many times can one person say "The turbulence was not sufficient to cause AP disconnect" before you believe them?

[jcjeant]

If the PF believed that the protections would allow them to pitch up and climb safely then the whole conversation about altitude was moot.The conversation about the altitude does not prevent the pilot think he can easily take more altitude .. if it has the protections active ..
If a problem occur (too much altitude) .. protections will act
Why not try ...
Those 4 minutes (yes .. they were startled for 4 minutes ..a long time for experienced pilots .. no ? ) were just ...the game " trying anything and we will see " ...
They just not try one thing ... push .. push forward the stick ....
Again .. the "surprise" effect ... ?

[CONF iture]

My original point was this, it's dam#$%^$ near impossible for a sim instructor to configure a sim in a way to force direct law without also removing control surfaces from the pilots usage. And therefore it's quite difficult for a pilot to experience true direct law in the training environment.
Q. Would it be possible to program a F/CTL IR DISAGREE which should activate DIR LAW and possibly still retain all flight control surfaces ... ?

[DozyWannabe]

The conversation about the altitude does not prevent the pilot think he can easily take more altitude .. if it has the protections active ..

Then why say that they shouldn't go any higher prior to the problem if he believes the protections will keep them out of trouble?

Those 4 minutes (yes .. they were startled for 4 minutes .. long time .. no ? ) were just ...the game " trying anything and we will see " ...

The zoom climb followed by an ever increasing descent should have been a clue that the protections weren't helping them - at no point until it is too late is the loss of altitude remarked on by the PF. If he was expecting protection, then why did he not remark on the altitude and why did he not remark on the Stall Warning (which should never sound when protections are active)?

They just not try one thing ... push .. push forward the stick ....
Again .. the "surprise" effect ... ?

It would be unfair to speculate as far as I'm concerned. We do have at least three previous incidents (Stony Creek 727, West Caribbean MD-80 and Birgenair 757) where a stall at altitude led to the pilot in command pulling back all the way to the ground - none of those aircraft had protections.

[CONF iture]

The big red X on the speed tape
Is it again something of your own making ?

and the disappearance of the Vx indicators should have been a significant clue, no?
No - The disappearance of some characteristic speeds is NOT a positive signal of UAS.

It's also possible that IAS DISAGREE/ADR FAULT was bumped off the ECAM when the ADR DISAGREE appeared, as OK465 attests to.

No - First a IAS DISAGREE ECAM MSG does not exist and second such message or its equivalence would have been part of the FDR if it had appeared even momentarily.
Also, it is not what OK465 was attesting (http://www.pprune.org/7413955-post386.html).

The ACARS timings are very vague - the final report contains more accurate timings which I'd imagine came from the DFDR.
Forget about the ACARS timings then ...

[CONF iture]

The fact that the CVR transcript has the PNF reporting no speeds at 02:10:15, despite the NAV ADR DISAGREE message not appearing until past 02:12 implies that at least half the crew on the flight deck were well aware what the problem was.
Absolutely not conclusive (http://www.pprune.org/7409086-post361.html).

This flatly contradicts any assertion that the systems were not providing the relevant information to the crew.
This flatly contradicts nothing.

[DozyWannabe]

Is it again something of your own making ?

Actually it came from Hunter58 earlier in the thread:

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

No - The disappearance of some characteristic speeds is NOT a positive signal of UAS.

It doesn't necessarily need to be UAS specifically in order to stabilise the aircraft and then try to troubleshoot.

No - First a IAS DISAGREE ECAM MSG does not exist and second such message or its equivalence would have been part of the FDR if it had appeared even momentarily.

OK - "IAS DISCREPANCY" then - talk about nitpicking! And has it occurred to you that it may well have been on the DFDR but was not considered relevant given that the PNF reported speeds being unavailable already?

The PNF's reference to losing the speeds is at approx. 02:10:15.

If the guys knew, why the PNF would have said :
Fais attention à ta vitesse - Fais attention à ta vitesse

I'm not sure - the DFDR indicates that ground speed was available (and slowing) during that period - approx 02:10:27 (and airspeed returned at approx. 02:10:33). Perhaps he was referring to that?

I just don't see how an argument that the crew were unaware of an air data/speed problem until the ECAM displayed NAV ADR DISAGREE at 02:12:44 can stand up in the face of a clear reference to speed being unavailable at 02:10:15.

Fundamentally I have no problem with a hypothesis whereby there was a technical issue that misled the crew - however if you want that hypothesis taken seriously then you must work forward from the evidence at hand to support your hypothesis. Throwing mud in the form of unsupported assertions because you've already decided that the aircraft and its design must be at fault is unlikely to convince anyone other than those who already share your views.

[HazelNuts39]

Several questions regarding the NAV ADR DISAGREE message have been lingering in my mind. The ACARS message was time-stamped 0212 and it was received by the ground station at 02:12:51. The 3rd interim report lets it appear on the ECAM at 02:12:XX and the final report at 02:12:44. What new information permitted the more precise timing?

What caused the message at this point in time? The Air Caraibes memo states the thresholds for rejection of the first ADR as: Altitude 3000 ft during 1 second, Mach 0.05 / 10 s, CAS 16 kt / 10 s, TAS 16 kt / 10 s, AoA 3.6° / 1 s, total pressure 20 hPa / 10 s, static pressure 5 hPa / 1 s. The thresholds for rejection of the two remaining ADRs are the same except that the time is always 1 second.

Then the ECAM message (final report, page 99):

NAV ADR DISAGREE
- AIR SPD ...... X CHECK
- IF NO SPD DISAGREE
-AOA DISCREPANCY
- IF SPD DISAGREE
-ADR CHECK PROC ... APPLY

Isn't it odd that the system asks the crew to find out what caused the system to generate that message? If there is NO SPD DISAGREE, the crew is to suspect AOA DISCREPANCY?

[BOAC]

I know this will go 'against the grain' for all those 'affectionados' of total computer control etc, but if my idea of a spring-loaded boxing glove in the panel is discarded, what is really need is a soft, HAL-like message:

"Dave - I'm sorry - I really don't know what is happening here. Would you mind being a pilot for a short time?"

As long as we have 'pilots' at the controls we will then be ok.

[jcjeant]

I know this will go 'against the grain' for all those 'affectionados' of total computer control etc, but if my idea of a spring-loaded boxing glove in the panel is discarded, what is really need is a soft, HAL-like message:

"Dave - I'm sorry - I really don't know what is happening here. Would you mind being a pilot for a short time?"

As long as we have 'pilots' at the controls we will then be ok.This equation has two data ...
One is a constant
"Dave - I'm sorry" :)
The other is a variable
"As long" :uhoh:
Not so sure that the result will always be good :sad:

[Lyman]

Hazelnuts39

The computer is trying to determine if the ADR disagree is induced by NAV (sic) Maneuvering? Eg slip/skid, asymmetric, etc.

[CONF iture]

Throwing mud in the form of unsupported assertions because you've already decided that the aircraft and its design must be at fault is unlikely to convince anyone other than those who already share your views.
Of course Dozy, why not blind fully pushing the idea of the big red X on speed tape or losing the speeds or speeds being unavailable or airspeed returned later ?
Hunter58 must be working for the BEA after all … no need to check.

Do you only make the difference between characteristic speeds and speed tapes ?

Unsupported assertions and mud … look in your own garden Dozy.

[DozyWannabe]

The computer is trying to determine if the ADR disagree is induced by NAV (sic) Maneuvering? Eg slip/skid, asymmetric, etc.

Not at all. The ECAM fault messages are contained in the "Navigation" category.

Chapter*10.*Navigation (http://www.hursts.eclipse.co.uk/airbus-nonnormal/html/ch10.html#adr-faults)

... all those 'affectionados' of total computer control etc

I've yet to see a single person on this thread who's advocating totally automated aircraft.

@CONF - coming from someone who's still convinced that Asseline's stuff-up was the fault of the aircraft I wouldn't be throwing stones. Hunter states something that contradicts your hypothesis, so you automatically assume he must be part of the conspiracy.

[RR_NDB]

Hi,

Because it's one of the most difficult situations to reliably work out - as has been stated previously. (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-21.html#post7421212)

This is feasible, should be done long time ago and the approach used by Airbus SAS showed in the earlier mentioned paper from the Design group is IMHO an ERROR.

To diagnose UAS just by "System output" is DANGEROUS and a good example of K.I.C.S. (*)

This flatly contradicts any assertion that the systems were not providing the relevant information to the crew.

The System provided a lot of information including processed garbage. What you need is just FAST and PRECISE information.

...at least half the crew on the flight deck were well aware what the problem was.


A good man-machine interface could provide to 100% of the crew (including Capt) reliable information.


(*) Keep It Complex Stupid

[OK465]

From page 98 of the final:

This correlation confirmed the preliminary analyses written up in the interim reports. Study of the transmission times between the computers that identified the triggering of the monitoring and the CMC also made it possible to explain and check the order in which the messages were sent by ACARS. This order may differ from the order of appearance of the ECAM messages.

From I#1 also:


message-timing by the CMC is accurate to within one minute, the order in which these messages are transmitted does not necessarily correspond to the associated sequence of events,


Beats me?

[DozyWannabe]

This is feasible, should be done long time ago and the approach used by Airbus SAS showed in the earlier mentioned paper from the Design group is IMHO an ERROR.

It was what could be achieved with the technology of the day,

To diagnose UAS just by "System output" is DANGEROUS and a good example of K.I.C.S. (*)

The System provided a lot of information including processed garbage.

Where do you see evidence of this? I must confess I can't. The idea that conflicting information was presented to the crew is in complete opposition to the recorded and proven reference to missing speed data by the PNF at 02:10:15.

A good man-machine interface could provide to 100% of the crew (including Capt) reliable information.

To be fair I'm not the only one who isn't sold on your magic DSP theory.#

Remember that when the Captain returned, the airspeed was back online, so he was facing a different set of problems than the initial situation confronting the F/Os.

For what it's worth I think that the initial UAS problem was quickly overtaken by the concern over the aircraft attitude caused by the PF's control inputs as far as the PNF and Captain were concerned.

[mm43]

- the order in which these messages are transmitted does not necessarily correspond to the associated sequence of events

I believe the transmit order from the CMC is prioritized, e.g.
F/CTRL
NAV
MAINTENANCE etc..

The ECAM and ACARS sequencing will both vary accordingly, and in the case of ACARS the shuffling shows up when a lot is going on.

[Lyman]

Whether or not the a/c was reporting it, we are only sure of the crew's cognizance at 2:10:16. That is eleven seconds to be in the dark as to what is wrong.

Loss of Autopilot does NOT mean fly "PITCH AND POWER". It means fly...

You continue to studiedly ignore what RR and myself, among others, have pointed out, that the a/c was not clearly indicating that UAS was the problem, and that the computers did not necessarily include the crew from the outset of suspected duff speeds.

The reference is to what the a/c displayed, RESULTS of bad data.

Question. If the a/c had ceased displaying IAS from the outset of suspected bad speeds, would not the pilots have had obvious cue of loss of Airspeed (literally)

Displaying any cue that is known to be false is counter to good design, if said cue can be left out.with impunity.

Why waste precious time in a situation that is easily remedied with Pitch and Power?

The fact that pilot started handling the a/c demonstrates his belief it needed handling, period, speeds or not.

[Hunter58]

CONFiture, i lived in that particular country for five and a half years, and I am more than happy for every day I left it. However, that will not blend over the fact that once the HALs decide they have insufficient info he shows you what he does not understand anymore.

OTOH, Air France by now managed to be the first to wreck any Airbus since the A320, typically by not following procedures. You seem to be French, you should not be suprisd by such culture...

Oh, any anyone who believes Airbus is French has not lived there.

[DozyWannabe]

Whether or not the a/c was reporting it, we are only sure of the crew's cognizance at 2:10:16. That is eleven seconds to be in the dark as to what is wrong.

Loss of Autopilot does NOT mean fly "PITCH AND POWER". It means fly...

It also means "don't pull up". The correct response was to observe and then correct as necessary.

You continue to studiedly ignore what RR and myself, among others, have pointed out, that the a/c was not clearly indicating that UAS was the problem, and that the computers did not necessarily include the crew from the outset of suspected duff speeds.

Even with RR_NDB's DSP algorithm, it would take time to work it out. Whether the system reported UAS or not is not the issue, the issue is and has always been the tendency to pull up when startled

The reference is to what the a/c displayed, RESULTS of bad data.

The PNF had a handle on things at approx 02:10:15 though - as I've said before this flatly contradicts the idea that the aircraft was providing confusing information. I don't believe the PF pulled up because he believed in the protections, nor because he was unaware that UAS was the problem - he did it because he freaked out under pressure.

Question. If the a/c had ceased displaying IAS from the outset of suspected bad speeds, would not the pilots have had obvious cue of loss of Airspeed (literally)

An instant appraisal cannot be done - even RR_NDB's hypothesis would still take a few seconds in order to work reliably. There's nothing to indicate that the PF's pitch inputs were an attempt to regulate airspeed - except for the response to the PNF's "Watch your speed" comment, which could have been taken from groundspeed. At that point, the PF actually briefly put the nose down, but then pulled it up again within a few seconds.

Displaying any cue that is known to be false is counter to good design, if said cue can be left out.with impunity.

Detecting UAS is difficult, and the Airbus system is more conservative than most, disconnecting AP at the onset of the potential problem. Compare this to the Birgenair B757 where the autopilot continued to try to fly on the bad data.

Why waste precious time in a situation that is easily remedied with Pitch and Power?

In this case, it looks like the startle effect took precedence.

The fact that pilot started handling the a/c demonstrates his belief it needed handling, period, speeds or not.

But it doesn't mean his belief was correct. The right thing to do was to monitor the aircraft's attitude and correct *only if* the attitude started to creep towards abnormal.

[OK465]

The ECAM and ACARS sequencing will both vary accordingly, and in the case of ACARS the shuffling shows up when a lot is going on.

Exactly...and is that 2:12:44 time for ADR DISAGREE an ACARS downlink time, or an ECAM appearance time?

[jcjeant]

he did it because he freaked out under pressureIn this case, it looks like the startle effect took precedenceUnder what pressure .. that of the the panic?
Panic because the autopilot disengages at cruising altitude?
If this is the case .. it says a lot about the criteria for selection of pilots and particularly on the selection made by AF
BTW it's not only on Air France !
DdoyDNfsaSs

:ok:

[DozyWannabe]

Disagree - even top-drawer pilots mess up when taken out of their comfort zone.

[infrequentflyer789]

Loss of Autopilot does NOT mean fly "PITCH AND POWER". It means fly...
[...]
The fact that pilot started handling the a/c demonstrates his belief it needed handling, period, speeds or not.

Exactly - and "fly" is what they did not do. The question is why.

If we assume that incompetence (never trained how to fly the plane) and negligence (knew now to but failed to) are out, then something caused PF to seek 10-15 degrees pitch up. Your (and RR and others) premise is that lack of precise indication of UAS from the outset is causative, right ?

So... perhaps you could humour this non-pilot and fill in the blanks, because I still don't understand how you get from:

- A/P has gone off, I have control
- Plane needs handling
- Plane hasn't told my WHY A/P dropped out

to...

- I need to pull up 10 degrees in cruise (even though that would normally be a crazy thing to do)


The only thing I can think of is airspeed indicated erroneously high (very high) - but that didn't happen, it went erroneously low.

So, what was it ? What piece of garbage information presented to the crew could have lead to that response ?

[jcjeant]

comfort zone:confused:

Autopilot is now the comfort zone of pilots :confused: ... :uhoh:

infrequentflyer789
If we assume that incompetence (never trained how to fly the plane) and negligence (knew now to but failed to) are outHow you can assume this is out ? .. on what basis ?
Remember ... Bonin ask (or dunno) what is St Elmo fire ... :E
Even a uneducated poor fisherman know what is St Elmo fire .....

[Lyman]

infrequentflyer789

Hello. "And fly is what they did not do..."

The autopilot was actively maneuvering until it quit, at handoff the a/c was rolling 4 degrees per second to the right, the nose was low, and they had exited moderate turbulence in conditions that I submit were more of a challenge than they were acknowledging, at least to each other, if not to themselves. If Bonin had not arrested roll, they would have been banked fourty five degrees when Robert said "So, we've lost the speeds..." eleven seconds later. In the eleven seconds I submit Bonin was unaware of UAS, his Pitch was not "full back" in fact it included several ND excursions.

Much has been made of "Do nothing". Not possible, given the conditions. Once Bonin got responses in Pitch (Was it sluggish? "Beware unusual control responses") he could easily have lost his sense of attitude. He was always the one flying, and his Panel was not recorded. What did he see and what was he using for references for his inputs? I don't know. At one point, PNF "Put him in ATT/HDG."?

Had he been using IAS? For the longest time I have defended this pilot, and I will not stop, though I do have to admit some strange examples of "pilotage" have shown up in other accidents (Colgan) (Schiphol) (Caraibes) and incidents.

Without a complete disclosure of the CVR it is impossible to know exactly what happened in the initial 20 seconds, the phase when the die was cast. I think that is deplorable...

My recent post addressed the fact that erroneous Airspeed was displayed. I consider that unfortunate, yet Dozy says it is unavoidable.

If IAS can be lost temporarily without risk, dump it until it can be verified. Given the state of the industry and the apparent lack of readiness to fly manual at altitude, nothing should be left to chance.

[mm43]

...and is that 2:12:44 time for ADR DISAGREE an ACARS downlink time, or an ECAM appearance time? It is the ECAM appearance time of NAV ADR DISAGREE, and the ACARS received time was 2:12:51. Allowing 4 secs for the up/downlink, that would give 3 secs processing between CMC and ACARS. The previous message via ACARS was received at 2:12:16, which indicates the ACARS system was probably clear.

[OK465]

This order may differ from the order of appearance of the ECAM messages.

Which out of sequence message(s) do you think the report is referring to, if any at all?

[Lonewolf_50]

Dozy, talkin out your backside again, are ye?
Disagree - even top-drawer pilots mess up when taken out of their comfort zone.
You make an overly broad assertion, which is far more accurately stated as:

Some high performing pilots (call them set A) make errors when taken out of their comfort zone.

Others don't. Why? They adapt to unexpected changes in their environment better than the set A pilots do. Why? No short answer. If you could bottle it, you'd make your fortune many times over.

Have seen this through personal observation over and over again.

[Lyman]

Temp Temper Temperament. Better to bottle "cool under Pressure".

It is in the Amygdala.

[CONF iture]

@CONF - coming from someone who's still convinced that Asseline's stuff-up was the fault of the aircraft I wouldn't be throwing stones. Hunter states something that contradicts your hypothesis, so you automatically assume he must be part of the conspiracy.
As usual, when out of argument, you're back to Habsheim with a deformed analysis which is supposed to be mine.
Educate yourself on my view once for all - It's here (http://www.pprune.org/7150688-post133.html).

Hunter58, as the instigator of the Big red X over the speed scale early in the sequence at AP disconnect, here (http://www.pprune.org/7408184-post345.html) and here (http://www.pprune.org/7408819-post355.html), would you give a hand to Dozy who put his trust in you to locate such reference in the BEA reports ?

[Linktrained]

I cannot know whether this was the case :
IF PF had seldom ( if ever) manually flown an A330 - except premeditatedly for a very few minutes after T/O and again, just prior to Landing, both of these at low level, it would be natural for him to be startled.
The Drill for UAS (then) empathised Terrain clearance.

On earlier, less sophisticated aircraft, I soon learned to hand fly through Cbs, IFR and at night, before radar was available. St. Elmo's Fire and lightening strikes occurred. And my knees got wet because the windscreen leaked until a blanket was made available ! I logged my first 250 hours of hand flying, sometimes doing a couple of 3 hours sessions in a day, alternating with the Captain. ( My quality did deteriorate - but there were no flight time limitations, then.)

[Hunter58]

CONFiture

The BEA does not loose a single word on the representation of the speed tapes. If mentiones mesured speeds only, and focuses on the representation of the ECAM messages. There is no reference on whether there was a visual clue of the rejection of data via a cross (as it should be in that case) or not (which could be interpreted as erroneous data).

Obviously this factor was not worth a detailed description, which I believe is not a good call as there would be no discussion about it. However, since the speed values seem to have been rejected, this would have triggered the cross.



I am sure you can clarify this to our satisfaction, or would it trouble your picture of the supposedly corruptive power of a certain aircraft manufacturer too much? However, since you seem to at least have been in France once you should remember that such power would be extremely limited as every little local politician with ambitions would try to grab national attention by disclosing whatever information he has available. There are no secrets in 'La Grande Nation', the are simply too may elements ready to disclose them for their own short term publicitary benefit...

[Lonewolf_50]

Hunter, I inferred, perhaps incorrectly, that the pilot's remark "we have lost the speeds" was a response to an indication failure of his airspeed indicator, which I presume, also perhaps incorrectly, would be something like an "off flag" or "red X" or other marked change in presentation.

It may have seemed far too obvious a detail for the BEA to dwell on?

If I am off the mark here, please advise.

[CONF iture]

The BEA does not loose a single word on the representation of the speed tapes.
Maybe time for you and Dozy to pay another visit to the BEA report as there is a paragraph named Analysis of the airspeed displayed on the PFD’s and ISIS.
The SPD flag (There is no such thing as a big red X) which replaces the speed scale, was not displayed before 02:11:40

[bubbers44]

Personnaly I think Dozy is one of the smart guys in this group. I think he believes as I do that it doesn't matter what aircraft you fly, if the IAS goes away just fly attitude and power. That is what the autopilot was doing until it disconnected so why change anything. I don't care if Airbus says go to climb power and 5 degrees up in their situation, they didn't even do that, they pulled up to over 15 degrees for no reason and the PNF let him. Bad. Do we need the old timers to come back and teach them?

300 hr pilots flying on autopilot for a thousand hours are not real pilots. They cause crashes like this because they can not hand fly and trust automation to bail them out. When automation fails they are lost. AF proves it.

[TTex600]

Personnaly I think Dozy is one of the smart guys in this group. I think he believes as I do that it doesn't matter what aircraft you fly, if the IAS goes away just fly attitude and power. That is what the autopilot was doing until it disconnected so why change anything. I don't care if Airbus says go to climb power and 5 degrees up in their situation, they didn't even do that, they pulled up to over 15 degrees for no reason and the PNF let him. Bad. Do we need the old timers to come back and teach them?

If the autopilot didn't have adequate info to fly the airplane, what makes you think the pilot had any better?

It's easy to second guess from the rocking chair.

I would have second guessed from my MD80, but now I fly an Airbus and there but for the grace of God go I.

[bubbers44]

Any competent pilot could have hand flown just fine. Pitch and power until IAS comes back. Any pilot should be able to do that. Couldn't you?

[bubbers44]

TT, I assume you always fly on auto pilot, right? If it can't do it you can't.

[TTex600]

TT, I assume you always fly on auto pilot, right? If it can't do it you can't.

Maybe if I post it twice, you'll read it the second time. If the autopilot didn't have adequate info to fly the airplane, what makes you think the pilot had any better?

We're talking about the information needed to fly the airplane, specifically to fly the airplane at that exact moment, not about the ability to fly the airplane.

I think 99% of the pilots posting on/reading this string agree that all Bonin and Robert had to do to live was fly pitch and power. So you got that going for you. :ugh:
I also think that 99% of us want to understand why they didn't. We get it that you think they were incompetent, at least part of us would disagree. The accident pilots were all properly qualified and experienced. I for one, and trying to understand just how their qualification and experience failed them.

As to my abilities, I'll venture that you've got more time hand flying a 7n7 than I have total in an Airbus. I'll also venture that I've got 100% more time hand flying a flybywire narrowbody airbus than you. If it makes you feel any better, I'm sure you flew heading/alt/airspeed better than me. Now can we get back to chasing our tails to understand why 228 people died?

[PJ2]

TTex600;
"Now can we get back to chasing our tails to understand why 228 people died?"

:ok:

[Lyman]

Bubbers44

You fall back on the same tire phrase, yet I do not believe you fully understand what you are saying.

What you mean to say, i believe, is Fly SELECTED Pitch and power...

And ROLL. You make it sound like 447 was smokin along in still air, no turbulence. They were not familiar with "selected value/Pitch". Have you flown in turbulence? Wind shear?

Select a Pitch, and it is instantly incorrect, modify your demand, and that too becomes wrong, now you are further off flight path.

The autopilot was actively manouvering the aircraft when it stopped making control inputs, and the a/c was off flight path. Had Bonin been instantly sceptical of speeds, he may have considered why the a/p quit on him. Would he have input rote values for PP? Why? The plane was moving, and we are taught to control in certain ways in turbulence. If your heavy was rolling and Pitching and you lost the auto, would you select a Pitch, a BANK, and HOLD it?

How? More importantly, why?

[gums]

I must be missing something about the flight control laws and the A/P.

Seems to me that A/P disconnect should result in stick commands to the system and not keep the jet rolling or pitching up or.... using last commands from Otto. In other words, no stick input then zero roll rate command or change in Nz from the basic control laws. Almost an "attitude control" mode.

So some here have advocated " don't just do something, just sit there".

My own experience in our primitive FBW jet ( have to bow down to Doze-breath about our system, heh heh) was the sucker handled turbulence really well if you simply relaxed pressure on the stick. In fact, at low level and 500 knots over the thermals the sucker felt more like an Aardvark than the light jet it was. The computers smoothed out the ride like you would not believe.

So question is: does HAL keep commanding the last A/P inputs or not?

[RR_NDB]

Hi,

Question made:

Originally Posted by RR_NDB
So, SURPRISES to the crew must be reduced to a minimum. Why not to ALERT CREW IMMEDIATELY when the System will face UAS? This is particularly important because there are risks of GIGO.

DW:

Because it's one of the most difficult situations to reliably work out (http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-21.html#post7421212)

An early warning alerting the crew, BEFORE System degrades was feasible long time ago. We can implement it even without a DSP algorithm. Early warning is SIMPLE.

Your answer shows:

1) Your focus is only in an automatic System
2) It was not clear to you the approach i am defending on UAS

The idea is to immediately HELP the crew to diagnose it before chances of GIGO (http://en.wikipedia.org/wiki/Garbage_in,_garbage_out)


Garbage in, gospel out is a more recent expansion of the acronym. It is a sardonic comment on the tendency to put excessive trust in "computerized" data, and on the propensity for individuals to blindly accept what the computer says. Since the data goes through the computer, people tend to believe it:
Decision-makers increasingly face computer-generated information and analyses that could be collected and analyzed in no other way. Precisely for that reason, going behind that output is out of the question, even if one has good cause to be suspicious. In short, the computer analysis becomes the gospel. (http://en.wikipedia.org/wiki/Garbage_in,_garbage_out)

[PJ2]

Hello gums;

Re, "So question is: does HAL keep commanding the last A/P inputs or not?"

No, it doesn't. As you'd expect, AP orders stop the moment it disconnects.

However, flight control orders (C*), maintain the last pitch and bank attitudes until manual control input order a change. Roll is a roll-rate request until Alt2 Law and pitch remains a gee request until Direct Law. I know you know all this...just reviewing!

That means the controls on the wing and stabilizer are "busy" maintaining the last ordered attitudes...they're making tiny movements, but only for this reason. The AP has no input and neither does the stick so long as it is in the neutral position.

Should manual input be made, the controls will move according to such orders, while "on-the-fly" maintaining last ordered position. Once the orders stop, the airplane stays in that attitude.

I can't say whether a slight NU input is made to counter the slightly-increased gee at higher bank angles, (say, 20deg), but I know in Normal Law beyond about 33 degrees one has to pull a bit to maintain altitude in the turn.

So flying in turbulence, even moderate, is straightforward and is done with tiny stick movements because the airplane is already attempting to maintain last attitudes, in Normal Law and is doing so with exactly enough aileron and elevator. Maintaining bank isn't the case in Alt2 as we know and Roll Direct is sensitive but no big deal in terms of control. The airplane isn't about to roll over to 45deg+!...not unless the pilot does it and Bonin got the roll under control very quickly. It's a very stable airplane. It flies very well at cruise altitude under manual control.

By way of emphasizing this point, I've flown the airplane manually in turbulence a number of times (A320 as well), and really, it's not a big deal. One makes tiny inputs, just like the AP! Everybody out there on the wing is already doing their job trying to keep the last ordered attitude!

In Roll Direct (Alt2) that isn't happening but that doesn't mean the airplane is about to roll over! Tiny SS inputs again, and like I said Bonin got the hang of it really fast and had stopped the roll oscillations.

The question of Why the sustained pitch up?, may never be answered. For the record, in July 2009 (http://www.pprune.org/tech-log/376433-af447-200.html#post5093749) in a response to stepwilk I stated that the correct response was to "do nothing" and initially got some flack for saying so mainly because the phrase "do nothing" was misunderstood as really "doing nothing", when of course maintaining pitch and thrust was what I had meant! Anyway...

[DozyWannabe]

Personnaly I think Dozy is one of the smart guys in this group. I think he believes as I do that it doesn't matter what aircraft you fly, if the IAS goes away just fly attitude and power.

Thanks for the support - appreciated. And I do agree with that point and always have.


300 hr pilots flying on autopilot for a thousand hours are not real pilots.

I'm less inclined to agree with that. I'm sure some come out of the cadet programme with inadequate handflying skills and aeronautical knowledge, but I'm loath to tar a large group of people with the same brush without evidence.

It's already been mentioned numerous times that the least experienced F/O was a sailplane pilot in his spare time, so you'd expect a higher degree of aeronautical savvy than average on his part.

The point I've always tried to put across is that no matter how good you are, how many hours you've logged - handflying or otherwise - and how calm you usually are under pressure, there are times when you can have a bad day at the office regardless. Being that the flight crew aren't here to answer for what happened, I think it's fair to give them the benefit of the doubt there.

If the autopilot didn't have adequate info to fly the airplane, what makes you think the pilot had any better?

Because the pilot has the ability to solve problems dynamically in a way computers can't. It's always going to be harder at night, because you can't get a fix through the windscreen, but during the day it should be a relatively simple matter of comparing the attitude on the instruments with what can be seen outside. Sadly, the AF447 crew didn't have that option, but judging by the report, the instruments were functioning correctly through the majority of the accident sequence.

I would have second guessed from my MD80, but now I fly an Airbus and there but for the grace of God go I.

If you think the MD-80 can't throw a crew into disarray, think again:

West Caribbean Airways Flight 708 - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/West_Caribbean_Airways_Flight_708)

With the anti-ice system on, the highest altitude at which the overloaded aircraft could fly - without stalling - was reduced to only 31,900 feet. The captain noticed the reduction in engine power, but he couldn't realize the source of the problem. Therefore, he started a rapid descent, as a precaution. At that time, the airspeed was already near stall speed and the autopilot had kept a nose-up attitude to maintain a constant height. When the airliner was pummeled by a sudden updraft, it finally entered a stall condition and the crew mishandled it. Confused by the unusual behaviour of the engines, due to the anti-ice system and probably the air flow disruption caused by the updraft, the captain thought he was struggling with an engine flameout and did not recognise the deep stall situation.

[TTex600]

Because the pilot has the ability to solve problems dynamically in a way computers can't. It's always going to be harder at night, because you can't get a fix through the windscreen, but during the day it should be a relatively simple matter of comparing the attitude on the instruments with what can be seen outside. Sadly, the AF447 crew didn't have that option, but judging by the report, the instruments were functioning correctly through the majority of the accident sequence.

There was no problem to solve. The automation knew it had a bad input and decided it could no longer fly the airplane. Why not tell the pilot which input was bad? Announcing an ADR problem is not adequate.

Somebody recently said that the A/S indicators were covered with a red X. My A320 manual states that the A/S scale will be replaced with SPD

Interim 1 reads (to me) that we don't know if the FO A/S scale indicated SPD or was a normal looking tape. I'm sure someone who has all thousands of pages of reports memorized will know, but from what I can see the airplane never gave a clear signal indicating that speed inputs were suspect. I still hold that the aircraft knew that UAS caused the A/P to disconnect, it just didn't tell the pilots that little fact. The final report avoids the question by graphing CAS, not IAS. If I read these report correctly, the A/S indications were wildly fluctuating but they did not ever show SPD

The die was cast in those initial few seconds, and the airplane wasn't showing all available info during that time. It was however, chiming, clicking, honking, flashing, etc. EVERYTHING was demanding attention EXCEPT the important thing. That important THING was curiously silent and invisible. Go figure.

[TTex600]

If you think the MD-80 can't throw a crew into disarray, think again:


There you go again.

I never said that a Diesel9 can't throw a crew into disarray. I was using the Diesel9 as an example of a raw data airplane that I've flown. I made the point that I too might well have second guessed the AF447 crew if I only had raw data/analog experience; but now that I have Airbus experience I won't second guess. I assumed that pilots would understand the comparison.

That's nothing more than a little glimpse of who I am. Would you like for me to start analyzing you? Maybe we can switch places and I can mis-characterize your positions for a while. That might be fun. Lucky for you, and Tullamarine, I'm heading off into vacation. Enjoy.

[TTex600]

QRH, Ch.5, "Flight Control Architecture".

Thanks. On the 320, the SEC's don't have any aileron input, that's my experience. I didn't mean to muddy the water. (I did look it up :-) )

[gums]

Yeah, PJ, like I thought.

The one thing I question is loss of roll rate command in Alt 2. Looked to me that as we go thru the reversion sequences we lose bank angle limits and you have to add some back stick as bank angle gets to maybe 20 or 30 degrees.

I keep seeing "attitude" versus rates - Nz and roll rate. True that the jet may seem to "lock" on an attitude except in "direct", but that's what we saw in the Viper except for the pitch attitude correction to the Nz. The basic laws are still Nz and roll rate until in "direct", right?

I would dearly love to get some of the 'bus drivers up in my trusty Viper to show them how our system worked and "limited" you ( hate that word "protection", heh heh). Very small pressures required unless hassling in a dogfight. Our pitch gradient was about 4 pounds per gee and all pressure, not stick movement even after they increased the throw to 1/8 of an inch. The roll command had a limit I was not aware of until my LEF folded up. So HAL was commanding zero roll rate, but turned out I had another pound and a half of pressure left to keep the wings level. Gotta admit it was disconcerting. I also kept the speed up, as previous dude crashed and burned while getting slow during his "flare" for landing. He ran outta air molecules to help roll, and I prolly got ten knows slower than I should have, but my HUD tape shows that it looked pretty good to me.

The second thing I would demonstrate would be the AoA limiter. Pull as hard as you wanted, but even on STBY GAINS when air data went FUBAR, we still had that working for us. By the time we got to 27 degrees AoA we were at 1 gee and could pull as hard as you wished, but that was where you were gonna be.

The biggest difference between the 'bus pitch and ours was the correction for pitch attitude. So the 'bus actually reduces the Nz command, but ours kept striving for whatever gee we had trimmed for, normally one gee. Hence, at extreme pitch the one gee command kept raising the nose and we could fly into the "deep stall" with a neutral stick.

[DozyWannabe]

@TTex600:

I totally follow what you're saying - however, the idea that the systems weren't relaying useful information (in that it could be processed by the flight crew) simply does not square up with the PNF saying "We've lost the speeds" at approximately 02:10:15 on the CVR - at least to my mind.

And I'm not trying to analyse you or anyone else. The fact is that every airliner from at least the '60s onwards has had some form of electro-mechanical device between the raw data and what gets displayed on the instruments - whether that device is as simple as a three-way switch or a more complex setup, such as a digital voting mechanism.

No matter how old-school or modern the system, the onus is on the crew to work around the problem and try to overcome it. The gradual shift from steam-gauge to digital technology has altered the nature of the problems to be solved - that much is certain. Also certain is the fact that the accident rate has consistently come down since the introduction of the new technology. What is less certain is how to approach the new problems that raised their head in that time.

I don't think any of us will get a satisfactory answer as to why the PF pulled up. Because his display was not recorded and because he did not survive we will never know conclusively. From my point of view, even if the pull-up input was triggered by something he saw, far more important to me is why the PNF did not feel he had the authority to command the PF to hand over control while he was waiting for the Captain, and to a lesser extent, why the Captain did not delineate the parameters that would have given the PNF the confidence to do so when he went for his rest period.

[Lyman]

"I totally follow what you're saying - however, the idea that the systems weren't relaying useful information (in that it could be processed by the flight crew) simply does not square up with the PNF saying "We've lost the speeds" at approximately 02:10:15 on the CVR - at least to my mind."

Wrong, it was 2:10:16. For eleven seconds the PF may have been following duff data. Your statement is nonsense, unless you ignore the possibility that eleven seconds means nothing, which you would do....



PJ2 you say the a/c would not keep rolling after ap loss, but I think you mean in the context of Normal Law. In Roll Direct, it would keep rolling, NO?

You mention the PF quickly controlled Roll, so I assume you mean his input was appropriate.

The Nose Was Low. We know it was trending UP, but he may not have been cognizant of that, hence the Pull.

It is probably noticeable that I am trying to establish that the PF may have started his manual handling with inputs that while demonstrably inappropriate, might have seemed correct given the conditions.

It is also possible that PF believed the Flight Law was NORMAL LAW. Since this would explain perhaps his apparent ham fisted inputs, I go with that conclusion, for purposes of discussion.

It has always been a challenge to separate conclusions from their bias, and their consequent growth into 'fact'.

I readily admit to looking at everything, however I do not represent that they are conclusions, especially as they are absent from BEA reportage. BEA suggests ICE, the thread assumes Fact. The pilots seem somewhat incompetent, that becomes fact, and subject to constant repetition.

My assumption is that this accident became almost instantly un recoverable, due to many factors. The proper discussion involves a look at everything, even if it is somewhat exculpatory, imho.

[DozyWannabe]

Wrong, it was 2:10:16. For eleven seconds the PF may have been following duff data. Your statement is nonsense, unless you ignore the possibility that eleven seconds means nothing, which you would do....

It was 02:10:15.9. How you read that depends on whether you're working in decimal places or significant figures. PF calls for control at 02:10:06.4, meaning that it's more like 10.5 seconds.

We know that the CAS was actually indicating *low* speed rather than high, so increasing pitch angle does not tally with what may have been displayed on the speed tape. We know that it's likely that the erroneous drop in altitude might have led to a pitch up command, but not of that magnitude and not for that length of time.

PJ2 you say the a/c would not keep rolling after ap loss, but I think you mean in the context of Normal Law. In Roll Direct, it would keep rolling, NO?

No. The flight surfaces would return to neutral, and the aircraft would passively attempt to hold bank angle in the same way as a traditional airliner. It won't actively try to hold a lateral flightpath.

It has always been a challenge to separate conclusions from their bias, and their consequent growth into 'fact'.

With all due respect, that's pretty rich coming from someone who's thrown accusations of broken vertical stabs, snapped jackscrews and stuck autopilots at the aircraft without a single bit of supporting evidence!

(I know my position is largely theoretical too - but at least the phenomena of pulling up due to startle effect, confirmation bias and flight deck command gradient are known and have been studied!)

The pilots seem somewhat incompetent, that becomes fact, and subject to constant repetition.

That's how you're choosing to read it. The crew made mistakes in terms of handling and CRM, certainly. But that's a long way from claiming they were generally incompetent.

[Lyman]

You have never wanted to accept my pov, fine. My purpose in the discussion was to move some people off of precipitous thinking.

No. The flight surfaces would return to neutral, and the aircraft would passively attempt to hold bank angle in the same way as a traditional airliner. It won't actively try to hold a lateral flightpath.

They were deflected?

[HazelNuts39]

Figure 64 of the final report (download separately from the BEA site) shows in a simulation what the airplane would have done without pilot input with reconstructed wind.

[DozyWannabe]

You have never wanted to accept my pov, fine.

It's got nothing to do with who the POV comes from, all I ask is at least *some* evidence to back it up.

My purpose in the discussion was to move some people off of precipitous thinking.

To the best of my knowledge, very few folk on these threads ever did so - in fact none who stayed around to discuss things did. Even those who actively bemoan the quality of low-hour pilots today have seen it as a system-wide issue rather than pointing the finger at this particular crew. The BEA wrote up the factual evidence, were very clear about system-wide issues and also did not disparage the crew. Throwing random "what-if"s into the mix serves to harm credibility as far as I'm concerned.

[Lyman]

HazelNuts39 Figure 64 of the final report (download separately from the BEA site) shows in a simulation what the airplane would have done without pilot input with reconstructed wind.


So now we know.... What a relief. When did Bonin know it?

[DozyWannabe]

Does it matter? The point is that the correct thing to do was monitor and correct as necessary. Immediately grabbing the PFC and making large inputs prior to properly assessing the situation is more than likely to make a bad situation worse.

Drilling that fact in until it overrides the instinctive "startle response" is the only way to combat it.

[HazelNuts39]

We know what he did, but not why he did it.

[Lyman]

Hazelnuts39

HazelNuts39 We know what he did, but not why he did it.


That is my point. Except to say, it appears he was correcting the flight path, at least to me. To say what he did was incorrect is an opinion, at least at first. It is also "substantiated"'after the fact, with data unavailable to the pilots.

[DozyWannabe]

That's just it - we can never know for certain, but given the evidence we do have, we can consider some possibilities as more likely than others.

The reason I don't believe the PF was confronted with a wildly divergent display from his colleague in the LHS is in part because I know that's not how the system works, and also because at no point is a discrepancy between the two PFDs and ISIS commented on by any of the crew - including the Captain, who after he arrived had a clear view of all three.

The reason I believe the pitch was commanded by the PF and not the automatics is because the DFDR traces of the stick input and pitch attitude tally almost perfectly up until the point of stall.

The reason I believe the displays were consistent with having lost speed information is the PNF's call at 02:10:15.9. ECAM is for systems-level troubleshooting, not maintaining or regaining control. The PFDs should be enough for that.

Lest this be perceived as a defence of Airbus, I believe they should have been a lot more pro-active about replacing the Thales AA pitot tubes than they were, and should have been more forceful in pushing for high-altitude manual handling and stall training. I think Air France should have mandated all three flight crew to be present on long-haul ITCZ crossings until the problem was fixed. I also think their CRM training was in dire need of overhaul.

[Lyman]

Lest this be perceived as a defence of Airbus, I believe they should have been a lot more pro-active about replacing the Thales AA pitot tubes than they were, and should have been more forceful in pushing for high-altitude manual handling and stall training. I think Air France should have mandated all three flight crew to be present on long-haul ITCZ crossings until the problem was fixed. I also think their CRM training was in dire need of overhaul.

Amen to that...

[DozyWannabe]

Having said that, I think it should be acknowledged that Airbus's response to the problem was to immediately form a working group with Boeing to tackle the problems of high-altitude stall across the industry. They deserve kudos for that.

I doubt it will convince everyone that Airbus does not deserve the brickbats thrown at them over the years, but I hope it will make some folk think twice.

[Lyman]

Let's not get carried away. Shortly after the wreck, the airframer published a bulletin advising pilots to review their Stall recovery procedures.

Rather an oblique admission of disconnect...

[DozyWannabe]

Let's not get carried away. Shortly after the wreck, the airframer published a bulletin advising pilots to review their Stall recovery procedures.

Rather an oblique admission of disconnect...

Not really - taking the eye off the ball as far as high-altitude stalls went was an industry-wide problem.

The industry had collectively suffered what renowned test pilot and astronaut Frank Borman once described (referring to the Apollo 1 fire) as a "failure of imagination". Stall training focused almost exclusively on low-altitude situations, where the advent of high-bypass jet engines meant that with 5 degrees pitch and full power it was possible to get out of it (and every manufacturer trained almost exclusively for this scenario). The prospect of bleeding off speed towards the operational ceiling (where thrust was far less effective) was to all intents and purposes disregarded by all manufacturers and airlines.

Modern previous UAS-induced stall incidents happened during the climb phase - Birgenair 301 being the most notorious example, and that was a single pitot tube failure that would not have presented a problem to Airbus's design. The West Caribbean 708 MD-80 (not UAS, but rooted in failure to diagnose stall) should have been more of a red flag, but because the root technical cause was a little-understood issue with the anti-ice system, it seems that the industry was happy to leave it there. Colgan 3407 should have been a warning too, but the industry focused on the fatigue levels of the pilots involved (which was understandable) rather than questioning why the Captain would pull up into a stall.

Every Thales AA pitot tube-related incident prior to AF447 was successfully recovered by the crews, and as such it's somewhat understandable that notification to crews of the issue and a procedure for dealing with the temporary UAS situation would have been considered enough prior to AF447.

Let's not beat about the bush here - most pilots on here were incredulous when AF447 IR#3 came out and it transpired that the PF got locked into a "pull-up" mindset throughout the accident sequence. I last flew a real aircraft in 1993 and even I remember that pulling up at or near the safe operational ceiling is a big no-no. However, I'm also acutely aware that when the fit hits the shan, reason can go out the window no matter how competent you are. I've seen it in myself, I've seen it in my friends and I've seen it in colleagues. Thankfully I've never been responsible for the lives of a couple of hundred people at the time I temporarily lost the plot, but I can still remember the cautionary lesson I took while cleaning the metaphorical egg from my face.

I don't consider this crew incompetent and never have. In fact one of the first things I said when I joined this discussion almost two years ago was that I consider them to have been incredibly unlucky and to some extent poorly-prepared by the industry that employed them. This isn't a zero-sum game - you don't have to try to prove the aircraft design deficient in order to honour and respect their memories, we simply have to honestly assess what went wrong and make sure it can't happen again.

As far as I'm concerned the industry as a whole deflowered the canine here - Airbus and AF included - but they weren't alone.

[DozyWannabe]

Oh, and apropos of nothing, the C4 documentary I watched last night (and picked a lot of holes in) is available here:

Fatal Flight 447: Chaos in the Cockpit - 4oD - Channel 4 (http://www.channel4.com/programmes/fatal-flight-447-chaos-in-the-cockpit/4od)

[Lyman]

Without any agenda, Dozy, explain to me your thoughts on the degrade, and the retention of a familiar axis, and introduction of an unfamiliar.

What happens to 447 with degrade to Direct, and its 'trim only' Pitch inputs, manual. Zoom climb? A focus on small inputs, and those by hand? I personally see a potential for salvation. If only to gain time, less altitude, and reappearance of good speeds. I know, hindsight.

Wadda ya think?

Thanks

[DozyWannabe]

For what it's worth, I think the trim issue is fairly inconsequential - because the stall situation was not identified in time by the crew. As I've said numerous times, the autotrim had potential for salvation because with sustained nose-down on the PFC it would have corrected itself without needing to touch the trim wheels.

Maybe if there was an attempt to force the nose down and keep it there in the last minute I may feel differently, but the fact is that the PF was pulling up practically all the way down. As such, failure to recognise the situation and use CRM to remedy it is considerably higher on my list of priorities.

Fundamentally though, the existence of Alternate Law is to provide the pilot with handling characteristics as close to normal as possible despite degraded systems functionality, and to suggest taking that away because of one incident where it worked marginally against the crew (in response to the handling pilot making inappropriate inputs) would be throwing the baby out with the bathwater as far as I'm concerned.

Incidentally - something that the documentary clued me into that I hadn't considered before regards the sudden switch to pulling up on the part of the PNF (and confirmed by the Captain), and that was the sound of the GPWS "PULL UP" warning at 02:14:17.

[EDIT : I don't think I've mentioned this before, but I almost had skin in the game. A fellow musician and friend of mine almost boarded AF447 that day, but elected to stay in Rio for a few more days.]

[CONF iture]

the idea that the systems weren't relaying useful information (in that it could be processed by the flight crew) simply does not square up with the PNF saying "We've lost the speeds" at approximately 02:10:15 on the CVR
You have been answered on that point already (http://www.pprune.org/7425052-post438.html) but you prefer to ignore the reality which allows you to camp on that false concept of your own.

If they lost the speed tapes at the time you mention, why the BEA is not mentioning it … or are you doubting the BEA now ?

[Hunter58]

It does not matter if it is a big X over half the screen or whatever it is, thete is a visual clue. Only it is not wort to be mentioned as contributing factor, and it was recognized.

We can turn in circles a hundred more times but it does not change any fundamentals. The pilots recognized the unavailability of information of the speed information. What they did not due is to follow with the appropriate actions.

We can discuss other visual clues, change the whole architecture of the flight deck, change the logic of the FBW system, add tactile clues, whatever.

In the end it has no effect as all these things still require the crew in charge to take the correct action to fly the aircraft. And that is what really was missing. To consequently think that the pilot is not the final authority and needs to be having the necessary education to do so in the end means to have the fully automatic aircraft.

We can only speculate on the nature of thinking wich lead to the inapropriate actions during the event. The way leading to those however are also cultural, but to understand this you must have lived in France as a foreigner.

In my opinion the real cause of this event lays very deep in the french way of doing things and no amount of changes on the technical side will change this and prevent such or similar events to happen again. We have hammered on Asian crews for causing loss of life on cultural factors but we fail to accept this as a reason for a 'western' crew.

[CONF iture]

The pilots recognized the unavailability of information of the speed information. What they did not due is to follow with the appropriate actions.
The pilots recognized the disappearance of some speed symbols, not a disappearance of the indicated airspeed. They would have been much better served with such disappearance of the all speed scale. That some speed symbols disappear is NOT a cue to trigger the UAS memory items.

The system knew something was wrong with the indicated airspeeds as it decided to disconnect AP but did not think as necessary to advise the pilots for the reason it had disconnected that AP.

The most difficult part in a scenario of UAS is to realize first that there is a UAS.
As soon it is a recognized, the pilot switch to the requested procedure, in this case a memory item – No guessing.
Pilots are trained to apply procedures and are pretty good at it – It helps so much if they are given the appropriate GO signal that will guide them in the right direction.

The system knew but did not inform – What a waste.

[BOAC]

You can all dress this up in whichever clothes you wish - the need for better 'control' systems on the AB, the way speeds are displayed, even badly written checklists, but the one big problem we have is the total illogicality of the response of PF in pitch and the apparent lack of 'command' (CRM if you will) from PNF.

These I feel will never be satisfactorily explained.

I hesitate to mention the 'O' bird, but I hear it flapping again.

[Linktrained]

For much of the event the THS was at full NU, IIRC. I believe that this was not commented upon by the crew. It may not be normally scanned even whilst it was within view of all. Is full NU "normal" in cruising flight ? (I think that I understand just how it may have reached this setting, but is that within what one might expect as "normal"?)

[jcjeant]

Linktrained
For much of the event the THS was at full NU, IIRC. I believe that this was not commented upon by the crew. It may not be normally scanned even whilst it was within view of all. Is full NU "normal" in cruising flight ? (I think that I understand just how it may have reached this setting, but is that within what one might expect as "normal"?) It always returns to the same point
Pull the stick (and sustained) at cruising altitude is heresy and lethal
Do not watch the flight instruments is evidence of a very bad practice (eg not seeing the trim wheels position.. altimeter .. etc ..)
The PNF is busy with a lot of things futile and foreign to maintains the aircraft's flight is another proof of poor training (first keep fly the AC .. and next investigate)
And this is common to all three pilots as they have the same bad training and same bad CRM
Like tell Mr Schramm in a interview (AF pilots manager) it was this night the" maximum of competence" in the cockpit
The key is to know what it means "maximum of competence" for AF and if it is comparable to the other pilots proficiency of major airlines ....

[mm43]

For much of the event the THS was at full NU...Only went that way after the aircraft was effectively stalled. On passing CLmax (AoA 9.6°) at 02:10:57, the THS had moved up only 1° from its cruise condition of about 2.7° NU. It was the continued NU on the SS that induced the THS to supplement the Elevator and head for maximum NU.

It would seem that neither the PF or PNF noticed the Trim Wheel moving - something I believe that wasn't in their "normal" scan, as in NORMAL LAW the THS is assumed to look after itself.

Even though the PNF announced the ALT LAW (Prot lost), the PF didn't acknowledge it verbally, and I think there has been a general consensus reached in these threads that neither the PF or PNF realized what the THS could do when other than in NORMAL LAW. By the time the Capt returned the majority of the THS NU had occurred, but like the other two, he probably never looked at its position or noticed that it was in the final stages of its movement.

[Lyman]

bonjour, mm....

Your quote, :ok: "By the time the Capt returned the majority of the THS NU had occurred, but like the other two, he probably never looked at its position or noticed that it was in the final stages of its movement."

That requires a suspension of disbelief such that even I am challenged to entertain it....


So let me ask you the hypothetical question that Dozy inartfully dodged.

Say it is so, and the crew were virtually ignorant of the controls.

If the only Pitch inputs available had been small manual 'trim only' excursions, do you not think the crew would grok this trim at Auto/loss?

If, without any airdata, (computer selects Alternat 2b), the a/c required pitch inputs, the fact that the THS is limited to three degrees NU would have completely eliminated the possibility of zoom, and STALL.

The controls Law architecture seems on the one hand to be mindful of PITCH in DIRECT LAW, but relies completely on ELEVATOR PLUS THS in an emergent and handling environment very touchy, when it should be MINIMAL.

IOW, without airdata, the need for very cautious PITCH input is clear, seemingly tailor made for DL PITCH, but it does not go there, it stops short, and allows the type of misdirected SS inputs.

IN DIRECT, the SS is abandoned (pitch axis), perfect for UAS, but goes to the vulnerable AL2 instead.

AIRBUS had the foresight to provide for careful PITCH work in DIRECT, suitable for UAS, but in the actual UAS condition, it allows 'mayonnaise'.

Qu' est-ce que c'est?

Merci bon chance

[PJ2]

http://www.pprune.org/tech-log/493472-af-447-thread-no-10-a-23.html#post7426387[/URL]]The basic laws are still Nz and roll rate until in "direct", right?
Yes, correct. I used the word "attitude" loosely but not in reference to what the fbw laws attempt to maintain. To put it straightforwardly, they maintain Nz and roll rate - no input, no change, so attitudes are maintained. IIRC, in Normal or Alt1/2 Laws, a small back pressure on the stick is required to maintain altitude beyond 33deg bank. In Direct, it's a regular airplane and some NU correction is required when banking to change direction.

[PJ2]

You're welcome TTex - yeah, I recall the 320 was quite different than the 330/340.

Like gums says, tiny movements on the stick are all that are needed.

[Lyman]

Let me rephrase, incorporate this:

"PJ2 Like gums says, tiny movements on the stick are all that are needed."


and ask, Would a degrade to DIRECT LAW have been more in tune with what we know of Airbus FBW?

As In:

Tiny movements on the stick are not available Only tiny trim originated inputs....

[PJ2]

Sorry Lyman I don't understand your question or point about "being in tune with what we know of Airbus fbw", or your observation, "Tiny movements on the stick are not available Only tiny trim originated inputs....".

[Lyman]

I think Airbus philosophy in general is excellent, but only ask that in the condition of 447, where complete authority in Pitch is retained, that here, specifically, a Default to Direct Law would involve caging the Pitch within strict limits eg: available, but in small doses.

Bonin must be the only pilot who would have acted this way? It depends on what one would expect from the pilot population as a whole, whether the risk to the aircraft with poorly trained airmen would warrant a scheme that went to Direct Law when the Airspeeds were lost. imo.

[mm43]

It depends on what one would expect from the pilot population as a whole, whether the risk to the aircraft with poorly trained airmen would warrant a scheme that went to Direct Law when the Airspeeds were lost.Whether you like it or not, the aircraft reverted to ALT2b.

Consider the pilot knows what's best and demands NU on SS, hence the Elevators follow and as the airspeed is bled off and the 'g' commanded is not being met, the THS commences its journey. It knows no better, only that the pilot knows best.

The point of all this is that if the aircraft during this UAS event had actually gone into Direct Law, and the THS was limited at 3° NU, the aircraft when handled the way it was would still have stalled. Owain Glyndwr has pointed out many times that the Elevators [alone] were quite capable of providing whatever NU/ND was requested.

Since when has an airframer been responsible for the actions of poorly trained airmen/women? I'm not talking about the 'deep pockets' litigation that seeks to make them responsible, but rather the expectation that the aircraft will be flown by properly trained and competent personnel.

You can argue until the 'cows come home' [in your grassy valley], but in the case of AF447 the expected procedures were not followed, CRM was lousy, and if there was any acknowledgement of the situation they were in, it must have been done with 'sign language'.

AB will most likely make changes to the way problems with faulty air-data is revealed to the crew, but this is to be expected in line with progressive improvements to the software. Now this could also be construed as further 'dumbing down' of the competency levels required to fly their aircraft. If its in the interest of 'safety', then I believe most will manage to live with it.

Now where is the concierge?:}

[CONF iture]

but the one big problem we have is the total illogicality of the response of PF in pitch and the apparent lack of 'command' (CRM if you will) from PNF.
Illogical in its excessive amplitude and in its duration yes, but certainly not illogical in itself, what do you do suddenly 400 feet below your cruising FL and your aircraft pitching 2 or 3 degrees under a normal cruising attitude ?

Mention the 'O' bird as you wish, but the initial response of PF in pitch was not fatal, it was far to be ideal, but things had stopped to deteriorate before the FD came back and everything started again for the worse.

Much emphasis on the PF case but I find you guys almost too unconcerned by :

The lack of awareness given by the system to the crew
The FD logic
The THS logic
The stall warning logic
The sidestick concept

Those 5 technological elements played against the crew that night.
Change one of those and chances to disrupt the deadly sequence are improved.

I take that opportunity to link a comment by Sullenberger on the sidestick versus …

kERSSRJant0&NR=1

[DozyWannabe]

And where in the final report does it say that "only the pilots" are to blame?

[Hint : it doesn't.]

CONF - Sully says it's his opinion (to which he is welcome) - he doesn't try to present it as fact.

[jcjeant]

The only certain fact is that I know is that AF447 crashed into the sea and there killed 228 people
This fact is indisputable (100%) and is recognized by the BEA
Other facts known by the BEA are not a 100% certainty and therefore logically BEA provides only conclusions based on the opinions (which are welcome) of investigators about those "facts"
Final BEA conclusion after years of investigations:
We don't know why the pilot made climb the plane to finally keep it in a stall position
BEA (as us) also know that the pilot (s) actions give as result 228 people killed
It's certainly not caused by the plane as the BEA state that the plane and systems acted as per design
And as the Airbus A330 design is good (proof is the sooo many hours of flights with no problems .. even in same situations like AF447) .. so the plane can be discarded as culprit ...
Evidently (they can't) the BEA don't blame the crew ... only "conspiracy nuts" think that the BEA blame the crew ...

[Turbine D]

Hi jcjeant,
Evidently (they can't) the BEA don't blame the crew ... only "conspiracy nuts" think that the BEA blame the crew ... I fully agree. The BEA drew in other agencies and information sources, examined the pertinent evidence, published a factual report listing causes or probable causes and made recommendations to EASA to follow up on. Everyone is entitled to an opinion as to the content of the BEA report, but it become obvious to most when facts turn into fiction such as your statement suggests...

[Organfreak]

jcjeant wrote:

It's certainly not caused by the plane as the BEA state that the plane and systems acted as per design
And as the Airbus A330 design is good (proof is the sooo many hours of flights with no problems .. even in same situations like AF447) .. so the plane can be discarded as culprit ...

I don't entirely agree, nor does the BEA. Aviation is not for the simple-minded; it's complicated. It depends upon if your view of cause is black-and white or not. A number of recommendations were made for improvements to the aircraft, based on reasonable suspicions (I guess we could call it) as to causation/confusion in the cockpit (flight director behavior, stall warning architecture, etc., etc.: see CONF iture's post). "As per design" may not be good enough, even if said design was approved by the authorities. Learning is on-going, not fixed. There is room in almost any design for improvement. Without, of course, having proof, it is entirely reasonable to speculate that some of the proposed improvements to the A330 might have broken the deadly chain-of-events.

I love Swiss cheese if I'm eating it, but I don't want to ride in it! :uhoh:

[roulishollandais]

1. I personaly cannot agree the CVR and said it since months. The language is not tbe language used by French professionnal pilots.Not sure that BEA was the redactor . To much sterilized? Not only.
For instance, when you write in (correct) French : "tu montes", we do not know if it means : "tu montes?" ,or "tu montes!"
Listening the text it is not said the same manner and we can understand the correct meaning : the first has "mon" climbing, the second has "mon" climbing and descending.
BEA knows that and would not write a non-pilot used text.
The Captain briefing is really unrealistic.
Did the "human factor" team write that? Not impossible , as the final report describes the sequence in a manner everyday flight would be psychedelic, not only AF447.
Has the CVR been translated to bresilian, then to german, then to english, then to french,with indian or tunisian translators? (In modern decision making they call that "consensus"!)
There is a CVR bug. Do without it.
2 . When you buy a ticket to an airline, you don't buy it to A or B or C. It belongs to :suspect:certification autority to verify that the aircrafts are safe enough for public transport. Certification autority has to verify that airline pilots' selection and trainning by the airline is adequate for that aircraft, that simulator t eaching is conform to that aircraft. The airline has not the means to verify that, major airline or not. Certification administration is alone to be able to do that and have autority and RESPONSABILITY to do that job. It is THEIR JOB.

[Turbine D]

Certification administration is alone to be able to do that and have autority and RESPONSABILITY to do that job. It is THEIR JOB. That would be the EASA...

[Linktrained]

In the 1950s and 1960s there were far more aircraft accidents as a proportion of the world transport fleets. Many then seemed to have a number of causes or contributing factors, often three or more. Many of these contributing factors have been "designed out". Systems have become more reliable, enabling very high and profitable utilisations.

" Simple things", like Checklists and Weather Minima, better landing aids, Flight Time limitations, Aquaplaning, Aircraft Performance calculation graphs were some of the items which only ultimately were to reach my level of knowledge as a First Officer. Some of this may have been known elsewhere in a Company, but prior to photocopying, much would have been kept in a Head Office drawer !

Flying training required, then, for a F/O was 6 T/Os and Landings, by day.
A Captain only had to do 5, some at night and with an engine failure.
( With this level of training......... !)

(If I exceeded 125 hours flying in a month, I would require a further medical ("to see if I was fit for a further 125 hours," it was said. !))

[TTex600]

The main lesson besides all the detailed system aspects is that also an Airbus pilot should view his Airbus like any other conventional plane and fly it like one.

Pitch and Power determine your trajectory, and your job is to control this trajectory. This is done by setting appropriate pitch and power regularly manually.

I'll agree with pitch and power and regular practice. Can't agree about the fly it like a conventional airplane, especially when things are abnormal. Auto trim for "g" and flight path make the airbus unlike a conventional aircraft.

[Lonewolf_50]

Mixing and matching points
mm
AB will most likely make changes to the way problems with faulty air-data is revealed to the crew, but this is to be expected in line with progressive improvements to the software.
Now this could also be construed as further 'dumbing down' of the competency levels required to fly their aircraft.
If its in the interest of 'safety', then I believe most will manage to live with it.
Consider the pilot knows what's best and demands NU on SS, hence the Elevators follow and as the airspeed is bled off and the 'g' commanded is not being met, the THS commences its journey. It knows no better, only that the pilot knows best.
That is a sound basic design philosophy.
I note a few points from CONFiture that what the pilot "knows" when he is in "knows best" mode depends upon two things:
how in depth his aircraft systems knowledge is,
and what info he has available to establish his event particular knowledge.

They go hand in hand.

Another point made was that to get to
"I need to use the UAS procedures"
certain key bits of knowledge are needed. This folds into mm43's point.

While one is sorting that out, it would seem to me that basic airmanship includes a scan that would alert you to the fact that one is changing state.
"Heh, while I'm getting this squirrely little roll problem sorted out and regaining a few hundred feet, I need to get back to my desired/assigned altitude."
The above is a standard, novice level instrument flying problem. What AF447's crew had as an added twist was that airspeed as a cross check performance indication was missing. Since the AH/attitude indicator was working (as best as we can tell, supported by PF initially relying on AH/attitude indicator to get a grip on his roll excursions, eh?) ... that should not be too big of a problem.

Basic pilot skills tell you that if you have not yet changed power, nor configuration, your speed and altitude are trade offs for one another. Set an attitude, see what changes, adjust, see what changes, adjust, and so on. You are back to straight and level soon enough.

Basics.

Even though the pilot of the day has lost his speeds, he could know that with no power change, increase of altitude was going to slow him down. (and vice versa). Once the power changed as the problem proceeded, the above isn't the simple adjustment problem, but change in altitude still ought to be telling the flying pilot something about his flying performance.

I get the impression that flying the bird/FPV seems to have replaced a basic instrument scan. Maybe just in this case.

One cannot lay the blame for something like that at the foot of Airbus, or of Boeing, or any single design bureau. Such aids to instrument flying have been in the aviation business for decades, and very handy they are! They are an aid to an already developed skill, the instrument scan, and do indeed reduce cockpit workload.

This takes me back to: how often does the average pilot actually fly / practice his instrument scan with fewer features enabled?

For a given pilot, how long will it take to get you to restart your instrument scan when the standard (and generally reliable) features take some time off?
How prepared are you?
How often do you get to practice? <-- Does airline management understand why that last question is so important?

[jcjeant]

Some infos (real world)
G1 - Justiça do RN condena Air France a indenizar família de vítima do voo 447 - notícias em Rio Grande do Norte (http://g1.globo.com/rn/rio-grande-do-norte/noticia/2012/09/justica-do-rn-condena-air-france-indenizar-familia-de-vitima-do-voo-447.html)

[PJ2]

Lonewolf 50;
Basic pilot skills tell you that if you have not yet changed power, nor configuration, your speed and altitude are trade offs for one another. Set an attitude, see what changes, adjust, see what changes, adjust, and so on. You are back to straight and level soon enough.
Yes - and this is what the FCTM on Unreliable Airspeed describes; small adjustments, wait...etc
I get the impression that flying the bird/FPV seems to have replaced a basic instrument scan.
Possibly. Not all transport pilots are familiar with the indication and so it requires training to use effectively and safely. It's a trajectory indicator as we know, (which is why it is removed upon selecting TOGA on a G/A) and while useful in some circumstances it has to be used in conjunction with energy awareness and not used alone to fly the aircraft. I still find it difficult to accept that pilots at this level would follow the flight directors and compromise the energy level of the aircraft but I think a valid point has been made during these discussions.

On your last comment, no, I don't think airline managements comprehend the value of raw data/manual flying practise. I think management awareness atrophies as financial constraints and complex simulator scripts combine over time to push out "that which pilots ought to know already", to concentrate on the competent management of autoflight systems in normal and abnormal flight circumstances.

In my experience, mere "practise" was sometimes given by individual instructors who knew its value but only when the script had been finished. Box-ticking has its value if the boxes are appropriate to training requirements and ensuring standards are met but manual flight and raw-data approaches are usually left out of the session. I think the need has been amply demonstrated and hopefully a refocus on the basics, as you describe them, is occurring. I've been away from it now for five years and no longer have a close sense of these sets of priorities.

[roulishollandais]

Thank you jcjeant

Tomorrow a french decision about possible no competence of french penal court for ocean pollution in the international waters. The lawyer is Daniel Soulez Lariviere who could ask that for the AF447 case:confused:

[Hunter58]

PJ2

Airline management frankly does not care about how pilots fly, that is what Operations Management headed by the chief pilot is for. Do you really think that the management of an airline discusses how to fly the crates? Not a single second!

The real culprits for these factors are the operations management, therefore pilots with management functions who promised a certain budget and now have to prove it. Or who believe that their flying skills are so good they do not need more training and therefore that is the way for all. In the end it is someone from the pilot community who introduces all this, not 'management'.

I believe not even MOL cares but he vividely repeats what comes from the crownies in the pilot ranks that wanted to be close to him...

[DozyWannabe]

@Hunter58:

I'm certain that PJ2 is well aware of the distinction, but chose to use a broader definition for the benefit of us laypeople. :)