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



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

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.

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.

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

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

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.

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

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

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

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?

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

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.

Is it again something of your own making ?

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

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.

Forget about the ACARS timings then ...

Absolutely not conclusive.

This flatly contradicts nothing.

Actually it came from Hunter58 earlier in the thread:

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

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.

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.

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?

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:

Hazelnuts39

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

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.

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

Chapter*10.*Navigation

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.

UAS early warning
 

Hi,

Quote:

---

Because it's one of the most difficult situations to reliably work out - as has been stated previously.

---

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

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

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


(*) Keep It Complex Stupid

ACARS
 

From page 98 of the final:

From I#1 also:


Beats me?

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

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.

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.

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.