I can't speak for others. I have, for myself, figured that the pilots did some things which appear to be disastrously wrong. Now, they either both had a really bad hangover or other form of really bad day or something led them to commit errors all the while thinking they were the correct thing to do.

The former case is unprovable. We can look at other issues to resolve the situation. Can we answer the "why" questions for "entering the storm", "pulling up on the stick in response to disconnects", "continuing the same errors after the second stall warning", and others?

It looks to me like a training error led to the pull ups, especially after the plane spuriously (with perhaps no accurate remedy possible) dropped the stall warnings when the measurable air speeds dropped to or below 60 knots. With that revised AirBus stall training syllabus I'm inclined to look to the training issue as the most serious one other than the pitot probes, of course.

But, that's just my hypothesis. There could be a real wiring problem, as unlikely as I see it, involved to compound the problems. There could be other problems that could have lead to the stall and led to it not being diagnosed in time. So that's what we're all discussing.

No pilot I know would pull full up at altitude because of loss of airspeed. We fly pitch and power for altitude and weight. Never would we pull up in a steep climb at that altitude. We have a checklist for that. Too bad the captain went back for rest when it happened. He could have handled it properly in my opinion. I only did one of those long flights to Sao Paulo and back and I didn't like leaving the cockpit to two FO's even though I trusted them. I never did it again. All of our junior FO's had at least 3 times the experience of the PF in Air France. Probably 100 times more hands on no autopilot flying.

I hope this Wall Street Journal article is not old news. Seems like AF447 may have been one of the motivating reasons.
Major Changes Building in Commercial-Pilot Training - WSJ.com (a truncated teaser)
They are talking about actual flying training! Not that simulator stuff. The kind of training where improper performance will create an immediate and visible impression on the psyche.

Not seeing the wood for the trees.
 

A major part of this thread has been and still is (very appropriately and usefully) along the lines of looking at the bark of one tree using a variety of microscopes. I would like to step back for a moment and try to look at the wood. Bear with me for a moment.

A good deal of the credit for eventually finding AF447 must go to the Russians who pointed out that in nine fatal LOC cases they had looked at of a/c getting into trouble at high altitudes, eight had crashed within 10 miles of the start of the event. The images below from the Metron report list the cases and show the distribution of distances.
http://pp.home.infionline.net/fig34.jpg
http://pp.home.infionline.net/table3.jpg


The a/c involved were an A-310, a Tu-154B, two Tu-154Ms, two B737s, an IL-18V, an ATR 72, a MD-82, and if we add AF447, an A-330-200.
One case involved icing, and the Silk Air case may have involved something unusual.

In six cases the LOC started at over 30,000 ft above the crash site, and in eight cases at over 20,000 ft above the crash site, i.e. with plenty of altitude to execute a recovery.

So here we have nine out of ten fatal LOC cases involving a/c manufacturers from different countries, flown by crews from different airlines, regulated by different government authorities, with crews trained under different systems, and using different technologies, some FBW, some not, but all but one of which crashed within ten miles of the start of the incident.

To me as a distant observer there is more than a hint of human factors, or human/machine interface factors, at work here. These data do not prove anything, but do hint (to me) that these (very, very, rare) accidents do happen whether the technology is FBW or not, i.e. human factors or human/machine factors were likely to be important (or dominant) causal factors in the outcome independent of technology, training, nationality, government regulation, or ………

And now back to the microscopes.

Hi,

I suggest this woman as chief instructor:

ASN Aircraft accident Airbus A330-321 F-WWKH Toulouse-Blagnac Airport (TLS)

Even if this has little or nothing to do with AF447, it shows that also the top guys (AB test pilots) didn't have a clear picture about the situation (alt acquisition mode/versus protections).

BOAC - Apologies for the slow reply. Details of other aircraft deviating round the weather front can be found in already released BEA reports and in various posts in the threads on this subject. I am sure that if you look you will come across them.

Smilin Ed - What you are referencing are the inputs into the interface. The human factors, the reasons or motivations for the inputs are not covered by aircraft designers. However, as these govern the inputs into the interface they are very important.

@PickyPerkins

