AF447 Thread No. 3
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi sensor_validation, bekolblockage, everybody,
A340 AIRPROX;
Full thrust was not from protection. The report messed up stuff.
Alpha_floor (as quoted in report) is inhibited above Mach 0.53 if I remember correctly.
Autothrust was disconnected by the crew: they should have received a THRUST LOCK signal (no ALPHA LOCK as reported).
Thrust increased from under 70% N1 (where the autothrust settled it because of the overspeed event before manual disconnection: overspeed protection is first managed by the autothrust) to 100% N1 in a short while. It is unclear if it was due to manual action (I guess it was because N1 was previously stable around 90% before turbulence encounter).
In this case, the climb (and pitch increase) is related to this sharp thrust increase (4 engines at 100% N1), being not countered by nose down imput from the PF.
Autopilot was first disconnected due to overspeed (it was not due to Alpha prot).
This TCAS event just added to the confusion.
Stick pitch axis data on the graph seems also inverted (or alpha_prot kicked at the top of the climb, but it is hard to see it without any AoA data track pictured on the graph - quite disturbing as to suport the AAIB comments).
A340 AIRPROX;
Originally Posted by sensor_validation
You have to go back more than 43 pages! The ballistic zoom-climb trajectory demonstrated by the A340 was suggested as soon as the proximity of the crash site to LKP confirmed - and the FDR plots in Appendix B of the AAIB report re-published a couple of weeks ago. But the A340 in daylight did not lose air-speeds so flight control laws and protections not the same as AF447 - but was way above safe height and must have been very close to stall at the apogee at FL 384 "where the airspeed had decayed to 205 KIAS and 0.67 Mach even though full thrust had been applied". Full thrust was from protection even though A/T off.
Alpha_floor (as quoted in report) is inhibited above Mach 0.53 if I remember correctly.
Autothrust was disconnected by the crew: they should have received a THRUST LOCK signal (no ALPHA LOCK as reported).
Thrust increased from under 70% N1 (where the autothrust settled it because of the overspeed event before manual disconnection: overspeed protection is first managed by the autothrust) to 100% N1 in a short while. It is unclear if it was due to manual action (I guess it was because N1 was previously stable around 90% before turbulence encounter).
In this case, the climb (and pitch increase) is related to this sharp thrust increase (4 engines at 100% N1), being not countered by nose down imput from the PF.
Autopilot was first disconnected due to overspeed (it was not due to Alpha prot).
This TCAS event just added to the confusion.
Stick pitch axis data on the graph seems also inverted (or alpha_prot kicked at the top of the climb, but it is hard to see it without any AoA data track pictured on the graph - quite disturbing as to suport the AAIB comments).
Join Date: Nov 2006
Location: SoCalif
Posts: 896
Likes: 0
Received 0 Likes
on
0 Posts
Pitot Physics, cont.
mm43:
Thanks for the question, MM. Jetstar did not get a TCAS Fail, did it?
The companies that build the TCAS also build the ATC Transponders. Like I wrote before, if you're going to insert such a reasonableness filter into the ATC/TCAS system, you would put it in the transponder, as it's just as important to report correct altitude to other aircraft as it is to have your TCAS using correct altitude.
Besides, failed altitude input should cause TCAS to report OFF, not Fail, but I'm not 100% sure of that at the moment. Selecting ALT to OFF on the ATC/TCAS control panel will for sure result in TCAS OFF.
Yesterday when posting the FDR traces for the Jetstar A330 incident, I mulled over the static port problem, then looked at the ECAM messages and realized that the sequence of events was very similar to AF447. So, getting back to the TCAS fail message, I'm starting to feel that the ALT supplied to the Transponder changed at a rapid rate, i.e. the speed correction value changed, and the TCAS determined the rate of change wasn't valid and shut-up shop.
Do you think that could fit the bill?
Do you think that could fit the bill?
The companies that build the TCAS also build the ATC Transponders. Like I wrote before, if you're going to insert such a reasonableness filter into the ATC/TCAS system, you would put it in the transponder, as it's just as important to report correct altitude to other aircraft as it is to have your TCAS using correct altitude.
Besides, failed altitude input should cause TCAS to report OFF, not Fail, but I'm not 100% sure of that at the moment. Selecting ALT to OFF on the ATC/TCAS control panel will for sure result in TCAS OFF.
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
mm43:
Any system that pressents "conclusions" to a user without access to the underlying raw data is inherently problematic, especially if there are unknown interactions. (Unknown or untrained for by the users).
Even if the raw data is suspect it should still be presented with a warning.
One analogy for the stall warning action would be an "idiot light" in a car without an oil pressure gauge that signals low oil but goes out if you overspeed the engine.
BTW: For a good example of bad outcome caused by sending "data invalied" rather than "possible error but here is best guess" see the
report for the destruction of the maiden flight of the Arieane5 launcher.
As takata has rightly pointed out, IAS greater than 60KTS AND/OR AoA less than 30 degrees are required to prevent the Abnormal Law activating. It is while in this AND/OR regime that a very clear warning needs to be given that the aircraft is stalled. IAS is useful, and AoA is useful, and it would be preferable to know each rather than being left in the dark because one or the other, or both wasn't deemed valid.
Even if the raw data is suspect it should still be presented with a warning.
One analogy for the stall warning action would be an "idiot light" in a car without an oil pressure gauge that signals low oil but goes out if you overspeed the engine.
BTW: For a good example of bad outcome caused by sending "data invalied" rather than "possible error but here is best guess" see the
report for the destruction of the maiden flight of the Arieane5 launcher.
Join Date: Jul 2009
Location: UK
Posts: 134
Likes: 0
Received 0 Likes
on
0 Posts
Hi sensor_validation, bekolblockage, everybody,
A340 AIRPROX;
Full thrust was not from protection. The report messed up stuff.
Alpha_floor (as quoted in report) is inhibited above Mach 0.53 if I remember correctly.
Autothrust was disconnected by the crew: they should have received a THRUST LOCK signal (no ALPHA LOCK as reported).
Thrust increased from under 70% N1 (where the autothrust settled it because of the overspeed event before manual disconnection: overspeed protection is first managed by the autothrust) to 100% N1 in a short while. It is unclear if it was due to manual action (I guess it was because N1 was previously stable around 90% before turbulence encounter).
In this case, the climb (and pitch increase) is related to this sharp thrust increase (4 engines at 100% N1), being not countered by nose down imput from the PF.
Autopilot was first disconnected due to overspeed (it was not due to Alpha prot).
This TCAS event just added to the confusion.
Stick pitch axis data on the graph seems also inverted (or alpha_prot kicked at the top of the climb, but it is hard to see it without any AoA data track pictured on the graph - quite disturbing as to suport the AAIB comments).
A340 AIRPROX;
Full thrust was not from protection. The report messed up stuff.
Alpha_floor (as quoted in report) is inhibited above Mach 0.53 if I remember correctly.
Autothrust was disconnected by the crew: they should have received a THRUST LOCK signal (no ALPHA LOCK as reported).
Thrust increased from under 70% N1 (where the autothrust settled it because of the overspeed event before manual disconnection: overspeed protection is first managed by the autothrust) to 100% N1 in a short while. It is unclear if it was due to manual action (I guess it was because N1 was previously stable around 90% before turbulence encounter).
In this case, the climb (and pitch increase) is related to this sharp thrust increase (4 engines at 100% N1), being not countered by nose down imput from the PF.
Autopilot was first disconnected due to overspeed (it was not due to Alpha prot).
This TCAS event just added to the confusion.
Stick pitch axis data on the graph seems also inverted (or alpha_prot kicked at the top of the climb, but it is hard to see it without any AoA data track pictured on the graph - quite disturbing as to suport the AAIB comments).
As discussed earlier, there was no fault found with the controls at the time, the issue investigated was the near-miss. What is clear is that the pitch up in the A340 was after A/P and A/T disconnect, and before any sidestick input, but curiously I now see the stab was moving. The pilot inputs to Mach Speed setpoint before A/T disconnect or manual throttle after are not shown. If the pitch up caused by manual throttle change (CAS had fallen significantly) - is it not true a twin engine A330 has more excess thrust than a four engine A340 (both are certified to take-off with loss of one engine)?
HUD display
The flight path marker in the A-7, F-16, F-15, F-18 and Space shuttle shows inertial velocity vector. Watch the space shuttle landing tonight and you'll see it NASA TV should use a lot of the HUD video as it will be dark outside for normal TV coverage. Sucker shows exactly where you will impact the ground if within the field of view. On one night landing they showed it until the craft lowered the gear. Also showed it a lot when a buddy of mine ( Lindsey) had a decent cloud layer to penetrate.
Scales on left and right show altitude and airspeed. Other guidance symbols are also present.
The A-7 showed inertial vertical velocity on same "thermometer" scale as the altitude. It also displayed an AoA symbol all the time. If inertial went bat sh^%$, it used doppler and basic attitude to provide a reasonable vector, actually a doggone good one. Altitude was either radar or baro. Spped was dynamic pressure as per the steam gauge.
F-16 could display IAS/CAS or TAS or GS. It only displayed the AoA symbol with gear down, but we had other indications of AoA. Altitude was baro until we got the LANTIRN birds and later models.
The good thing about the flight path marker in a fully developed stall is that it is "pegged" at bottom of the HUD field of view or even below it!! In the Viper it would have an "X" over it to tell you it was invalid being outta the field of view.
Scales on left and right show altitude and airspeed. Other guidance symbols are also present.
The A-7 showed inertial vertical velocity on same "thermometer" scale as the altitude. It also displayed an AoA symbol all the time. If inertial went bat sh^%$, it used doppler and basic attitude to provide a reasonable vector, actually a doggone good one. Altitude was either radar or baro. Spped was dynamic pressure as per the steam gauge.
F-16 could display IAS/CAS or TAS or GS. It only displayed the AoA symbol with gear down, but we had other indications of AoA. Altitude was baro until we got the LANTIRN birds and later models.
The good thing about the flight path marker in a fully developed stall is that it is "pegged" at bottom of the HUD field of view or even below it!! In the Viper it would have an "X" over it to tell you it was invalid being outta the field of view.
Last edited by gums; 31st May 2011 at 14:22. Reason: addition
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi Martin,
AP, ATHR, flags on PFD, etc. all disconnected at 0210:05 due to unreliable airspeed processed by the PRIMs (Flight control computers)... this is the root cause of everything. The system switched to ALTERNATE LAW (PROT LOST) at this point because two or three pitots displayed a variation of airspeed above 30 Kt during one second. As this event lasted more than 10 seconds, ALTERNATE LAW would be definitive until the end of the flight, but autopilot and autothrust could have been re-engaged later if two calculated airspeed would be considered valid again by the PRIMs.
There is absolutely zero doubt that this is why AP went off.
Do you remember also that the floating wreckage was found drifting 6 days later?
The "Tail" was not found: it was the vertical stabilizer part of it... This piece wasn't drifting alone but with the main floating wreckage, including something like 3,000 pieces of this aircraft and 50 bodies.
Come-on!
RTL (rudder travel limiter) fault is related to RTL airspeed function that was invalid due to PRIMs rejection! (you can't set a value limiting RTL deflection without a valid airspeed)... NOT that it was ripped off!!! There was 36 cases discussed in BEA reports about "unreliable airspeed" and each had the same RTL fault. All this aircraft landed with their vertical stabilizer!!! This fault could be cleared once the airspeed will stabilise and be considered valid again by the PRIMs.
Please, go read the BEA previous interim reports; they won't write again everything that was already validated as "facts" in each subsequent publication (like this last note). They will only write about any new findings that could invalidate/correct anything previously established (and so far, nothing appears contradictory to what was already established).
Originally Posted by MartinM
The AP disconnected automatically, but what happened before? What actually made the AP disconnect.
There is absolutely zero doubt that this is why AP went off.
Originally Posted by MartinM
I plotted the position of the wreck and the position where the Tail was found. The Tail actually was found 70Km northeast of the location of the wreck. While the sea current where at that day were going northeast to south. How the heck did the Tail get so far away from the wreck assuming that it was still sitting on the tailcone on impact.
The "Tail" was not found: it was the vertical stabilizer part of it... This piece wasn't drifting alone but with the main floating wreckage, including something like 3,000 pieces of this aircraft and 50 bodies.
Originally Posted by MartinM
Bringing these two elements together makes me assume that the tail was already ripped of the plane earlier. While in deepstall? No. But at what point in time. Maybe exactly at the point when the pilots were doing a right turn. Remember, the FDR said, pilot gave stick input to the left and up. At the same time, ACARS reports a failure of the RTLU. Well, I would say, tail gone, RTLU gone. Logical response of ACARS to report it as failed
As BAE has not release exact coordinates of the flightpath, it makes it hard to overlay with the other position. fact is, they turned back before the decent and due to this the theory looks valid to me.
Opinions?
As BAE has not release exact coordinates of the flightpath, it makes it hard to overlay with the other position. fact is, they turned back before the decent and due to this the theory looks valid to me.
Opinions?
RTL (rudder travel limiter) fault is related to RTL airspeed function that was invalid due to PRIMs rejection! (you can't set a value limiting RTL deflection without a valid airspeed)... NOT that it was ripped off!!! There was 36 cases discussed in BEA reports about "unreliable airspeed" and each had the same RTL fault. All this aircraft landed with their vertical stabilizer!!! This fault could be cleared once the airspeed will stabilise and be considered valid again by the PRIMs.
Please, go read the BEA previous interim reports; they won't write again everything that was already validated as "facts" in each subsequent publication (like this last note). They will only write about any new findings that could invalidate/correct anything previously established (and so far, nothing appears contradictory to what was already established).
Last edited by takata; 31st May 2011 at 15:33.
Join Date: Jul 2009
Location: USA
Posts: 102
Likes: 0
Received 0 Likes
on
0 Posts
So the nose-up input was likely caused by the incorrect assumption that AS was too high; right?
If a stall was being caused by too much AS, wouldn't there be other physical indications (wing shutter, nose over, etc.) to confirm this?
If a stall was being caused by too much AS, wouldn't there be other physical indications (wing shutter, nose over, etc.) to confirm this?
Join Date: Jul 2009
Location: USA
Age: 62
Posts: 28
Likes: 0
Received 0 Likes
on
0 Posts
ACARS
After spending two years looking at the ACARS messages there some questions I would like to ask the regulars that may be relevant---or not?
1. 2:12:51WRN/WN0906010212 341040006NAV ADR DISAGREE. It is my (probably incorrect) understanding that this message came earlier in other similar events. Is this late in the sequence here and not as a result of the initial problems but occurring at the apogee of the climb and 2nd stall?
2. In the new BEA note, why the first stall warnings at the initial event since stall is based on AoA?
3. 2:13:45WRN/WN0906010213 279002506F/CTL PRIM 1 FAULT and
2:13:51WRN/WN0906010213 279004006F/CTL SEC 1 FAULT
Obviously, not mentioned in the BEA note, were these then a result of failure and not shutdown?
1. 2:12:51WRN/WN0906010212 341040006NAV ADR DISAGREE. It is my (probably incorrect) understanding that this message came earlier in other similar events. Is this late in the sequence here and not as a result of the initial problems but occurring at the apogee of the climb and 2nd stall?
2. In the new BEA note, why the first stall warnings at the initial event since stall is based on AoA?
3. 2:13:45WRN/WN0906010213 279002506F/CTL PRIM 1 FAULT and
2:13:51WRN/WN0906010213 279004006F/CTL SEC 1 FAULT
Obviously, not mentioned in the BEA note, were these then a result of failure and not shutdown?
Guest
Posts: n/a
robert bartsch (and takata)
2h10m05s. Unreliable a/s.
This is an ACARS message, not a DFDR trace. Something was bollux with IAS in the cockpit to generate the maintenance entry into log.
Takata, you are assuming that ACARS report is real time, and by inference that ACARS reports simultaneously with fault. Impossible.
The Speeds were reported for time 'x' prior to loss of PRIM.
"So the nose-up input was likely caused by the incorrect assumption that AS was too high; right?"
"If a stall was being caused by too much AS, wouldn't there be other physical indications (wing shutter, nose over, etc.) to confirm this?"
Here, rb suggests the pilot may have alertly already responded to bunk data. The ACARS report a/p dropout first, not UAS. If the PF was aviating in Normal Law for a time certain prior to AD hash, his pull and roll would be indicated as correct. He could also manipulate the stick with impounity, and let the protections sort out life on the edge of Stall or wing drop.
Just because our Pilot responded to overspeed doesn't make him wrong.
Overspeed and turbulence may have killed the autopilot, instead of UAS. Although you have said that UAS is without question true.
2h10m05s. Unreliable a/s.
This is an ACARS message, not a DFDR trace. Something was bollux with IAS in the cockpit to generate the maintenance entry into log.
Takata, you are assuming that ACARS report is real time, and by inference that ACARS reports simultaneously with fault. Impossible.
The Speeds were reported for time 'x' prior to loss of PRIM.
"So the nose-up input was likely caused by the incorrect assumption that AS was too high; right?"
"If a stall was being caused by too much AS, wouldn't there be other physical indications (wing shutter, nose over, etc.) to confirm this?"
Here, rb suggests the pilot may have alertly already responded to bunk data. The ACARS report a/p dropout first, not UAS. If the PF was aviating in Normal Law for a time certain prior to AD hash, his pull and roll would be indicated as correct. He could also manipulate the stick with impounity, and let the protections sort out life on the edge of Stall or wing drop.
Just because our Pilot responded to overspeed doesn't make him wrong.
Overspeed and turbulence may have killed the autopilot, instead of UAS. Although you have said that UAS is without question true.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by robertbartsch
So the nose-up input was likely caused by the incorrect assumption that AS was too high; right?
b) First emergency signal was a "stall warning"... not overspeed.
c) PF initial reaction was contrary to a) & b)... unless those signals were duely ignored because of an unknown factor, or that he thought to be the right thing to do in response to a) and b)... and this could have been in case of CFIT alert in Normal law (except thrust settings, but TOGA should kick automatically by alpha_floor function). What make me think it could be an explanation is that it is also exactly what the PF did after the stall warning at 0210:51 (he manually applied TOGA and pitched up).
Originally Posted by robertbartsch
If a stall was being caused by too much AS, wouldn't there be other physical indications (wing shutter, nose over, etc.) to confirm this?
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi bear,
I knew it!... no surprise.
This doesn't fit with your own "theories" and you now need to make up few of those "facts".
Well, certainly not!
ACARS message are not displayed in realtime, they are stamped to the nearest minute.
There is 14 messages dispatched for 0210, all processed by the CMC between 0209:51 and 0210:50:
2:10:10 -.1/WRN/WN0906010210 221002006 AUTO FLT AP OFF
2:10:16 -.1/WRN/WN0906010210 226201006 AUTO FLT REAC W/S DET FAULT
2:10:23 -.1/WRN/WN0906010210 279100506 F/CTL ALTN LAW
2:10:29 -.1/WRN/WN0906010210 228300206 FLAG ON CAPT PFD SPD LIMIT
2:10:41 -.1/WRN/WN0906010210 228301206 FLAG ON F/O PFD SPD LIMIT
2:10:47 -.1/WRN/WN0906010210 223002506 AUTO FLT A/THR OFF
2:10:54 -.1/WRN/WN0906010210 344300506 NAV TCAS FAULT
2:11:00 -.1/WRN/WN0906010210 228300106 FLAG ON CAPT PFD FD
2:11:15 -.1/WRN/WN0906010210 228301106 FLAG ON F/O PFD FD
2:11:21 -.1/WRN/WN0906010210 272302006 F/CTL RUD TRV LIM FAULT
2:11:27 -.1/WRN/WN0906010210 279045506 MAINTENANCE STATUS EFCS 2
2:11:42 -.1/WRN/WN0906010210 279045006 MAINTENANCE STATUS EFCS 1
2:11:49 -.1/FLR/FR0906010210 34111506 EFCS2 1,EFCS1,AFS,,,,,PROBE-PITOT 1X2 / 2X3 / 1X3 (9DA),HARD
2:11:55 -.1/FLR/FR0906010210 27933406 EFCS1 X2,EFCS2X,,,,,,FCPC2 (2CE2) /WRG:ADIRU1 BUS ADR1-2 TO FCPC2,HARD
First message was recieved at 0210:10 (AP OFF).
The BEA note said that it disconnected at 0210:05 (from CVR "Alarm"/DFDR data AP status, I presume).
We know that it takes about 6 seconds to process an ACARS (due to protocole limitations).
This is obviously fully consistant with "everything started at 0210:05"... before this point, the flight was totally uneventful beside crew conversations about weather avoidance, small offset and speed reduction to Mach .80.
Now, if you want to absolutely shed the doubt by making up particular "events" prior to 0210:05, that's your call but not mine.
I knew it!... no surprise.
This doesn't fit with your own "theories" and you now need to make up few of those "facts".
Originally Posted by bearfoil
2h10m05s. Unreliable a/s.
This is an ACARS message, not a DFDR trace. Something was bollux with IAS in the cockpit to generate the maintenance entry into log.
Takata, you are assuming that ACARS report is real time, and by inference that ACARS reports simultaneously with fault. Impossible.
This is an ACARS message, not a DFDR trace. Something was bollux with IAS in the cockpit to generate the maintenance entry into log.
Takata, you are assuming that ACARS report is real time, and by inference that ACARS reports simultaneously with fault. Impossible.
ACARS message are not displayed in realtime, they are stamped to the nearest minute.
There is 14 messages dispatched for 0210, all processed by the CMC between 0209:51 and 0210:50:
2:10:10 -.1/WRN/WN0906010210 221002006 AUTO FLT AP OFF
2:10:16 -.1/WRN/WN0906010210 226201006 AUTO FLT REAC W/S DET FAULT
2:10:23 -.1/WRN/WN0906010210 279100506 F/CTL ALTN LAW
2:10:29 -.1/WRN/WN0906010210 228300206 FLAG ON CAPT PFD SPD LIMIT
2:10:41 -.1/WRN/WN0906010210 228301206 FLAG ON F/O PFD SPD LIMIT
2:10:47 -.1/WRN/WN0906010210 223002506 AUTO FLT A/THR OFF
2:10:54 -.1/WRN/WN0906010210 344300506 NAV TCAS FAULT
2:11:00 -.1/WRN/WN0906010210 228300106 FLAG ON CAPT PFD FD
2:11:15 -.1/WRN/WN0906010210 228301106 FLAG ON F/O PFD FD
2:11:21 -.1/WRN/WN0906010210 272302006 F/CTL RUD TRV LIM FAULT
2:11:27 -.1/WRN/WN0906010210 279045506 MAINTENANCE STATUS EFCS 2
2:11:42 -.1/WRN/WN0906010210 279045006 MAINTENANCE STATUS EFCS 1
2:11:49 -.1/FLR/FR0906010210 34111506 EFCS2 1,EFCS1,AFS,,,,,PROBE-PITOT 1X2 / 2X3 / 1X3 (9DA),HARD
2:11:55 -.1/FLR/FR0906010210 27933406 EFCS1 X2,EFCS2X,,,,,,FCPC2 (2CE2) /WRG:ADIRU1 BUS ADR1-2 TO FCPC2,HARD
First message was recieved at 0210:10 (AP OFF).
The BEA note said that it disconnected at 0210:05 (from CVR "Alarm"/DFDR data AP status, I presume).
We know that it takes about 6 seconds to process an ACARS (due to protocole limitations).
This is obviously fully consistant with "everything started at 0210:05"... before this point, the flight was totally uneventful beside crew conversations about weather avoidance, small offset and speed reduction to Mach .80.
Now, if you want to absolutely shed the doubt by making up particular "events" prior to 0210:05, that's your call but not mine.
Guest
Posts: n/a
takata
ami. "...AP, ATHR, flags on PFD, etc. all disconnected at 0210:05 due to unreliable airspeed processed by the PRIMs (Flight control computers)... this is the root cause of everything. The system switched to ALTERNATE LAW (PROT LOST) at this point because two or three pitots displayed a variation of airspeed above 30 Kt during one second. As this event lasted more than 10 seconds, ALTERNATE LAW would be definitive until the end of the flight, but autopilot and autothrust could have been re-engaged later if two calculated airspeed would be considered valid again by the PRIMs.
There is absolutely zero doubt that this is why AP went off..."
Everything never happens at once. If that were so, there would be no time. What happened prior to 2h10m05s to cause "..all disconnected at 2h10m05s?"
ami. "...AP, ATHR, flags on PFD, etc. all disconnected at 0210:05 due to unreliable airspeed processed by the PRIMs (Flight control computers)... this is the root cause of everything. The system switched to ALTERNATE LAW (PROT LOST) at this point because two or three pitots displayed a variation of airspeed above 30 Kt during one second. As this event lasted more than 10 seconds, ALTERNATE LAW would be definitive until the end of the flight, but autopilot and autothrust could have been re-engaged later if two calculated airspeed would be considered valid again by the PRIMs.
There is absolutely zero doubt that this is why AP went off..."
Everything never happens at once. If that were so, there would be no time. What happened prior to 2h10m05s to cause "..all disconnected at 2h10m05s?"
2. In the new BEA note, why the first stall warnings at the initial event since stall is based on AoA?
From 2 h 10 min 05 , the autopilot then auto-thrust disengaged and the PF said "I have the controls". The airplane began to roll to the right and the PF made a left nose-up input. The stall warning sounded twice in a row.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by bearfoil
Everything never happens at once. If that were so, there would be no time. What happened prior to 2h10m05s to cause "..all disconnected at 2h10m05s?"
Nothing before 0210:05.
And yes, at 0210:05, the speed function was simply invalidated by the PRIMs after a 1 second check out of its limit range... that's all!
It is all you need to have the following sequence of ACARS (and more).
- First dispatched: those are the cockpit effects (warnings) without failure.
- Root system failures are at the end of the ACARS list for the whole sequence: Pitots fault and this ADIRU faults.
CMC needed to crosscheck what systems caused the failures (internal, external, etc.) before dispatching the failure ACARS while cockpit effects are immediatly processed once they occured. The following time sequence is due to the protocole as the messages are queued and dispatched one by one. It will be clear from the DFDR tracks that all those warnings were basically simultaneous and that any delay in warning would be caused by priority order functions.
For example, there is a small delay between AP OFF and ATHR OFF because the later is retardated for not confusing both cockpit alarms sounding.
Join Date: Jul 2009
Location: France - mostly
Age: 84
Posts: 1,682
Likes: 0
Received 0 Likes
on
0 Posts
A tentative time-history of altitude and airspeed based on total energy is shown in this TEplot. Imagination mostly, of course, but more or less consistent with the datapoints in BEA's Update.
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
takata:
Very interesting point, if the PF was scanning the "gap" between MMO and speed more than absolute values he may well have perceived a jump in airspeed when ALTERNATe mode was entered rather than the drop in MMO.
Pity that one very relevant parameter (PF arispeed display) was not recorded on DFR.
On the other hand, switching to ALTERNATE would also reduce the MMO limit displayed on PFD down to Mach 0.82 (putting the limit much closer to their real airspeed)... hence, what if the pilot saw that gauge high limit moving close to its airspeed, if it was actually rightly displayed? Could he interpret the warning being an "overspeed" instead of "stall" (even if voiced)?.
Pity that one very relevant parameter (PF arispeed display) was not recorded on DFR.
Join Date: Jul 2009
Location: UK
Posts: 134
Likes: 0
Received 0 Likes
on
0 Posts
jcjeant...
Re my response to CONF's question about access to investigation information, you wrote:
Without going into too much unnecessary detail, I have a lot of experience with both Annex 13 and many of the State investigative agencies that are bound by its requirements (including BEA).
First, Annex 13 is not "just for the organization between states"; it is the document that States (including France) must comply with, as the basis for how to conduct investigations (supplemented or modified by State legislation and any differences filed with ICAO).
With specific reference to your statement about "who really have access to the data", BEA can, of course, include any other party they wish as part of the investigation. They can also release any portion of the data to any party they wish (an example might be a specialised psychologist to review and comment on crew voices under stress), in which case BEA would place confidentiality restrictions (as per Annex 13) on that person with regard to the information they have received.
Lastly, apart from the BEA investigation, there is a French legal investigation underway, and there will of course be other legal actions arising out of this accident. Who will have access to the CVR and DFDR data for those purposes is a matter for French (and possibly other State)courts.
Re my response to CONF's question about access to investigation information, you wrote:
It's just for the organization between states ..... it's not realy instructive about who have really access to the data .... IMHO
First, Annex 13 is not "just for the organization between states"; it is the document that States (including France) must comply with, as the basis for how to conduct investigations (supplemented or modified by State legislation and any differences filed with ICAO).
With specific reference to your statement about "who really have access to the data", BEA can, of course, include any other party they wish as part of the investigation. They can also release any portion of the data to any party they wish (an example might be a specialised psychologist to review and comment on crew voices under stress), in which case BEA would place confidentiality restrictions (as per Annex 13) on that person with regard to the information they have received.
Lastly, apart from the BEA investigation, there is a French legal investigation underway, and there will of course be other legal actions arising out of this accident. Who will have access to the CVR and DFDR data for those purposes is a matter for French (and possibly other State)courts.
Last edited by grizzled; 31st May 2011 at 17:36.