AF 447 Search to resume (part2)
for takata
With that mouthful digested after reading it thrice, I am curious:
What tools are provided the flight deck crew for inflight trouble shooting and remedy of this complex failure mode? QRH and ECAMS are two resources that seem obvious to me, are there others?
It is apparent to me that cues and warnings to the crew that something is amiss are available, but what is unclear to me is the immediacy of the prompt. (Compare to an engine low power alert, a chip detector alert, fire alert, low oil pressure alert, where immediacy is due to "on/off" threshold of a switch being met). {If you wish, use "warning" rather than "alert" in the above.}
From numerous posts, the average A330 aircrew are aware that airmass data can be wrong, even though correct airmass data is integral to the aircraft functioning properly and safely. (This is not an alarmist comment, as the average aircrew are also aware that the engines can go badly wrong, and power is integral to a passenger jet operating properly and safely).
What is unclear to me is whether or not this failure mode, airmass data to the pilot displays and the flight computer, is insidious, or "creeping up on you," in nature.
Can you help me understand?
To put this in context, a few decades ago the squadron I was in lost an aircraft (not the crew) thanks to an insidious fuel transfer problem going undetected for long enough for it to become a problem. The result was that fuel on board was not all usable. Once they were aware of the problem, they did their best to overcome this malfunction but ran out of gas before finding somewhere dry to land. Put another way, they were playing "catch up" once they were alert to the problem. (I operate under the feeling that AF 447's crew were playing "catch up", but Friday may prove me wrong).
for cogsim:
I agree with your false dilemma point, but am not comfortable with the "ignorance is bliss" state of the point preceeding it. The cold comfort of statistics is that the odds are that we can wallow in bliss on your (or my) next trip.
Fact#3: Emphasis was also put on the crew training for detecting any possible Air data issues ; the fact is that possible Air data issues must be, in any case, monitored in flight because there is plenty of different cases following various "contaminations" of an anemometric chain.
This is not a single case issue with a single procedure to follow as it is too complex to indentify correctly what is causing those Air data to be unreliable at the first place.
This is not a single case issue with a single procedure to follow as it is too complex to indentify correctly what is causing those Air data to be unreliable at the first place.
What tools are provided the flight deck crew for inflight trouble shooting and remedy of this complex failure mode? QRH and ECAMS are two resources that seem obvious to me, are there others?
It is apparent to me that cues and warnings to the crew that something is amiss are available, but what is unclear to me is the immediacy of the prompt. (Compare to an engine low power alert, a chip detector alert, fire alert, low oil pressure alert, where immediacy is due to "on/off" threshold of a switch being met). {If you wish, use "warning" rather than "alert" in the above.}
From numerous posts, the average A330 aircrew are aware that airmass data can be wrong, even though correct airmass data is integral to the aircraft functioning properly and safely. (This is not an alarmist comment, as the average aircrew are also aware that the engines can go badly wrong, and power is integral to a passenger jet operating properly and safely).
What is unclear to me is whether or not this failure mode, airmass data to the pilot displays and the flight computer, is insidious, or "creeping up on you," in nature.
Can you help me understand?
To put this in context, a few decades ago the squadron I was in lost an aircraft (not the crew) thanks to an insidious fuel transfer problem going undetected for long enough for it to become a problem. The result was that fuel on board was not all usable. Once they were aware of the problem, they did their best to overcome this malfunction but ran out of gas before finding somewhere dry to land. Put another way, they were playing "catch up" once they were alert to the problem. (I operate under the feeling that AF 447's crew were playing "catch up", but Friday may prove me wrong).
for cogsim:
Realistically, we (as pilots) don't know anything about the hairy situations that were successfully negotiated by computers. And somewhere in there lies the paradox setup by the false dilemma of "either computer or human" type thinking.
Last edited by Lonewolf_50; 26th May 2011 at 17:16.
Join Date: Feb 2008
Location: Ann Arbor, MI
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
Maybe the pitot tubes clog up somewhat symmetrically, so before they disagree they all report a massive increase in airspeed.
The autopilot pitches the airplane up sharply, then the sensors disagree, and dump the whole mess into the laps of the pilots, dropping stall protection at the same time.
Maybe that's the case, maybe it isn't, and the pilots pitched the airplane up. But if it was the autopilot:
My question is, why doesn't the software realize, especially when in cruise, that pitch and power haven't changed much, GPS altitude is relatively stable, that a big increase in airspeed is simply illogical?
I'll back ADA as a strong programming language. It helps prevent PROGRAMMING errors, syntax errors, buffer overruns and such.
No matter what the programming language is, though, it doesn't prevent otherwise correctly coded software that has errors in human logical thinking. If the software isn't written to identify such a situation and fall back to a pitch and power mode on its own, then it simply won't happen.
The autopilot pitches the airplane up sharply, then the sensors disagree, and dump the whole mess into the laps of the pilots, dropping stall protection at the same time.
Maybe that's the case, maybe it isn't, and the pilots pitched the airplane up. But if it was the autopilot:
My question is, why doesn't the software realize, especially when in cruise, that pitch and power haven't changed much, GPS altitude is relatively stable, that a big increase in airspeed is simply illogical?
I'll back ADA as a strong programming language. It helps prevent PROGRAMMING errors, syntax errors, buffer overruns and such.
No matter what the programming language is, though, it doesn't prevent otherwise correctly coded software that has errors in human logical thinking. If the software isn't written to identify such a situation and fall back to a pitch and power mode on its own, then it simply won't happen.
Join Date: Jul 2009
Location: Planet Earth
Posts: 91
Likes: 0
Received 0 Likes
on
0 Posts
I agree with your false dilemma point, but am not comfortable with the "ignorance is bliss" state of the point preceeding it. The cold comfort of statistics is that the odds are that we can wallow in bliss on your (or my) next trip.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi Lonewolf,
Well no QRH/ECAMS.... as it depends on conditions and are flight phase related:
Cross-checking of all instruments (various displays), GPS ground speed, Radio Alt, airflow sound on airframe, thrust setting in relation with air data, autothrust erratic behavior, etc.
The first step is to identify if the system may have been fooled and turn off any ADR if they seem unreliable (but to keep one, even wrong, for still having the Stall warning).
Next is ECAM troubleshooting. Read again those PJ2 posts as he already described the process many times.
Originally Posted by Lonewolf_50
What tools are provided the flight deck crew for inflight trouble shooting and remedy of this complex failure mode? QRH and ECAMS are two resources that seem obvious to me, are there others?
Cross-checking of all instruments (various displays), GPS ground speed, Radio Alt, airflow sound on airframe, thrust setting in relation with air data, autothrust erratic behavior, etc.
The first step is to identify if the system may have been fooled and turn off any ADR if they seem unreliable (but to keep one, even wrong, for still having the Stall warning).
Next is ECAM troubleshooting. Read again those PJ2 posts as he already described the process many times.
takata, #2450
Hi,
Thanks for the reply.
I thought you were perhaps being a bit paranoid, but yes, there are
always those in life who do little but try to find fault and apportion
blame. Iirc, others have said, the A330 has a decade or more of impeccable
safety record, so there can be nothing fundamentally wrong with it.
If airbus make recommendations to customers that they then choose to
ignore, or drag their feet in implementation, then it's clear who is
at fault. Perhaps part of the problem is that there is not enough
regulatory involvement. A recommendation is, after all, not a legal
requirement.
I'm not so clear about the second part of Fact3 paragraph, which, no
disrespect intended, looks a bit smoke and mirrors. Irrespective
of how complex such problems are, they *all* need to be identified,
together with a defined procedure to allow the crew to recover from the
situation. Anything alse is just dodging the issue. Perhaps this has
been done and is being ignored by the airlines in terms of training,
but not enough data here to comment on that.
The probe icing problem still nags though, one of the failure
modes of your "too complex" set and the first and critical link in so
many parts of the system. Looking in from outside, it really does
amaze me that this has been allowed to drag on for so long. As an insider,
perhaps you could comment on the reasons for this ?. Irrespective
of how serious the problem is in reality, fixing that would be one fewer
item to cause trouble and one more step towards the goal of "zero defects".
There's a good systems reason to fix it. While it's easy to design a system
that only ever gets fed good data, the software overhead involved
in trapping and recovering from bad data can be considerable and complex
in itself. Thus, more likely to have hidden faults in implementation. This
means that any primary data source has the added responsibility to ensure
unambiguous output at all times. That is, the data is always within expected
limits, or a clear error signal generated. Of course it doesn't absolve
the data consumers of the responsibility of doing their own checks, but
it's one less thing to have to deal with. In essence, it's better not to to
have to deal with errors in the first place. Better if they can be
designed / engineered out...
Hi,
Thanks for the reply.
I thought you were perhaps being a bit paranoid, but yes, there are
always those in life who do little but try to find fault and apportion
blame. Iirc, others have said, the A330 has a decade or more of impeccable
safety record, so there can be nothing fundamentally wrong with it.
If airbus make recommendations to customers that they then choose to
ignore, or drag their feet in implementation, then it's clear who is
at fault. Perhaps part of the problem is that there is not enough
regulatory involvement. A recommendation is, after all, not a legal
requirement.
I'm not so clear about the second part of Fact3 paragraph, which, no
disrespect intended, looks a bit smoke and mirrors. Irrespective
of how complex such problems are, they *all* need to be identified,
together with a defined procedure to allow the crew to recover from the
situation. Anything alse is just dodging the issue. Perhaps this has
been done and is being ignored by the airlines in terms of training,
but not enough data here to comment on that.
The probe icing problem still nags though, one of the failure
modes of your "too complex" set and the first and critical link in so
many parts of the system. Looking in from outside, it really does
amaze me that this has been allowed to drag on for so long. As an insider,
perhaps you could comment on the reasons for this ?. Irrespective
of how serious the problem is in reality, fixing that would be one fewer
item to cause trouble and one more step towards the goal of "zero defects".
There's a good systems reason to fix it. While it's easy to design a system
that only ever gets fed good data, the software overhead involved
in trapping and recovering from bad data can be considerable and complex
in itself. Thus, more likely to have hidden faults in implementation. This
means that any primary data source has the added responsibility to ensure
unambiguous output at all times. That is, the data is always within expected
limits, or a clear error signal generated. Of course it doesn't absolve
the data consumers of the responsibility of doing their own checks, but
it's one less thing to have to deal with. In essence, it's better not to to
have to deal with errors in the first place. Better if they can be
designed / engineered out...
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
This message, transmitted by the FCDC2 (EFCS2), means that the FCPCs (or
PRIMs) triggered one of the speed monitoring processes: they have detected
a decrease of more than 30 kt in one second of the “polled” speed value
As I read it, the computers will tolerate a transient (<10 seconds) period of dodgy values and revert back to normal if everything comes back into line - but if the values stay out of expected range, you are in alternate law etc for rest of the flight. Note that the BEA use the phrase "one of the speed monitoring processes" - which implies to me that there are other cross-checking processes as well as this one.PRIMs) triggered one of the speed monitoring processes: they have detected
a decrease of more than 30 kt in one second of the “polled” speed value
One thing we might find out tomorrow is whether the pitots failed in a way that slipped through this monitoring - maybe a symettrical and gradual speed increase or decrease - leading the plane to be already doing the wrong thing by the time the fault is detected.
Well no QRH/ECAMS.... as it depends on conditions and are flight phase related:
---
Next is ECAM troubleshooting. Read again those PJ2 posts as he already described the process many times.
---
Next is ECAM troubleshooting. Read again those PJ2 posts as he already described the process many times.
Cross-checking of all instruments (various displays), GPS ground speed, Radio Alt, airflow sound on airframe, thrust setting in relation with air data, autothrust erratic behavior, etc.
The first step is to identify if the system may have been fooled and turn off any ADR if they seem unreliable (but to keep one, even wrong, for still having the Stall warning).
I'll review what PJ2 has said again, with your points in mind, and see what shakes loose.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Chris,
I have stricly no whatsoever connection with Airbus, Thales, AF, investigation (or anybody else interests in this story) as I'm investigating it for my own personal account in relation with human-machine interfaces and ergonomy issues.
Originally Posted by syseng68k
As an insider, perhaps you could comment on the reasons for this ?
3holelover;
First, thank you for your moderate and patient response, and the opportunity to respond.
No, I did not mean or intend the post to sound and read as it did. It was too blunt. The post is deleted.
My point, I think, has been badly misunderstood because I have not explained it very well. Too much in a hurry and too little time to write well while on vacation....I should just take my wife's advice, and after this last post, I am going to!
I've read the document describing the Air Caraibe incident. I read (and re-read) the Airbus FCOM Bulletin posted by Takata, (since updated as A330 FCOM Bulletin #810/1, June, 2004). I have read extensively in the A332 AMM, in several Flight Crew Training Manuals regarding the SOPs for handling a loss of airspeed and/or altitude data. I've flown the 'bus since 1992 and instructed on the airplane and flown the A330/A340 since 1999. I have done a number of scenarios in a Level D A330 simulator. Like everyone, I am trying to understand how the accident happened.
There are 36 previous pitot events described in the BEA's Second Interim Report, Appendix 7.
I understand very well that once known, potential risks must be mitigated. My comments are not to be mistaken for an insensitivity to this primary requirement.
There is a history (of pitot problems) here but as has been eloquently pointed out by John Tullamarine and others, there are always changes underway which address issues raised in-service.
I think it is reasonable to assume that the software on this aircraft is not what it was when first introduced. I don't think such a process is nefarious. At the same time, I am aware of the controversies. The issue is well-discussed by a number of posters here.
I am also more than keenly aware of hindsight bias and am concerned that many of the comments which claim that "action was not taken" are based in such bias.
The view that the flight controls and computers were, though such an event is demonstrably, exceedingly rare, were a "trap" for pilots, is simply too facile, and I simply do not believe that this is the case, in isolation from other possible factors.
Further, 36 previous events did not result in an accident and the logical question to ask therefore is, Why here?
So...how to discuss the accident within such a context, without conveying the the impression that, "if not the flight control computers, then the pilots"?
In my clumsy and rushed way, I did, and now have deleted the post. But that doesn't alleviate the question that all investigators (I am not an accident investigator, btw), would ask...How did this happen and why? What can and must be changed to prevent such a reoccurrence?
I do not make the connection, "if not the computers, then the pilots". Even if the immediate causes are simple, the causal complexity of this accident is deeper and the lessons more important than "handing this accident to the crew".
The risk in talking about all causal pathways including human factors is just this. Rather than elaborate further at this point, I think it is best just to leave it there.
No offence taken - quite the contrary.
First, thank you for your moderate and patient response, and the opportunity to respond.
No, I did not mean or intend the post to sound and read as it did. It was too blunt. The post is deleted.
My point, I think, has been badly misunderstood because I have not explained it very well. Too much in a hurry and too little time to write well while on vacation....I should just take my wife's advice, and after this last post, I am going to!
I've read the document describing the Air Caraibe incident. I read (and re-read) the Airbus FCOM Bulletin posted by Takata, (since updated as A330 FCOM Bulletin #810/1, June, 2004). I have read extensively in the A332 AMM, in several Flight Crew Training Manuals regarding the SOPs for handling a loss of airspeed and/or altitude data. I've flown the 'bus since 1992 and instructed on the airplane and flown the A330/A340 since 1999. I have done a number of scenarios in a Level D A330 simulator. Like everyone, I am trying to understand how the accident happened.
There are 36 previous pitot events described in the BEA's Second Interim Report, Appendix 7.
I understand very well that once known, potential risks must be mitigated. My comments are not to be mistaken for an insensitivity to this primary requirement.
There is a history (of pitot problems) here but as has been eloquently pointed out by John Tullamarine and others, there are always changes underway which address issues raised in-service.
I think it is reasonable to assume that the software on this aircraft is not what it was when first introduced. I don't think such a process is nefarious. At the same time, I am aware of the controversies. The issue is well-discussed by a number of posters here.
I am also more than keenly aware of hindsight bias and am concerned that many of the comments which claim that "action was not taken" are based in such bias.
The view that the flight controls and computers were, though such an event is demonstrably, exceedingly rare, were a "trap" for pilots, is simply too facile, and I simply do not believe that this is the case, in isolation from other possible factors.
Further, 36 previous events did not result in an accident and the logical question to ask therefore is, Why here?
So...how to discuss the accident within such a context, without conveying the the impression that, "if not the flight control computers, then the pilots"?
In my clumsy and rushed way, I did, and now have deleted the post. But that doesn't alleviate the question that all investigators (I am not an accident investigator, btw), would ask...How did this happen and why? What can and must be changed to prevent such a reoccurrence?
I do not make the connection, "if not the computers, then the pilots". Even if the immediate causes are simple, the causal complexity of this accident is deeper and the lessons more important than "handing this accident to the crew".
The risk in talking about all causal pathways including human factors is just this. Rather than elaborate further at this point, I think it is best just to leave it there.
No offence taken - quite the contrary.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Lonewolf_50
Roger, but what is the cue that gets you disbelieving your airmass data in the first place?
Alerts are supposed to catch their attention only if their situation awareness is low because they are distracted by something else.
PJ2/takata
From one of PJ2's posts in the past.
1. If the "alert" I was asking about is this abrupt pitch command, then takata's response does not satisfy. This goes back to basic upset and UA training, a different road we've traveled more than once in this thread.
EDIT:
takata, if I may misquote Sir Joseph Porter, KCB, pray don't try to patronize me.
Given the hours I spent teaching instrument flying, thanks so much for that.
Uh, no.
A key function of a cockpit alert is to inform the pilot of a change of state beyond normal, set, or expected parameters. See my mentioning a chip light up there, or a fire warning light. That isn't a matter of a distracted pilot not monitoring the internal gears or the firewall, it is a matter of identifying a condition that may require immediate attention beyond normal scan and activity. (I have typically seen alerts are coded with different colors, to help with "immediate" or "pretty soon" or "we can take our time with this one" classes of malfunctions, but that will vary with platform and design philosophy.)
Sometimes, its a small "Off" flag on a radio instrument. Other times, a blinking light.
Tell me, do you design applications related to ergonimics?
2. AD assumption seems to be that previous FM's were deficient.
3. I'll let it go at that.
EDIT: interesting patent description, for those interested, per the link alluded to a few posts up, about a back up system.
United States Patent Application: 0110071710
From one of PJ2's posts in the past.
As we are aware, the AD that was released on December 22, 2010 states,
"However, in some cases, the autopilot orders may be inappropriate, such as possible abrupt pitch command.
In order to prevent such event which may, under specific circumstances, constitute an unsafe condition, this AD requires an amendment of the Flight Manual to ensure that flight crews apply the appropriate operational procedure."
"However, in some cases, the autopilot orders may be inappropriate, such as possible abrupt pitch command.
In order to prevent such event which may, under specific circumstances, constitute an unsafe condition, this AD requires an amendment of the Flight Manual to ensure that flight crews apply the appropriate operational procedure."
EDIT:
takata, if I may misquote Sir Joseph Porter, KCB, pray don't try to patronize me.
IMC Flight: pilots are supposed to watch their instruments and notice any change of monitored values which are all related to each others: temperature, altitude, airspeed, pitch, thrust... even to ear or feel "how" they are flying (turbulence, buffet...) and have a good feeling if everything looks ok or if something is turning wrong.
Alerts are supposed to catch their attention only if their situation awareness is low because they are distracted by something else.
A key function of a cockpit alert is to inform the pilot of a change of state beyond normal, set, or expected parameters. See my mentioning a chip light up there, or a fire warning light. That isn't a matter of a distracted pilot not monitoring the internal gears or the firewall, it is a matter of identifying a condition that may require immediate attention beyond normal scan and activity. (I have typically seen alerts are coded with different colors, to help with "immediate" or "pretty soon" or "we can take our time with this one" classes of malfunctions, but that will vary with platform and design philosophy.)
Sometimes, its a small "Off" flag on a radio instrument. Other times, a blinking light.
Tell me, do you design applications related to ergonimics?
2. AD assumption seems to be that previous FM's were deficient.
3. I'll let it go at that.
EDIT: interesting patent description, for those interested, per the link alluded to a few posts up, about a back up system.
United States Patent Application: 0110071710
Last edited by Lonewolf_50; 26th May 2011 at 18:07.
Join Date: Jun 2009
Location: Florida
Age: 60
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
Surprised to see that no one has reported on the "leak" on France Info this morning - I was listening to the radio on the way to work. They claimed to have some inside info on what will be announced by the BEA tomorrow. In brief:
- yes the pitots iced up, the flight computers gave up and passed the control to the pilots;
- yes the a/c stalled but (as you'd expect!) the crew then correctly applied the textbook approach to deal with the stall but this did not work;
- yes the captain had briefly left the cockpit but was back in the cockpit for the critical part of the incident.
The article suggested that the incident was as yet inexplicable given current state of the investigation, and concluded that major conclusions would have to be drawn by the industry with regard to contingency procedures, training, system certification, high altitude aerodynamics and more.....
What I found interesting and reassuring was the avoidance of kneejerk reaction blaming just the crew - guess we'll hear whether their leak is correct tomorrow. You can hear the article at the link below - note that they say the more interesting things in the audio stream compared to the written synopsis.
Vol Rio-Paris : le BEA s'apprête à rendre publique une note sur les circonstances de l'accident - international - toute l'actualité internationale - France Info
- yes the pitots iced up, the flight computers gave up and passed the control to the pilots;
- yes the a/c stalled but (as you'd expect!) the crew then correctly applied the textbook approach to deal with the stall but this did not work;
- yes the captain had briefly left the cockpit but was back in the cockpit for the critical part of the incident.
The article suggested that the incident was as yet inexplicable given current state of the investigation, and concluded that major conclusions would have to be drawn by the industry with regard to contingency procedures, training, system certification, high altitude aerodynamics and more.....
What I found interesting and reassuring was the avoidance of kneejerk reaction blaming just the crew - guess we'll hear whether their leak is correct tomorrow. You can hear the article at the link below - note that they say the more interesting things in the audio stream compared to the written synopsis.
Vol Rio-Paris : le BEA s'apprête à rendre publique une note sur les circonstances de l'accident - international - toute l'actualité internationale - France Info
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Lonewolf_50
1. If the "alert" I was asking about is this abrupt pitch command, then takata's response does not satisfy. This goes back to basic upset and UA training, a different road we've traveled more than once in this thread.
2. AD assumption seems to be that previous FM's were deficient.
3. I'll let it go at that.
2. AD assumption seems to be that previous FM's were deficient.
3. I'll let it go at that.
1) AP kicked off whith ADR faults without a single ADR previously rejected (it would take a double probe simultaneous failure to fool the system).
2) It could not have been re-engaged later because this fault was never cleared until before impact (RTL).
Join Date: Mar 2009
Location: S23W046
Age: 73
Posts: 57
Likes: 0
Received 0 Likes
on
0 Posts
..........alerteness
@Takata
Are you a pilot? From your location Toulouse one could think you are just lobbying for AI.
How do you spell alerteness? During 11 hours?
If one imagine the situation: crossing the ITC possibly concentrated not to hit one of the bigger red things on the screen, when all of a sudden a lot of chimes alerts and so on went off...
Lets wait for the BEA rep tomorrow....
Are you a pilot? From your location Toulouse one could think you are just lobbying for AI.
How do you spell alerteness? During 11 hours?
If one imagine the situation: crossing the ITC possibly concentrated not to hit one of the bigger red things on the screen, when all of a sudden a lot of chimes alerts and so on went off...
Lets wait for the BEA rep tomorrow....
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
STALL WARNING during more than three (3) minutes
JE NE COMPRENDS RIEN said one pilot
Let's see what the BEA will reveal tomorrow ... ?
Thanks for the link Porker.
JE NE COMPRENDS RIEN said one pilot
Let's see what the BEA will reveal tomorrow ... ?
Thanks for the link Porker.
Last edited by CONF iture; 26th May 2011 at 18:37.
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
Hi,
More in Liberation newspaper: (judiciary experts comments)
AF447: un rapport d'experts met en cause Airbus et Air France - Libération
The written report
rapport d'expertise Rio-Paris
I let you make the translation ...........
More in Liberation newspaper: (judiciary experts comments)
AF447: un rapport d'experts met en cause Airbus et Air France - Libération
The written report
rapport d'expertise Rio-Paris
I let you make the translation ...........
Last edited by jcjeant; 26th May 2011 at 19:20.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi Flyinheavy,
point 1.
point 2.
Can't you see a paradoxe here between 1 & 2?
No PF is flying an 11 hours leg. What is he supposed to do, then at cruise, at night, in weather avoidance mode, with AP and ATHR, beside monitoring his flight intruments?
What about some task sharing for this radar tilting and cb avoidance? are you flying alone, sir?
IMC: Instrument meteorological conditions (IMC) is an aviation flight category that describes weather conditions that require pilots to fly primarily by reference to instruments...
Doesn't it sound more than adequate for ITC crossings? or maybe are you suggesting me that it would take them 11 hours to cross it? Beside, they were in the first third of the flight (3 hours+) and the PF has already been relieved.
"when all of a sudden a lot of chimes alerts and so on went off."
Here is your single and very valid point: surprise, noise, stress... bad documentation, bad "crisis" ergonomy, bad training as not realisticaly or specifically adressed.... we'll see.
Experience return: I'm pretty sure, after AF447, that the general situation awareness has steeply increased for all the crews flying in similar conditions, whaterver their company or aircraft model.
do you think that all the people living in Washington DC. are potential lobyists for Obama administration?
Originally Posted by Flyinheavy
How do you spell alerteness? During 11 hours?
Originally Posted by Flyinheavy
If one imagine the situation: crossing the ITC possibly concentrated not to hit one of the bigger red things on the screen, when all of a sudden a lot of chimes alerts and so on went off...
Can't you see a paradoxe here between 1 & 2?
No PF is flying an 11 hours leg. What is he supposed to do, then at cruise, at night, in weather avoidance mode, with AP and ATHR, beside monitoring his flight intruments?
What about some task sharing for this radar tilting and cb avoidance? are you flying alone, sir?
IMC: Instrument meteorological conditions (IMC) is an aviation flight category that describes weather conditions that require pilots to fly primarily by reference to instruments...
Doesn't it sound more than adequate for ITC crossings? or maybe are you suggesting me that it would take them 11 hours to cross it? Beside, they were in the first third of the flight (3 hours+) and the PF has already been relieved.
"when all of a sudden a lot of chimes alerts and so on went off."
Here is your single and very valid point: surprise, noise, stress... bad documentation, bad "crisis" ergonomy, bad training as not realisticaly or specifically adressed.... we'll see.
Experience return: I'm pretty sure, after AF447, that the general situation awareness has steeply increased for all the crews flying in similar conditions, whaterver their company or aircraft model.
do you think that all the people living in Washington DC. are potential lobyists for Obama administration?
You'll let it here because you are not interested
at looking further than a FBW induced upset.
Now, there are already some pretty good clues that AP did not order a pitch up and was possibly never fooled.
Note: what has been discussed in this thread is that in some previous Unreliable Airspeed incidences, there were pitch up, but not in all. My point on "alerts" is that if your "alert" is the pitch up, you are already behind the aircraft ... which is an ergonomics and systems design issue when you have a known issue (back to 1999 at least ...) If there were other alerts, that is what remains unclear to me. If in this case the pitch up of some other incidents wasn't a symptom, ... we'll find out soon enough.
takata, do you understand how to stall an aircraft?
The scenario looks to have been open to more than one path to that destination. You will I am sure explain the stall in your own words. There are reasons one enters turbulent air in a restricted window of airspeeds. (model dependent)
1) AP kicked off whith ADR faults without a single ADR previously rejected (it would take a double probe simultaneous failure to fool the system).
2) It could not have been re-engaged later because this fault was never cleared until before impact (RTL).
2) It could not have been re-engaged later because this fault was never cleared until before impact (RTL).
I am pretty sure that you don't understand what I am asking, and I am also not sure that I am asking clearly enough.
EDIT:
Conf iture ..
STALL WARNING during more than three (3) minutes
JE NE COMPRENDS RIEN said one pilot
JE NE COMPRENDS RIEN said one pilot
"I don't understand this thing (that thing?)"
Am I close?
Last edited by Lonewolf_50; 26th May 2011 at 19:33.