Worth noting that AF447 is an outlier on that table in terms of full incident duration ~4mins 23 seconds which equates to 8,000 ft/min average vertical speed.

- is it perhaps that you have missed the 12 deg deviation of AF447 in the report? As far as I know there is no evidence that they 'flew into a CB'.

I agree, nowhere is there any evidence they flew into a CB. All we know is evidence that the pitot tubes froze up causing unreliable airspeed. Previous similar freeze ups have occured with the A330 with several airlines without flying into CB's.

To save me hours of searching - can someone quicklink to the report of the 'zoom climb' ?LH 340? over the Atlantic please? I think the analysis of why that beast lept for the heavens would be useful.

BOAC...Air Accidents Investigation: Airbus A330 C-GGWD and Airbus A340 TC-JDN

Read it carefully. I doubt if there is a relationship between the two behaviours of the aircraft but take a look for yourself and see what you think. The report focuses on a TCAS and AIRPROX event and I don't think does a credible job of explaining the pitch up.

The summary of the behaviour of the A340 in the "zoom-climb" claims that in the overspeed and turbulence, that the AFS reverted to the Alpha Protection Law. From my research, that was changed before this event occurred to inhibit the AoA Protection Law above M0.53. The other frustrating aspect is, the recorder data that is included with the report does not have AoA...the very parameter claimed to have caused the triggering of the AoA Prot Law and the cause of the zoom-climb.

Anyway...these things are complicated. Maybe I'm mis-reading it all.

Interesting, PJ (many thanks for the link). I disagree (from a position of ignorance on the AB system!) with your 'doubt' of a 'relationship' - ignoring the trigger for a/p dropout, we appear to have a similar manouevre induced by the FCS and not the crew, resulting a (co-incidental) 'arrival' at FL380 after a 6000fpm zoom during which the IAS decayed below Vls. OK, I'm easily swayed by these things, but???????

I do not understand why the alpha reached 'alpha-prot' all on its own? It then goes on to say that if the sidestick is left untouched in pitch, alpha remains at alpha-prot, and that application of full back stick would take it to alpha-max and that a determined nose-down input is required to stop this. So, this a/c,all on its own, raised the nose to alpha-prot and climbed - with no crew action to cause it. The report goes on

"For 18 seconds after the autopilot disengaged the aircraft remained within 200 feet altitude of FL 360 but once AoA law was invoked at 14:21:50 hrs, the aircraft’s attitude began to pitch nose-up. The pitchup trend continued for 17 seconds reaching a peak of 15° nose-up shortly before the first nose-down sidestick command was applied. Throughout this phase the aircraft climbed rapidly (reaching a peak rate of about 6,000 ft/min) due to the increase in lift created by the flight control system’s capture of alpha prot. The aircraft reached its apogee at FL 384 at 14:22:28 hrs where the airspeed had decayed to 205 KIAS and 0.67 Mach even though full thrust had been applied."

I then am told that there is no indication in this system to the crew that this 'law' has been invoked? I am struggling to see, through my ignorant eyes, why this is not relevant to 447? I know, different type and 'history', but is there not an Occams Razor lurking here?

Note this report was discussed on these forums as soon as the crash site located - the 'zoom-climb' to loose speed and stall from height being the simplest explanation Mr Occam could suggest. But clear air turbulence, daytime, 4 engines ... no Unreliable Airspeeds or Alternate 2 law - so very different protections active. Trying to match pilot inputs and the resulting elevator, Stab. and engine speeds to the resulting flightpath from the low res FDR plots in this report is still quite a challenge - what sense and scale is on the 'SS1 PT'? Compare/contrast the higher quality better labelled plots in the QF72 first interim report Investigation: AO-2008-070 - In-flight upset, VH-QPA, Airbus A330-303, 154 km west of Learmonth, Western Australia, 7 October 2008 , which is relevant with respect to the dynamic response of an A330 at FL370 but control system glitches not believed to be directly related to AF447?

There are at least 5 computer systems monitoring airspeed: 2 FMGECs and 3 FCPCs (a weird architecture for me but what do I know?).

The previous 2 or 3 days discussions suggested the following possible sequence of events (of course open to discussion):

