AF 447 Thread No. 10
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by DozyWannabe; 18th Sep 2012 at 21:23.
Join Date: Nov 2010
Location: FR
Posts: 477
Likes: 0
Received 0 Likes
on
0 Posts
Now... hat, coat...
Last edited by AlphaZuluRomeo; 18th Sep 2012 at 21:41.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.....
How many times can one person say "The turbulence was not sufficient to cause AP disconnect" before you believe them?
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
If the PF believed that the protections would allow them to pitch up and climb safely then the whole conversation about altitude was moot.
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 ... ?
Last edited by jcjeant; 19th Sep 2012 at 00:52.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by TTex600
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.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
Those 4 minutes (yes .. they were startled for 4 minutes .. long time .. 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 ... ?
Again .. the "surprise" effect ... ?
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Dozy
The big red X on the speed tape
and the disappearance of the Vx indicators should have been a significant clue, no?
It's also possible that IAS DISAGREE/ADR FAULT was bumped off the ECAM when the ADR DISAGREE appeared, as OK465 attests to.
Also, it is not what OK465 was attesting.
The ACARS timings are very vague - the final report contains more accurate timings which I'd imagine came from the DFDR.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Dozy
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.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
The PNF's reference to losing the speeds is at approx. 02:10:15.
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.
Last edited by DozyWannabe; 19th Sep 2012 at 02:15.
Join Date: Jul 2009
Location: France - mostly
Age: 84
Posts: 1,682
Likes: 0
Received 0 Likes
on
0 Posts
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?
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?
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
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.
"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.
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
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.
"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.
One is a constant
"Dave - I'm sorry"
The other is a variable
"As long"
Not so sure that the result will always be good
Last edited by jcjeant; 19th Sep 2012 at 10:15.
Join Date: Aug 2011
Location: Grassy Valley
Posts: 2,074
Likes: 0
Received 0 Likes
on
0 Posts
Hazelnuts39
The computer is trying to determine if the ADR disagree is induced by NAV (sic) Maneuvering? Eg slip/skid, asymmetric, etc.
The computer is trying to determine if the ADR disagree is induced by NAV (sic) Maneuvering? Eg slip/skid, asymmetric, etc.
Last edited by Lyman; 19th Sep 2012 at 11:21.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by DozyWannabe
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.
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.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
Last edited by DozyWannabe; 19th Sep 2012 at 13:50.
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes
on
0 Posts
UAS early warning
Hi,
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
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. (*)
This flatly contradicts any assertion that the systems were not providing the relevant information to the crew.
...at least half the crew on the flight deck were well aware what the problem was.
(*) Keep It Complex Stupid
ACARS
From page 98 of the final:
From I#1 also:
Beats me?
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.
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,
Last edited by OK465; 19th Sep 2012 at 22:10.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
The System provided a lot of information including processed garbage.
A good man-machine interface could provide to 100% of the crew (including Capt) reliable information.
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.
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
Originally Posted by OK465
- the order in which these messages are transmitted does not necessarily correspond to the associated sequence of events
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.