Away for a couple of days and catching up, but the above just about sums up my gut feelings as well. This problem has been known about for years, with fwics, many examples of uas causing at very minimum, added crew workload and stress. I know change in aviation is glacial, but this problem should have been fixed as a regulatory requirement years ago.

Have been trying to think of a suitable analogy, so how about this:

Buying a new car from the showroom, salesman tells you how good and reliable the car is, but then tells you that when it's very cold, there's an intermittent fault that causes the headlights and instruments to fail. It usually only happens for a short period, but could cause a serious accident if the car is travelling at speed. The manufacturers have been trying to correct the fault for some time, but with no success. The advice is therefore, not to travel at more than 20mph at night. Does anyone think that such a vehicle would be allowed to be sold anywhere ?...

I think sometimes you need a sense of the surreal to put things into perspective...

sensor_validation
 

Well I agree that from Airbus engineers point of view double or triple Pitot's failure is a very low probability event. My university used to deal with "aircrafts" going out of the atmosphere and then back in, so Pitot's were one of the many sensors allowing computer to integrate positions and speed. And cross checking was a must. Remember this knowlege was around from 12 April 1961 and culminated by Russian space shuttle flown 100% by on-board computers.

Very sad that we paid such big price for engineering mistake or in fact "overseeing" the probability of failure being not so low. For example bird strike coud give the same result for all three tubes, since birds do fly in formations (flocks).

Block pitots - back to basics
 

Thinking out loud....

Ok, so a pitot in it's simplest form is a tube facing into the 'liquid' flow, such that the resulting pressure can be measured with a transducer (diaphragm). At a constant (fixed) altitude that's all you need to measure 'speed' (once calibrated). However the measured pressure is a function of two components - there is a static component to the pressure (effectively due to the mass of the column of air pressing down on the diaphragm) and the dynamic component due to movement (effectively the additional pressure due to more air molecules pressing on the diaphragm). So if the thing that needs it's speed measured can change altitude, then we need to measure both dynamic and static pressure, and subtract the later from the former to derive speed irrespective of altitude. So far so good? (Please excuse the layman-esque language, but longer words make my head ache).

Alrighty then... so all's well and good until something blocks the dynamic tube - moisture, bees, ice, whatever - bad things happen.

Considering moisture - water - pretty common on Earth, so what's the solution - drain holes. Now this is where I need some help. Obviously the drain holes MUST be significantly smaller than the inlet port (otherwise there would be no pressure to measure - all the air would flow out the 'drain'...), so in normal operation we have air entering the inlet port and some portion of that flow exiting the drain? Clearly it is possible to calibrate the sensor to compensate for this, so the speed measurement still occurs.

However, block the inlet (ice), with the drain still open and the pressure will drop to static (indicated speed will decrease, at the limit to zero). My assumption is this is the failure mode we are discussing? (Since a blocked DRAIN alone will cause the speed to over-read).

My thought is this - in BOTH malfunction cases the flow inside the pitot has stopped at least through the drain - so why not include a mass-flow sensor right there in the drain outlet? Can we compare the GPS/INS derived speed to the pitot derived output and cross-check this with the mass-flow value, and figure out if we have a sensor problem? If our GPS ground speed is 400 knots and the pitot IAS is 80knots, with mass-flow derived value of 0 then there's a problem? I am presuming that pitot icing occurs fairly rapidly.

Am I oversimplifying?

- GY

If you view an accident as a series of links in a chain, or a series of holes in slices of cheese - whichever one prefers - surely the elimination of any link, or hole, is a valuable goal. Granted, we do NOT know yet, but we obviously have good reason to believe that UAS was a contributing factor here. Yes, we could view that as something that "should" have been little more than another snag in the book for the makers of the pitot probes to ponder as they look toward eventual corrective actions... but the truth is, in this case, that may well have been a single link which, if it hadn't occurred, would have meant this conversation wouldn't be happening (and a ship load of trusting souls would still be alive!)

I know UAS alone should not have led to this result. ...but then, neither should a fuel leak in one engine have led to all tanks empty.... but it did, and the fuel leak should never have occurred. ...and, I feel just as strongly, airspeed indication should never be unreliable.