Pitot 1 tip freezes. ADR1 output indicates rapidly decreasing airspeed/Mach.

FCPCs and the AFS part of FMGECs detect the discrepancy and launch monitoring functions:

AFSs quickly reject ADR1 (tolerance threshold = 20 kt for 0.45 s) and uses remaining ADRs

FCPCs would reject ADR1 if its error relative to median CAS was still above 16 kt after 10 seconds. In the meantime, having detected the median CAS value decreased more than 30 kt in 1 second they launch the “median CAS monitoring function”:

• Master FCPC (FCPC1) broadcasts it intends to change the flight control law from normal to ALT2.

• Master FMGEC/AFS receives the ALT2 request from FCPC1, disengages AP and A/THR then acknowledges the message.

• Receiving acknowledgment that AP and A/THR are off, FCPC 1 activates ALT2 law and notifies other FCPCs.

• All FCPCs start computing flight control commands according to ALT2 law, using limited pitch rate feedback and gains for an initial period of 10 seconds. “F/CTL ALT LAW” is displayed on the ECAM. At this stage, ALT2 law is temporary. If at the end of the monitoring period the median CAS value is found less than the value registered at the start of the period minus 50 kt, ALT law will be latched.

• At some point before the end of the monitoring process FCPC2 loses connectivity with ADR1. For FCPC2 the median CAS becomes the average of ADR 2 and 3 CAS values, practically unchanged compared to the initial value.

• The 10 seconds period ends. Because their final median CAS value is beyond the 50 kt tolerance, FCPC1 and FCPC3 signal normal law unavailable. They also reject ADR1. FCPC2 finds its median value in tolerance and able to compute normal law.

• Before latching ALT law, the FCPC priority logic must be invoked otherwise the master FCPC would force other FCPCs to change law and would never relinquish mastership.

• Priority logic grants mastership to FCPC2 because it is claiming the highest level of flight control law.

• End of “median CAS monitoring function”.

Now comes perhaps the most arguable part of this scenario. Pitot2 and Pitot3 start icing simultaneously but not as fast as Pitot1. CAS does not decay fast enough to trigger another “CAS monitoring function”. However, it triggers the AoA protection law instead, due to the “phase advanced AoA calculation” similar to the TC-JDN A340 Airprox incident. That this function is now inhibited above M 0.53 is irrelevant in this case since the measured Mach number was soon showing less than that.

The A/C start a zoom climb, trying to maintain about Alpha Prot AoA, apparently confusing the PF beyond any understanding.

Perhaps all of the above is just garbage but:
1/ The claim found in the Airbus FCTM that simultaneous obstruction of two pitots is “highly improbable” is a weak case when there is a common cause. These pieces of hardware are built under tight tolerances, live the same life in the same environment and pitots 2 and 3 occupy exactly symmetric positions on the fuselage (contrary to pitot1). Additionally, ice ingestion is not a slow process at cruising speed when the Ice Water Contents in atmosphere reaches 9 g per cubic meter.

2/ I believe the “phase advanced AoA calculation” uses a time derivative of CAS in order to anticipate the interception of Alpha Prot speed and prevent any slower speed. AoA may not be precise or stable enough and its variation is not linear with speed.

that none of the three pilots had any idea what's going on.

This, in a modern, highly sophisticated airplane.......

Optimum interface? I'm afraid no!

Feedback Systems (Testability and Diagnosability)
 

PJ2,

When trying to understand this "things" we must remember they are "complex feedback Systems" eventually with crew actions affecting final results (crew with his own feedbacks not always logical and understandable by us).

Many years ago i worked (Testability of complex electronic Systems) in diagnosing "complex digital circuitry" full of feedback loops. The only way we found adequate to diagnose a faulty circuit down to the component level was "to open the feedback loops" at least, momentarily.

The simple reason is: When there is a certain failure, the "feedback loops" make the "failure" appear also in the inputs of the System. And this was for a Hardware in a lab, in a bench with all necessary stuff (Digital storage scopes, logic analyzers, recorders, etc.)

