PPRuNe Forums - View Single Post - AF 447 Thread no. 4
View Single Post
Old 3rd Jul 2011, 22:29
  #720 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 76
Posts: 2,485
Received 1 Like on 1 Post
RR_NDB;
Another "great feature" of "advanced planes". In some cases you may not be capable to even imagine what happened when analyzing a "mysterious" case.

. . . .

Another reason to "rethink" the FDR concept. IMHO it lacks currently the capability to provide the required details perhaps not allowing definite conclusions.

You say that the industry should, "'rethink' the FDR concept [/I]".

On the contrary, the industry has come a very long way in flight data recording.

I'm genuinely interested in any push to improve flight data recording, (but with CNN around, not video recording) because the present legal standard in Europe, the United States, Canada and I believe Australia is the recording of 88 parameters for aircraft of the A330's certification date. For those certified prior to 1991 (October to be exact), only 17 or 18 parameters are legally required and if the aircraft is modified with a DFDAU [Digitial Flight Data Aquisition Unit], 22 parameters.

Any FDR & QAR data gathered above this regulatory minimum is voluntary. That should give some sense of the extent to which flight data is valued and gathered for investigation and accident prevention in FOQA Programs.

Nevertheless, many working in the industry have been battling this lack of data for decades, but with little success in improving the regulations even for the protection of data that is required to be recorded.

To some, data is indeed "inconvenient" because, in an accident the data can illuminate failures somewhere in the system. The will to deny unwelcome flight data is powerful among those who are commercially-motivated and such short-term thinking does drive the industry to a certain extent.

If the airline lobby (through IATA) is unified at all, it is not around sustaining such "mystery" but more ordinarily around the very high cost of such systems which will always include the costs of retrofitting aircraft to exceed the legal minimums. Where STCs [Supplemental Type Certificates...the legal authority that permits any aircraft to be modified), alone are unbelievably expensive, time consuming and resource-hungry, for smaller organizations.

That many current transport aircraft record over 1000 parameters is a testimony to the digitial revolution and the both the manufacturer's and the airline industry's established intention to monitor their aircraft, primarily aircraft systems but operationally as well.

FOQA Programs, now regulated with certain FAA protections for the collected data in the US but not in Europe, Canada or Australia, use QARs which can be programmed to record many thousands more parameters and at higher sample rates than available in FDRs and certainly exceeding the legal minimums.

The AAIB document, "CAP 731" is well worth examining, especially Appendix B which describes a bit of the complex recording process.

The BEA may have already used the QAR and other EEPROMs from the FMGECs, FCPCs, FCSCs mounted on the main equipment rack, "880VU" and since recovered. Hopefully they will have some comment on this recovery.

To return to your point, the fact that the #2 CAS is not a recorded parameter has nothing to do with a mysterious absence facilitating a 'mystery' and plausible deniability. Were that the case, many other parameters which hold equal importance would also be "missing". There are approximately 1300 parameters on AF 447's SSFDR. It is unfortunate that the #2 CAS parameter is missing, but it just isn't logical or even reasonable to believe that someone or some organization didn't want the parameter to be in the data.

One manual pitch-up theory says that the PF was pulling back in response to a high-speed indication on his PFD.

My own view is, the #2 CAS was almost certainly, roughly the same as the #1 and the ISIS-displayed speeds. Here is why I believe this:

Double or triple independent and concurrent system failures are extremely improbable. So first, let us set aside double or triple failures in other sensors and/or computers independent of the pitot failure and not merely a cockpit effect of upstream data or component failure causing an instant increase in CAS readings just on the #2 PFD.

By design the FMGEC > FCPCs cannot trigger the High Speed Protection Law or the Alpha Protection Law in Alternate Laws 1 or 2. And there is only one case where pilot ND response on the sidestick is inhibited and that is the High Speed Protection in Normal Law, and only until the speed is reduced below VMO +4kts, (IIRC). All other "protection" pitch-ups may be countered by the PF. So if the pitch-ups were executed by "rogue software/hardware", the side-stick should be effective in reducing the pitch and returning the aircraft to level flight.

This leaves us free to examine pitot failures in combination with the plausibility of an airspeed increase just on the #2 PFD.

There is no pitot failure mode which will cause an increase in airspeed in level flight.

A blocked pitot inlet and open drain hole produces a drop in airspeed and a blocked pitot inlet and drain hole requires an increase in altitude to produce an increase in indicated airspeed.

The increase in such a circumstance is mild - from experience (B767) it is not a huge increase - 20kts, perhaps. At FL350, the cruise speed was roughly 271kts (M0.80) and MMO (M0.86) is approximately 295kts. Nobody is going to pitch a transport aircraft up beyond 10deg to control that kind of increase in speed.

Regardless of amount of increase, logically the increase in observed speed must occur before the actual pitch-up because, with the pitot and drain hole both blocked, there is no increase in speed in level flight and the pitch-up by the PF would not have occurred in response to increasing speed. Therefore the PF was not responding to an increase in observed CAS on his PFD.

The argument is merely reasonable but of course is not conclusive.

So your, and everyone's question regarding "Why the pitch-up?" is, I think, the only important one at the moment.

I think the PF was executing the initial memory items of the UAS drill rather than stabilizing the aircraft (maintaining pitch-and-power settings) while calling for the QRH UAS checklist for the book settings but that's just a theory among theories and we'll soon know what actually happened and why.
PJ2 is offline