Thankfully, very soon we'll know much more.

I hope I'm not getting under your skin.:ouch:

Cheers,
3hl

I like simple. Nomenclature is a challenge, it was ever so. On either side of an event, I see two bookends. One is "Proximal" cause, ie engine spool down, the other is "procuring cause", cold soaked fuel in China.

In between are fuel supply architecture, spar valve actions, low and high pressure pumps, SOPs, and a flawed design re: Heat exchanger and spill circuitry.

I have never liked the cheese hole theory, it makes me hungry and I get distracted.

I am one hundred per cent on board wih PJ2. When one says "It was not the pitots", one expects a little slack. Given the 17 year history of A330 and a "gazillion miles", and the unfortunate smoking gun of poor crisis management in dependability, by now, don't we know what we mean ?


:ok:

Hi, jcjeant,
Please, do not quote from any "sources" whithout also providing a link or a credit for your quotes. Also, in past posts, you should refrain from posting translated French press articles into English using auto-translation (everybody can do it himself, but the end result is most of the time meaningless).

Of course, one could certainly point that what you have posted above is far from an "objective" point of view about those probes issues but, as it seems to comfort you and few others into your Airbus consipiracy feelings, please, go ahead but you should certainly include the source where it comes from.
S~
Olivier

takata

"...Please, do not quote from any "sources" whithout also providing a link or a credit for your quotes. Also, in past posts, you should refrain from posting translated French press articles into English using auto-translation (everybody can do it himself, but the result is most of the time totally meaningless).

Of course, one could certainly point that what you have posted above is far from an "objective" point of view about those probes issues but, as it seems to comfort you and few others into your Airbus consipiracy feelings, please, go ahead but you should include the source where it comes from.
S~
Olivier ...."


"Conspiracy" is a volatile word, and unfortunately has acquired the status (Urban) of instigating severe reactions. It is a crime, a serious felony, depending on INTENT. A Board projecting profit lines for the next quarter with proprietary data are 'conspiring' to succeed.

INTENT is perhaps the squishiest word on the Planet, yet the basis for virtually all of our Law. If the plan is to avoid or circumvent the regulations it may be borderline chargeable. If it is blatant, void of consideration of "Duty of Care", it may be criminal.

Hunched together at either end of the spectrum, nothing is gained, certainly not progress, by expecting great loads of intelligent thought to disappear upon the utterance of a word.

It is a tactic, nothing more.

bear

Hi Bear,
Well, I've also read a few late posts from you in the R&N thread where you mentioned (as a fact) that AF447 lost also Inertial References (horizon, attitude, etc.).
Hence, as your high morale stance may be sincerly doubted and those garbagistic uterly farcicalious numerous posts in the vein of the above are suggesting to me is that you are simply using your own proved "tactic, nothing more".
"Diffame, diffame, et diffame encore... il en restera toujours quelque chose d'utile à la fin !"

takata, #2437

Sorry, but I didn't get any feeling of "conspiracy" from any part of the post you were discussing, or any problem with the translation. The point of it, afaics, was to illustrate that the problem is real and has been known about for quite a long time. If we clear away the bs, politics, bean counting, weasel words and excuses, we are still left with a failing that can have serious consequences.

If you think that this is not the case, then please explain...

Regards,

Chris

Last dance and philosophy
 

Salute all!

A huge attaboy for the post by Sv concerning philosophy.

This shall be my last post on the matter until we all dissect the AF/BEA/Airbus folks' interpretation of the accident. I also thank all here for their nice comments ( a degree of acceptance amongst a group of "heavy" pilots, although I never flew a "heavy") and hope I have added to a technical understanding of FBW designs, design philosophy and corrections to both design and pilot procedures when unexpected situations are encountered that the design folks or pilots had not allowed for, however remote.

This is what got my attention from Sv:

That quote embodies the most profound thoughts I have seen on this topic. In short, rules to live by.