When investigating incidents (e.g. AIRPROX) or accidents (AF447) i suspect the current FDR´s may be not are enough to provide all the required details (e.g. the WRG fault) to allow a definitive conclusion.

Ridiculous Pitot redundancy implemented
 

Considering Airbus SAS didn´t have supply of "hotter" Pitot´s a much safer approach would be to put several Pitot´s in selected locations of the a/c and feeding a reliable "voting scheme" subsystem.

The "redundancy" used in this design may be is "amplifying problems".

In Annexe 1 of the French version of the first interim BEA report, Meteo France's analysis of Meteosat 9 imagery indicated AF447 flew into a cloud with tops of 500 to 520, while in an area where mature convective storms were embedded within layers of cumulus, altocumulus, and stratocumulus.

Vasquez concluded the cloud tops were FL560 at about 2 h 10.

What sort of cloud does one find at FL500 in the ITCZ?

pj2
 

many thanks again for one of many useful links :ok:

Due to limited availability of class slots, I had to do my A330 ground school with a class start time of 2 AM. (This time is more suited for leaving a bar than being alert & receptive to technical instruction.)

However, reading some of the knowledgeable detailed technical discussions here, I’m having flashbacks, not to the information presented, but to the difficulty in trying to understand what it actually meant at oh-dark-thirty in the wee hours.

Now occasionally in my head, in imaginary digitized voice, I'm sure I will hear all these computers "broadcasting, receiving, requesting, acknowledging, discussing, granting and permitting".

(Previously I never gave it a second thought with the SS firmly, i.e. lightly, in hand.)

There is no indication so far the the 447 zoom climb was induced by the FCS, while there is knowledge of PF nose-up input prior to the climb. If invoking Occam, why would you add an FCS law change as cause of climb when there is already a known nose-up input from PF ?

In the other incident, my understanding would be alpha reached alpha prot due to severe turbulence causing fluctuations in speed etc., followed by (I think) crew reducing speed after momentary overspeed warning (hence next downward fluctuation in speed maybe takes alpha momentarily over alpha prot, and engages the law).

The other difference is that the other incident is in normal law, while 447 was in alternate, which doesn't have the alpha prot law.

[ Note: I know there are some posts on a theory that maybe 447 was still in normal law through one of the PRIMs, and therefore the climb oculd have been a protection doing the wrong thing - I think there is a fundamental flaw with that theory, which is that in normal law the FCS would never have allowed the a/c t exceed alpha max, which it clearly did. ]

IF789: Right on w.r.t. this :ok: There are a number of problems with this 'hung on in Normal' theory - most significant of which is the lack of any comment within the BEA note of May 27th. I hardy can conceive of them (a) not reporting a disagreement of control law with that reported by the crew:

If this had been in error or something mislead the crew, then I firmly believe that would have been stated in the note. Otherwise the BEA have simply hung the crew out to dry to some extent. I realized that many folk have been attempting to "fit the foot to the shoe" and have been postulating theories that might work with the data we have, but Occam doesn't sit comfortably with any in my opinion.

The BEA data is maddeningly thin, but the shortest distant between two lines is most often the route traveled.

Chronology of events @ 5 sec interval.
 

Updated here: LINK

I am probably guilty of inaccurate terminology here, apologies all - there is ample evidence that they flew into turbulent weather though.

This was first brought to attention by takata in this post.

!!!!!!!!!!!!!! post with reordered ACARS message list. Since there is some discussion about the delay in NAV ADR DISAGREE, I thought I'd post it to help refocus.

Hi,

I want also brought to attention .. this ...

In the BEA note (27 May 2011)

The chronology of events is not rigorous: A 2h10min51sec it is said that a couple of seconds later, the speeds become consistent. So, 2h11min06sec speeds are consistent. It is said, small on the next line (foot note), that the inconsistency between the speeds lasted less than one minute. So let's say 59 seconds. This therefore means that the inconsistency between the speeds appeared earlier than 2h10min07sec. So before 2h10min07sec speeds were consistent. So why 2h10min05sec to the autopilot and auto-thrust and disengage the OP says "I have control"? The autopilot had disengaged while he speeds were consistent?

