CONF iture: When I flew A330 it was possible to access the individual AOA values via the CMS using the applicable codes. I assume the A320 has similar functions?

Yup, those values are actually shown without the need to call them up by code, but that might be just a preset on our busses.

Are you supposed to access this kind of data during a flight ?

sonicbum: Yes, easily done in flight.

Read the question again : are you supposed to ?

For a test flight like that, yes, of course. In normal line operation? No, not really, just used to check on some facts or for curiosities sake.

This is the point. The thread veered from its original meaning.

Posts above appear to disagree with that? I appreciate you appear to have a grudge against Airbus and it's products, but does it really extend to accusing Airbus of writing Test Schedules asking the impossible :confused:

I do, but the likelihood is it was, and anyway, there was other, more compelling evidence.

I am not sure I would? The QF A380 incident, IIRC, is tending towards reducing "ECAM Messages" for everything? I spend enough of my time on the A320 dealing with spurious, unnecessary, and transitory ECAM messages. There needs to be a balance in life, some level of trust in designers and certification procedures re "fault tree analysis". To have an AoA problem such as Perpignan, ignore the signs there was such an issue, and then require a Max Perf GPWS warning I consider "improbable".

Is the Airbus FBW perfect? Of course not. Has it stood the test of time well, for the first mass market FBW commercial airliner? Yes. It has been improved, minor faults ironed out. I think we are now past the stage where the machine is the target of "blame" and "fault" - indeed for the A320 series I do not think it ever was. The FBW is well in the mature "refinement" phase.

The training and oversight / management of the operators would be a more productive target - IMHO. Perpignan an unfortunate, but clear, example - despite Airbus' efforts, man proved it is not uncrashable :{

Zee pushbutton is optional and labelled "EVAC". At least, last part of your statement is correct.

Exact same reply stands :
The crew has rushed and was clearly poorly prepared, but how would you want them to check those 3 AOA values when only 2 are available and so only indirectly through the third MCDU ... ?
But what about you actually link the document you mention ... ?

As improbable as 2 AOA vanes would lie together to trigger a protection that a crew could do nothing about it ... except by shutting down some computers ... or how to have to publish an improbable red OEB.

BEA Report:

NigelOnDraft
Once we leave the ground we are in a hostile territory because since it is not a human habitat we have no instincts whatsoever. Only birds have that and that is why we have procedures. Any deviation from them and you are like a blind man who has missed a cue. There are any number of accidents/incidents which show that whenever a pilot has surprised the airplane by change of plan the aircraft has sprung up a fatal surprise. But you won't prove a point to Conf.

Blame the crew for not doing the test above 10000ft and not recalling the characteristic speeds during the briefing, but not for not applying a procedure they didn't have.
In the meantime I do maintain that ISATM procedure is erroneous as there is no way to read the data for AOA #3

Conf wouldn't keep his job much longer if he was not following the procedures.
The system knew something was wrong with the data, all it needed was to advise the crew by a straightforward ECAM MSG :
NAV AOA DISAGREE

As Airbus gave so much priority to the AOA data in its system, it would be logical to at least advise a crew when one single reading differs from the 2 others.

Why wouldn't be there any way? You can read all AoA values from every MCDU as has been explained above. It's easy enough to do, and i would expect it to be detailed in the relevant procedure.

I do agree however that an AoA disagree advisory would be a nice clue about whats up.

One problem is that this was a 1 vs 2 disagree. So the system used the "2" that agreed. (Just like a pilot would I suspect, given three sources of data where 2 agreed). The most likely scenario for such a case is the "1" is bad, so ignoring it and doing nothing else is a good plan EXCEPT if you are doing flight tests. So if there was a message which just said "take no action" I'm not surprised they decided not to bother line crews with it.

A lot of this comes down to the big topic from this accident - the way such flight tests are (were, rather) conducted.

Conf
I said in post 46 the following
"All these protections are triggered from data derived from one sensor or the other but the present system of sifting the data to ensure it's genuineness is being proved inadequate and is the cause of all these incidents. The answer to this will come from better sensors, better system of confirmation of data or even quantum leap of technology in measurement of airspeed,"
So I had already said AB needs to change the method of identifying the faulty ADR/component. That includes change in ECAM messages or even giving the job to the crew to identify it for themselves until a new method of air speed measurement is discovered. I agree that crew was not warned of the ADR3 rejection in some cases it does which can be easily included in the ECAM and the crew advised to confirm it if it was correct.

The 1v2 disagree can be fixed quite simply by introducing monitoring over time. The Perpignan a/c had two probes at fixed values for a long period, including speed, altitude, and config changes... if a flight test engineer had monitored them he would have noticed the fault; all we need now is software as competent as humans.

Every single parameter is not necessarily available through the ACMS (or is it called AIDS on the 320 ?)
AOA1 and 2 are there but #3 is nowhere to be seen ...

All three AOA are available on AIDS and test flight requires write down value for all of them in clean configuration,green dot speed and croscheck/comparation with "angle" obtained from differenece btwn. pitch and flight path angle. Maximum allowable difference is 0,5 degree. Don't know if this procedure was valid at the time when Perpignan happend..:confused:

One thing which I did not understand is why did the aircraft go in direct law. First the rejection of the third is no different than ADR3 fault should have come on ECAM and the second is any combination of ADR malfunctions is not suppose to trigger direct law. Nobody else also has noticed it.