PPRuNe Forums - View Single Post - AF 447 Thread no. 4
View Single Post
Old 2nd Jul 2011, 16:10
  #656 (permalink)  
DozyWannabe
 
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes on 0 Posts
Apologies for delay - helluva busy week!

Originally Posted by galaxy flyer
The pilots clearly did not grasp what the computers were trying to do
How many times is it possible to say that the computers were not "trying" to do anything other than that which they were told to do by the stick inputs from the flight deck? "NO PROT" means just that. There's no released evidence whatsoever that indicates the pilots were "confused" by anything the aircraft was doing.

probably did not understand what the THS was doing and how that might have impacted their recovery attempts, and how they may have reacted properly.
I may be contradicted by the report when it finally arrives, but it would not surprise me in the least to discover that what the trim system was doing didn't even factor into the troubleshooting mode (by which I mean mental model) they were in. Again, witness the Birgenair case where, despite the escalating warnings that went on to include stick shaker, stall call-out and eventually the dreaded "WHOOP WHOOP PULL UP", the pilot spent most of his time continuing to troubleshoot the initial explicit warning he got, which was the erroneous overspeed.

Unfortunately, pilots learn to fly on planes that fly like all the planes built since the Wright Flyer, version 1908, not like Airbuses.
We all (or most of us) learn to ride a bicycle on stabilisers/training wheels, learn to drive in low powered "city" cars and learn to read with basic picture books. We can't rely on those forever, because they all limit the ability to master the thing you're trying to learn. The same is true of learning in a Cessna and piloting an airliner - the former is designed to have forgiving characteristics and be easy to fly using the simplest technology, whereas the latter is designed to get as many people from one place to another as quickly, efficiently and as economically as possible using the best technology available for the job.

There have been a disproportionate number of LOC accidents/incidents in Airbus aircraft. Since the A320 Habeshiem accident, there was the NAT incident, the Australian incident, the Perpignan crash, amongst others.
Not true. Every aircraft has its fair share - notwithstanding the fact that Habsheim was down to pilot error (with, IMO, significant corporate negligence on the part of Air France) and the Perpignan crash was largely attributed to failure of the pitot-static system due to improper cleaning/maintenance.

Originally Posted by RR_NDB
I.e. BADLY! This redundancy implementation is USELESS specially at "cruise FL". Or worse, creating a CRTICAL design.

The use of a "voting scheme" capable to "major a/c reconfig" using identical (sub heated) not adequate Pitotīs is a direct path to PROBLEMS!

...

1) Ridiculous AS sensors redundancy (useless)*
2) The use of this voting scheme to not adequate AS sensors (sub heated)

Note: IMO this design EXACERBATES Pitotīs icing susceptibility
I disagree strongly. The system was designed down to a worst-case scenario where one pitot had failed. The thought of two or more failing was thought to be exceptionally remote. Until Birgenair and Aeroperu, the concept of air data failure wasn't even headline news to the aviation industry and by then the A330 had been in service for over two years. The combination of the less-than-stellar performance of the Thales AA pitot probes in foul weather conditions with the voting logic of the FCU and FMC didn't raise its head until a decade later, and they've been trying to fix it since.

Now, regarding the traditional method of redundancy where the pitot data is directly fed to one of three instrument clusters (CPT/FO/STBY), I'm not sure if the Airbus design reverts to this behaviour in the event of ADR DISAGREE - or indeed if that's how it works anyway and the filtered data only applies to the automatics - and I will try to find out ASAP. However I'd like to throw in that even if this method is used, it still takes time to diagnose which of the pitots has failed (Birgenair F/O : "Mine [ASI] is broken too" [it wasn't]), have the presence of mind to fly pitch and power while doing so (no mean feat at night in turbulence with warnings blaring at you) and resist any attempt to re-engage FMS until you're absolutely sure the failure has been isolated. Birgenair's FMS did actually try to fly the aircraft with the bad data, causing a pitch-up to the AP's limit of authority due to erroneous overspeed indication - which Airbus's design would not have allowed to happen, so in that aspect it is actually a "better" design.

Originally Posted by BOAC
JD-EE, I disagree - it was the 'system' that trimmed the tail at AMS, PGF and with 447 (and several other cases), not the 'pilots'. In all cases they made no deliberate attempt to trim that far.
With respect, we have no idea what they did or did not attempt - let's wait for the report before we start blaming the system, the pilots or a combination of the two, eh?

Originally Posted by Chris Scott
That is why Dozy Wanabee and I are suggesting that, in the UAS case, the reversion should be all the way to Pitch-Direct, requiring the PF to do the pitch-trimming.
Chris, again with all due respect I *never* suggested that. I asked Smilin'_Ed if that's what *he* was suggesting, but my position is that the designers had a very good reason for implementing Alt 2 in this scenario and I intend to find out at some point. I'm still not convinced by the "G-loading causes nose-up trim" argument and I'm trying to find the info that will confirm or disprove it.
DozyWannabe is offline