This BEA note can't be a serious one to elaborate any scenarios from it
Only the FDR can be a valable source for a scenario .. instead of some truncated dialogues between pilots and fantasy timing ..

Disagree, suggest you read the report closely again.

The aircraft, and it's systems (AP etc.) work from 3 airspeed sources. The FDR only records 2 of those. So prior the 2:10:07 any observations / system anomalies would be down to the 3rd (unrecorded) speed source.

How an aircraft aerodynamically moves though the airmass is essentially an engineering problem which is very well understood. Computers solve these engineering problems very well, better than humans, and it is clear that automation of the nature used by Airbus has saved many lives. Computers, as well as pilots, require sensors to fly and if the aircraft sensors are working it makes sense for the aircraft to fly the aircraft instead of the pilots. When all aircraft systems are working, it also makes sense for the aircraft to override all 'flying' actions that the pilots make which the equations for flight deem to be dangerous. i.e. Normal Law.

When the aircraft sensors fail, as they appear to have done here, it is essential that the aircraft hands over control of the flying of the plane to the pilots. This appears to have been done properly. As the aircraft had degraded sensor information it removed any protections that rely on this sensor information. This is also a correct action to take, aircraft in ALT 2, no AoA protections in place.

It then appears that the pilots mismanaged the further flying of the aircraft. Unusual, but the evidence we have so far points strongly in this direction. The reported sidestick position invalidates all the other improbable theories proposed so far.

On the descent, it appears that the input from the aircraft sensors became valid again. This is entirely to be expected if the initial problem was icing. The aircraft would presumably have known that all it's sensors were now working. However it was latched into ALT 2, AoA protections are not in place, and so it could do nothing about the stall.

If once the aircraft had validated the sensor data, it could have legitimately reverted to normal law, it could then have applied AoA protections and all on board saved.

So why is this not programmed to happen?

OC - if it helps with your 'terminology' the ITCZ IS an area of 'turbulent weather' which pretty much circles the globe, commonly with CB activity but generally always with 'bumps'. It may help you to Google ITCZ and see? As such, dozens if not hundreds of aircraft penetrate this 'zone' every day and nearly always experience 'turbulent weather'. Sometimes light or moderate, occasionally severe. It may be that 447 did fly into a CB - we do not yet know, but I do not see any evidence of it so far. Very few of them experience the loss of pitot systems which appear to have triggered this event so until we can establish that an 'active' CB was penetrated by them it is not really relevant.

For Saturn, I have never been to FL500 in the ITCZ so I cannot answer your question but I would expect (and not be particularly surprised by) the activity on an active ITCZ to easily produce water vapour up to FL560. It may be useful to try and look at other Sat weather images of the zone on other days. I believe it is generally accepted that the tropopause can be at FL560+ in the tropics so it should not be a surprise.

Hi,

It's no matter of airspeed sources or what is recorded or not .. it's simply matter of timing described by BEA.
The numbers are there black on white .. no need of "what if" or or complicated scenarios
Make the maths ... it's simple arithmetic ... and something is wrong ..

Because of the Airbus A/T design, the thrust would have gone to full power. A fundamental design flaw, imho, and one that will never be admitted to by Airbus. I hated the T/L not moving design of the Airbus. It works fine when all is going smoothly. But in the failure case, and non standard configuration case it causes more trouble than it is worth. It is so difficult to work out what it is or is not doing under high workload situations. Very often all you have to go on is the "cyan arc." a tiny blue trend line. Miss that and chaos can ensue.

With all the warnings and the chaos on the flight deck, it is doubtful if the FO hd the spare capacity to even notice the AT going to full power. That would have instantly de-stabilised the aircraft. Making a bad situation far worse.

TCAS Fail
 

Thanks, Cogsim:
Loss of Mode C results in TCAS Off, not TCAS Fail.

I can only conclude the BEA reporting is inaccurate.

