PPRuNe Forums - View Single Post - TAM A320 crash at Congonhas, Brazil
View Single Post
Old 6th Aug 2007, 15:30
  #1242 (permalink)  
ELAC
 
Join Date: Jun 2001
Location: East of the Sun & West of the Moon
Posts: 286
Likes: 0
Received 0 Likes on 0 Posts
Ok, so let me complicate this logic a little.
Having in mind that Vref+something is not that far from V1 for a specific leg and usually a bit lower, why not INHIBIT that command above V1 (if this speed is entered on the FMGC as it normally should).
Simple. Bellow V1 uncommanded REV deployment would set the other engine to idle and the situation is treated as a RTO. OTOH on a situation of T/L left above idle on landing would let the plane do its magic. Either situation would trigger autobrakes and spoilers.
GD&L

Okay:

Below V1 uncommanded REV deployment would set the other engine to idle and the situation is treated as a RTO + DUAL LGCIU FAULT (Loss of A/G signal) = 1 ENG uncommanded reverse on approach at Vref + 1 ENG auto-commanded to idle = Dead Again!

Now to be fair, in this case I'm not sure that the default value for a loss of A/G signal from both LGCIUs is GROUND, but I think it is. It might be the last reported position or it might be different depending on the receiving system, I don't really know. Do you?

How about an incorrect V1 speed entered by crew? Optimized performance take-off where V1 is 20-30 knots above Vapp? Loss of FMGC V speed data to the autothrust? There are lots of cases to consider and if you get any one of them wrong you could leave the crew and airplane hanging like dead ducks without power when they really, really need it ... just ask anyone who's done a reverser deployed on takeoff scenario in the sim.

I know the thinking is well intended on your part (and by most if not all here), but I'm mystified by how we can have one part of the crowd carping that there's too much or too much wrong with the automation leading to a lack of crew awareness of the condition and another part of the same crowd mooting that an uncommanded automated reduction to something as vital as the thrust on a normally functioning engine in a critical flight regime might solve the apparent problem.

The way all the bits of automated logic fit together and the way they connect to human decision processes is a seriously complex subject; certainly way beyond my limited brain wattage. Suffice to say these inter-relationships are the product of an awful lot of pointy heads working together over a great number number of years to evaluate all the different ways these things can work or fail.

We are loathe (and rightly so too) to lay blame at the feet of the crew until there is concrete proof that their actions were unreasonable for the situation. Don't the folks who develop the logic of the systems deserve the same consideration? I don't know that the current system logic is perfect, but until we (i.e the investigators) get down to identifying a specific element of that logic that undeniably failed and actively worsened the situation (and pj and I are just going to have to agree to disagree here), I think that we are putting the amateur flight control system designer's cart before his horse.

ELAC
ELAC is offline