I am a "dinosaur" according to many. But I am an enlightened dinosaur. I moved up through the technological improvements in our jets gladly. I accepted the new capabilities and the new limitations on my superior aviating skills, heh heh. Most of all, I got to see problems and solutions along the way. Neither the pilots nor the designers were perfect. But both groups admitted it, and we sought and implemented solutions to prevent future accidents and to "improve" aircraft capabilities.

The last thing we did was tell the designers we didn't know that their jet could enter into an unrecoverable deep stall. The designers didn't tell us, "well, Gums, what in the hell were you thinking pointing the nose up at 80 degrees and not pulling down before the airspeed go too slow for the elevators to work?".

Later, when we found that our quad-redundant flight control computers and sensors went off-line due to a single-point-failure in the power supply system, we were livid!!! At the interim accident briefing our Wing CO came outta his seat and we had to hold him back before he punched out the GD briefer. Did the GD folks balk? No, they developed a better power supply system and we flew with a kludge, hot-wired-to-aircraft battery system for a year or so.

I don't see this with the Airbus folks. Sorry. I also do not comprehend an aircraft designed to fly at the "edge of the envelope" or all bets are off and we hand off the plane to the crew. Hal says, " I do not understand what is happening, Dave, you have the stick", GASP!

Instead of the swiss cheese model, bear, may I suggest "the links in the mishap chain" as a supplement. This model I was familiar with before the cheese model. It tends to indicate a serial order of causes and contributions to a mishap. Any one of these links being broken ends the accident event chain, and the mishap doesn't occur.

TEXT EDITED OUT, 3holelover covered this more concisely. LW50

"It's not the pitot tubes" is most likely right from an analytical sense, since pitot tube malfunctions are neither unknown nor new. You then trip over two systems interface issues: one is hardware to hardware, the other is hardware to wetware. (wetware ~ human brain) Since such issues can get quite complex, the easy soundbyte isn't available ... but giving out an uncomplicated soundbyte is what is asked for in the public information sector of the process. :p

Were no rice bowls at risk of being tipped, you'd get a different (and cleaner) analytic approach from parties A, B, C, D, etcetera, and different PR emissions.

Yessir. True enough. I'll offer my humble apologies, and lots of slack... and shut up now. :oh:

As a fare paying passenger I want to know that you are doing exactly as required by the regulations and that you have taken all reasonable care to ensure that I arrive in one piece at my destination. I do not want a chancer up front.

Computer easily wins if given a choice because humans are more fallible. Simple statistical fact.

Most sensible comment since the beginning of the thread.

jcjeant you are getting boring. Air France had every opportunity to replace the probes just like everyone else. The fact they questioned it and left it very late before replacing, apparently to save money, says more about Air France than Airbus, Thales or Goodrich.

The A330 is a mighty fine aircraft. Pilots will never match the computers and its pretty blinkered to think you can. Safety statistics have never been better. Even if the software pitched the aircraft up in this case and I say IF, there was still no guarantee that this aircraft would have been saved.

I remind you all of the analogue 757 that lost its speed indications, the Birginair 757 that had ONE blocked tube.

Think about it.

On any specific FFS IOS Malfunction page under FLIGHT CONTROLS, you can count more than 20 selectable icons and under ADIRU, you can count more than 10.

In both B & A simulators, you see numbers of malfunctions available which are not incorporated in any training syllabus and are thus never utilized. (“Only move the shiny switches.”)

I realize there is a certain basic common default package, however.

3holelover

Sorry if I was a little too assertive there, but Lonewolf and you have given me a thought.

I think honestly that what I see with the cheese is metaphoria. It is not helpful to simplify with homily a serious safety discussion. I am pedantic here, but sometimes.....

Cheese emphasizes the randomness of this outcome, and it was not random, I'll bet my Calloway. It was predictable, borderline inevitable, and I think that is where Svarin and PJ2 are taking us all. It was a block, no a loaf, of cheese, with one void only, impossible to misalign.

If 447 wandered into Scratch's cave, that is a bad thing, throw in Ice, more bad, virtually any "mitigating" excuse is just that, an excuse. I smell some corporate nonchalance, here, will it be reinforced tomorrow? Defended?