Hi
I think you misinterpreted what "valid speed" means. When the BEA writes "The speeds became valid again", it means the speeds were no longer below 60kt (for AoA stall warning) or below 30kt (for speed itself).
A valid speed (system speaking) is not by definition a correct speed (i.e. real).
The system cannot know if the sensed speed, after the pitot failure/icing, is back to correct values. In fact in some cases, speeds may be valid (above 60kt), consistent (3 equal values, or at last 2 equal values, the third being voted out) but not correct.
It's only the discrepency in speeds (from 3 sensors) that make the system decide "We got a problem". Unless you can confirm the correct speed by other means, it's safer IMO that the system let the crew decide. That needs the crew to be trained for such situations, and the SOP to be OK.

For the system to be able to decide, by itself, that the speeds are back to correct values, it would need to compare the ADR speeds with other sources. Perhaps the INU/GPS may be a source, here, in combination with the altitude (pression), the temperature and the wind speed/direction. If you have all of them, I suppose it's just maths (which a computer can do, and quickly).
The wind speed will be a problem, to me. How do you know it ?

CogSim;

It should be noted that both referenced posts are dated 30 june 2009, i.e. before BEA published its first Interim Report. I believe BEA's reports are based on more authoritative information than these posters (with all due respect) had at their disposal at that time.

Thanks for reply. I should have quoted the report, I was referring to the reported fact that the speeds became consistent during the descent (as to be expected once the icing conditions had been left behind if the initial problem was pitot icing, which appears likely)

"Around fifteen seconds later, the speed displayed on the ISIS increased sharply towards 185 kt; it was then consistent with the other recorded speed."

It was inconsistent speeds that caused the aircraft to depart normal law and hand control to the pilots. If the speeds later became consistent there should be, IMO, logic that at least contemplates a return to normal law. 185kts is well above the lower limit where the aircraft ignores the speeds as being out of range.

Had the aircraft returned to normal law, applied AoA protection, it almost certainly would have recovered in the 30,000ft available.

Apart from that I cannot, with the information available, fault the aircraft at all.

Why is ALT 2 latched?

IIRC it was not an inconsistency between the three ADR speeds, but a sudden drop in one of them, the "polled" value that the PRIMs were using and considered the most accurate of the three. That anomaly was confirmed at the end of the monitoring period.

PA 18 151 : My mistake on the "valid" speed.;)
I agree with you, in AF447's case, a return to normal law may have helped, or even have saved the plane.
But I stand still : how can the system decide the speeds are corrects ? It would be a guess. And I think that, in other scenarii, such a guess would be wrong and lead to incorrect actions by the system.
That's why I suggested a comparison between the ADR speeds and other sources. The ADR redudancy is not enough, as 3 (identical) probes can be faulted by an identical phenomenon at ~ the same time : icing, ash cloud...

I suppose that's why ALT2 is latched. The point is, as you said : If the aircraft system doesn't know, let's give control to the crew.
The aircraft system cannot know, cannot be 100% sure (using only the ADRs) that the speeds are back to correct values "just" because the speeds have rised, and/or are consistent again. The crew is better IMO to assume that, based on other sources (pitch, power, feel, visual clues...)

For the record : Agreed with the rest of your posts :ok:

Hi Hazelnuts,

Yes, it used polled value, explained by BEA (Interim Report 2) my italics:So my reading is:
1) No single value is more imporant than the other in normal operations
2) When one becomes inconsistent with the other two it is rejected
3) When the other two become inconsistent with each other the law goes to ALT 2

It is inconsistent speeds that causes the plane to reject them

Consistent AND valid = Correct

The speeds later became Consistent AND Valid therefore they should have been considered correct. i.e. Normal Law conditions = AoA protections = aircraft breaks the stall.

AlphaZuluRomeo:

Consistent AND valid = Correct

Well, yes it's a good assumption to make that the crew will act correctly once the plane hands over control. Is this what the designers assumed too? Perhaps another flaw in system design?

Normal Law would almost certainly have saved the day. I submit that from the evidence we have, for over two minutes and 30000 ft AFTER the initial problem, that normal law conditions existed. Unfortunately in the interim, ALT 2 had been latched, and the aircraft was unable to break the stall the pilots had caused and failed to recover from.

Very nice timeline, hope we get that level of presentation in the BEA reports (though just fdr traces would be ok).

Haven't gong through it all, but it looks right per the information we have to date. One comment - initially there was a PF left + nose-up input which seems to be missing.