bear, my love of links (golf or sausage) aside, the variables interact with each other in dynamic systems. (Such as the case under consideration).

I think you are being reductionist with your block of sharp cheddar.

I believe the BEA will not be reductionist.

Hi,

No probs ..
Les dossiers noirs du transport aérien
it's from one of the expert (member) of this family association
Bienvenue sur le site de l'association entraide et solidarité vol AF447
Liste des membres du Conseil d

Lonewolf

"...bear, my love of links (golf or sausage) aside, the variables interact with each other in dynamic systems. (Such as the case under consideration)..."

Of course, and my post was simplistic. Millions of people are going to be assaulted with reductionist rhetoric tomorrow, from all sides. After 38 logged events, one believes the pile of Swiss is getting a bit rangy. A causal chain becomes a necklace after enough iterations.

Hi Chris,
My main concern with jcjeant's post is that it is posted from a source which is not quoted at the first place. (Now, it is also translated with meaningless sentences). Anyway, I know that it is taken from a place where you can only find a compilation of documents (duely commentented) aimed at charging Airbus for its so many so-called wrong doings. There is nothing objective in such compilation as any communication on safety issues can be freely used as a proof of what they are suggesting: they did nothing and everything was aimed at discharging the manufacturer in case of trouble.

I myself posted about it, saying that it was a long story with Airbus "probe issues" (including the part of the manual dated from December 1999 explaining how to indentify unreliable air data).

Nonetheless, the way this issue is presented and commented is completely misleading:
Fact #1: Airbus did certainly something when the first issues appeared with Goodrich/ Rosemount P/N 0851GR which was the original probe on A330 (and issues were quite different from today context)... they developped with Goodrich the P/N 0851HL (not the Thales/Sextant C16195AA and later BA).
Fact#2: They worked on systems like the BUSS (Back-Up Speed System) and invested further in R&D technology (l@aser probes, etc.).
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.

Now, it may appear that the weakest link was the last one and we'll see that tomorow. From what I have read on the crew training by Air France, they were simply not drilled at tackling this situation at cruise level: a single training was made months ago about another critical situation (UAS in approach or landing phase), but here, there was no switch to Alternate Law and the basic reaction would have to be quite different in this case, with much more thinking (and time) about what to do before altering their flight parameters (possibly safe when this event started).

I never quite understood why this has to be a choice. It seems to me that future systems will need to seriously consider a solution where the pilot and the computer work together if we need to see improvements (in safety and other areas) in an already extremely safe system (as you pointed out in your earlier post).

I would replace when it is easy with when things work, because, that is by definition, what makes FBW flight safer than purely human operated flight. 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.

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.

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.

takata
 

Well, it surely smelled like "dossiers noirs" which has been now confirmed by jcjeant.
Nothing else to add about that source.:{

Neither am I. My point is that this is the dilemma we face, like it or not. Its an all or nothing deal. So you are completely ignorant or completely "in control" as the poor crew of 447 found out.

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.

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

It does. That is what happened as far as we know today (tomorrow maybe we'll know more) - from BEA original reports on the ACARS messages: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.

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.

I understand your answer to mean "no alert," but am not sure that this is what you meant.
Roger, but what is the cue that gets you disbelieving your airmass data in the first place? Most of the time, (just like the engines engines) it works just fine, does it not?
Understood, even if they way I asked the question didn't get me the answers to what I don't understand.

I'll review what PJ2 has said again, with your points in mind, and see what shakes loose.

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.

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.

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.

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? :eek:

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

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

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

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

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.

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

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?

Wrong. Your mind reading score is 0 out of 100.
Actually, it intrigues the hell out of me, but I've a finite amount of time to engage with you. You are unable to answer my question, no problem, I appreciate the attempt.
Which tells me you don't know ... no problem, it's a thorny question. The information should be with us shortly.

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? :confused: 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)
Thank you, that is old ground you are covering, and you still have not addressed my inquiry into alerts. Cheers. Appreciate your trying.

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 ..
My horrid grasp of French parses this as

"I don't understand this thing (that thing?)"

Am I close?

Hi,

I don't understand anything seem's better .... IMHO