TAM A320 crash at Congonhas, Brazil

[bsieker]

Magic Buttons to the Rescue. Or the Demise.

Originally Posted by atakacs

[...] optional aditional and basic help to recover from emergency situations (stop the plane NOW, get to level flight NOW, Go Around NOW) could save the day...

Such automatic buttons are useful, but will not automatically save you. You have to know which ones to press, and in which order. Otherwise they might get you in trouble.

Case in point:

For "go to level flight" and "go around" these are already in place.
The V/S-FPA pushbutton can have a "Push to Level Off", or "PTLO" function, which selects AP Vertical Mode "V/S" (vertical speed) with a target speed of 0m/s.

"Go Around NOW!" is enabled by advancing the thrust levers all the way forward to TOGA. During approach this not only gives maximum thrust, but also performs an automatic go-around. (Setting AP Modes SRS and GA TRK).

Not using this fully automatic go-around procedure probably contributed to the Sochi accident just over a year ago, where an Armavia A320 crahsed into the Black Sea after the pilots lost spatial orientation.

Incidentally they did use the other "magic button", "PTLO" and then selected OPEN CLIMB towards a too-high altitude target, which, in this combination, caused the autopilot to command a steep pitch-up and climb with unexpectedly high vertical acceleration.

This in turn, combined with a low-energy warning (SPEED, SPEED, SPEED) a short while later, and then, after selecting TOGA thrust in response to it, activation of SRS and GA TRK modes, may have caused the flight crew to think the AP was behaving erratically and to disconnect it.

Continuing unco-ordinated stick-inputs of both pilots, disregarding FD command bars and other instruments (radio altimeter), and breakdown of crew resource management finally led to loss of spatial orientation and a CFIT, despite an EGPWS warning.

So, even if you have some "Get-me-out-of-trouble"-buttons, you still need to use the right one.

BEA just released the English translation of the Russion accident report a few days ago.

[James7]

Autothrottle

Pira: Most Boeing aicraft are flown with autothrottle on even when manually handling

.

My Boeing instructor in Seattle:-"Autothrust off first then Autopilot". Not once on Boeing's have i seen autothrust engaged on landing during a manual landing. B727,B737-2,3,400, B747-200,400. The last time i flew a Boeing was 5 years ago so maybe times have changed.

Regarding the tire damage. Likely cause is that the brake pedals were firmly on the floor and as the wheel left the ground going off the side of the runway, wheel now firmly 'locked', on touching down again the tyre was likely shredded on the point of impact.

Regarding this thread, I believe it is one of the most informative on PPRuNe. It has certainly highlighted a number of Flight Safety and human factor issues and enlightened many AB operators.

Fortunately it appears that this will not go down as a 'Pilot Error' only accident, judging by the recent demonstration and government resignation.

[Dream Land]

Even on a Piper Seneca, you must close the throttles in the flare, maybe in the future we will see the following MEL operational procedure:

Thrust Reverser Inop-For approach and landing, A/TH - OFF

[HotDog]

I would still tend to think that a "panic" button could be useful in some cases where the pilot simply doesn't understand what's happening with the plane. The Airbus chief test pilot and 6 fellow airmen were killed in such an occurrence (ok, it's a bit of oversimplification)...

Takacs, your 2c worth certainly is an over simplication, as you say!
2.2) HABSHEIM
Air France, Airbus Industrie A320-111, F-GFKC, June 26 1988
2.2.1) Isn't this crash proof of deficiencies in the fly by wire A320?
Contributed by Phil Miller
No. This accident was caused by human error on the part of many
people, including, but not limited to, the crew. The flyby of
Habsheim airfield was poorly planed and poorly executed.
Poor planning
No reconnaissance of the airfield was made by the Flight Division of
Air France in preparation for the flypast because of the extensive
experience of the pilots.
The crew were only given details of the flypast when they reported
for work on the morning of the flight. They were given no verbal
briefing on the display, or the airfield, which they were unfamiliar
with. According to the instructions given to the crew, which were
based on the invitation from the airshow organisers, the event was to
be aligned with runway 02. It was over this runway that they were to
perform a low, slow pass.
It was not until 450 feet AGL had been reached, on descent to the
airfield, that the pilot saw the crowd was along runway 34, not 02.
At this late stage in the descent he realigned the aircraft's path to
runway 34.
Poor execution
Habsheim airfield is located approximately 10NM north of the takeoff
point at Basle-Mullhouse Airport. The total flight time from takeoff
to impact at Habsheim was 4 minutes and 34 seconds.
Initially the crew climbed to 1000 feet AGL. Descent was commenced
5.5NM from Habsheim with the flight director set to Open Descent Idle
Mode, which held the autothrottle at flight idle. The engines
remained at flight idle until 5 seconds before impact with the trees.
The automatic system that might have prevented the crash, the Alpha
Floor function, was turned off by the crew as the aircraft descended
through 100 feet AGL, so that they could fly a slow speed, high angle
of attack, pass along the runway, without the engines automatically
throttling up as the maximum angle of attack was reached.
The rate of descent, with the engines at flight idle, as the aircraft
approached the airfield was still 600fpm, when the altitude was only
100 feet. The aircraft was levelled out by application of elevators
only, with the wheels 30 feet above the runway and the engines still
at flight idle. There were 40 foot high trees only 200 feet beyond
the end of the runway. When the crew recognised the trees full power
was applied. At this stage the aircraft was flying at only 120 knots
with an angle of attack of 15 degrees. The engines responded within
their certification guidelines, but approximately 5 seconds later the
aircraft impacted the trees.
The minimum altitude allowed by the French regulations for such
events was 170 feet AGL.
Source "Air Disaster" Volume 3 chapter 1

[stickyb]

A Big Red Button

Previous posters have suggested the equivalent of a big red emergency button, with , as one poster put it, minimal checks to make sure it was only activated on the ground.
Looking at that not from the pilots perspective but as someone who has to design and implement such computerised control systems it would seem to be a nearly impossible task. Even with today's advances in computing, you have to specify things in black and white, go/nogo, binary type decision trees at the lowest level.
So what criteria could you use to let the automation decide you were on the ground?
RA? not accurate enough. Wheel spin up to a certain speed? No good if aquaplaning. MLG compressed? Both or one? That's why AB does the partial spoiler extension to dump lift and get both MLG compressed - but that is itself switched out if one of the TLs is not at idle. Here we go round the loop again.
Wht I am trying to say is that a lot of thought already seems to have been put in to the area of deciding "on the ground", and it may turn out to be not good enough yet. But i don't see how a new emergency off system would be anything but a) a duplicate of parts of the logic already involved in the decision making process, and b) more complex than that which already exists.
Also remember that any hardware component can develop a fault. Both solid state and mechanical devices can wear out/breakdown.

[alph2z]

Interesting posts PBL and many others.

PBL
.....Of those (let us take it as) 55 million landings, there have been 3 in which some issue related to thrust control has resulted in an accident, with a total of 3 deaths (ground deaths, no passengers and no crew). These incidents are
* 22 March 1998, at Bacolod
* 28 Aug 2002, at Phoenix
* 18 Oct 2004, at Taipei-Sung Shan

Even if we suppose that TAM Congonhas on 17 July was an addition to that list, that is still less than one serious problem every 10 million landings......

Are you not forgetting:
S7 Airlines Flight 778
http://en.wikipedia.org/wiki/S7_Airlines_Flight_778

Fatalities...124
Injuries.......68

Also, how many Boeings have suffered similar auto-throttle accidents when compared to AB ??

.

[armchairpilot94116]

comforting statistics, BUT.....

Its comforting that after around some 55 million flights that throttle mis-adventure has only caused relatively limited casualties. However this is no consolation at all to those whos loved ones lost their lives because of such a fundamental and "simple" error ! No consolation at all.

[kurimaw]

is there any "computer bug" issue???

"pitot static" problem????

or just only a human error????


the incident happend in bacolod was related into a computer bug issue..

this new aircraft used by PAL(philippine airlines)used for only 6months..then later on...accident was happend due to A/T issue

[hetfield]

@alph2z

I mentioned the similiar s7 sibirian accident here as well. Anyhow the 310/300 has a completely different A/THR system compared to 320. It's working more like Boeing.

[SoaringTheSkies]

Looking at that not from the pilots perspective but as someone who has to design and implement such computerised control systems it would seem to be a nearly impossible task. Even with today's advances in computing, you have to specify things in black and white, go/nogo, binary type decision trees at the lowest level.
So what criteria could you use to let the automation decide you were on the ground?

I can't find the diagram right now, but has been linked to the thread: the decision of whether or not to allow ground spoilers and wheel breakes is exactly such a binary decision as you describe it. However, it's an inhibiting decision, if I read the diagram right: wait for all those binary factors to go TRUE before allowing the breaks system. In Warsaw, the missing factor was the 2nd sqat switch, here, it might have been the TLA of more than 22.5° (still no factual data afaik).
I think the "red button" suggestion was more along the line of "no matter what you (the airplane) think you should do, give me full manual control, i.E. let me manually deploy the spoilers. I understand that wheelbreakes override with the tip breakes.

RA? not accurate enough. Wheel spin up to a certain speed? No good if aquaplaning. MLG compressed? Both or one? That's why AB does the partial spoiler extension to dump lift and get both MLG compressed - but that is itself switched out if one of the TLs is not at idle. Here we go round the loop again.

Yes, and it's what might have happened here. If the logical formula for breaking is somewhere along the lines of
(BREAKES_ARMED AND WHEELS_SPINNING AND SQUAT_SWITCHES_DEPRESSED AND TLA<22.5°) (there were more factors) then one of the input factors being "FALSE" makes the whole expression false and thus does not allow breaking action? How about adding a OR OVERRIDE_BUTTON_PRESSED for the situations where the pilots have no clue what prevents the system from evaluating this expression to true but from their human, analog point of view, they've clearly touched down, want breaking action and have only limited runway left.

Wht I am trying to say is that a lot of thought already seems to have been put in to the area of deciding "on the ground", and it may turn out to be not good enough yet. But i don't see how a new emergency off system would be anything but a) a duplicate of parts of the logic already involved in the decision making process, and b) more complex than that which already exists.

It might - only might - make the pilot a part of those expressions. Specifically logic that inhibits desired behavior until all prerequisites have been met is something that should have an override switch. For several reasons. Everybody who has ever formulated a complex system in binary logic knows how difficult it is to put all allowable states into one, simplified expression and how even more difficult it is to specify all those states a propriori.

Also remember that any hardware component can develop a fault. Both solid state and mechanical devices can wear out/breakdown.

This is all being said by me as a no pro pilot who looks at those logic diagrams shaking his head. There's a certain level of arrogance in constructing such systems on the drawing board and thinking that they will include all possible states they will encounter later. In Warsaw, there was clearly a flaw found in the air-to-ground detection logic (requiring both sqat switches fully depressed before deploying ground spoilers) and in the case at hand, hypothetically, they might at least have left very little room for error.
I have not designed aircraft systems (thankfully, I doubt I could bear the responsibility) but I have worked with complex state machines for internet protocols. I remember that in one protocol (it might have been ppp) there's a state called "SOL" or "seriously out of luck". It is entered when the input just doesn't make any sense for the current state and it's used to reset the state machine to a defined state and continue.
The breaking and lift-dumping state machine of the AB seems to be designed without such a "reset" state. Again, from the diagrams, it sais "do nothing until all requirements are met". After the Warsaw accident, they've added a new state, "partially deploy spoilers". Why? because the inputs the system had back then did not meet the requirements to proceed to the next defined state, however, the physical airplane had long left the logical state the system thought it in and was no longer flying.
And in this case, again under the assumption that the root cause might have been a TLA>22.5° for the #2 engine, all signals were TRUE to go to state "on the ground" and activate breaking but this one. And an ambiguous one it is. The system remained in it's current state. Which would have contributed to the event.
It's been pointed out that out of 55 million landings, only a few ended like this one. Yes, but:
Every single event like this is too much, I don't think we'll have to argue that.
There are errors we will never be able to prevent. You can only have so many mechanical or electronical backup systems, there's always a chance that they all fail. But the logic behind the whole system should not have states where it's sitting like a dead duck, waiting for the next thing to happen, because you don't have a backup logic. The logic might be implemented in three different computer systems of two different brands in two different programming languages, it's still the same logic.
If there's a chance that a TL is malpositioned by human error (or mechanical error or sensor error) then that TL position must not be an absolute inhibiting factor for a vital system such as deceleration.
That's where the override button might come in handy, even if it might not be a big red "safe me, now!" button but an internal "SOL" state.

pj

[bsieker]

Brake override button

SoaringTheSkies (and others),

why would you suppose that giving the pilot an extra override-button to enable ground spoilers, wheel braking and perhaps thrust reversers, and idling non-reversed engines would make a difference for the better?

Statistics of human error rates are important here.

The error rate of leaving one TL above 20 degress (the exact definition of "at or near idle" was quoted somewhere in this thread) during flare has been shown to be extremely low. Mostly because it makes perfect airmanship sense to select idle thrust at that stage. One just does it without thinking about it. Almost always in these cases, routine is good.

Why would you assume that the error rate of someone inadvertently pressing an override-ground-stop button in the air would be even lower than that, given that it would be an extremely rare situation? Isn't it possible, even likely, that this may happen more often than just once every 10 million flights?

Conversely, what are the chances that the pilot will remember to press it, if he is already in a state of mind that he has forgotten to idle the thrust levers?

Either the "big red button" is on his mind during final approach, remembering that he has to press it when the aircraft won't decelerate, then there is a relatively high chance that someone will press it at the wrong time, plus, it is one more thing to remember, and take-off and landing are the most complex and demanding "normal" phases of a flight as it is.

Or it is not on his mind during final approach, then he might not think of it even when he needs it.

One more emergency procedure to learn and to remember for cases, in which a standard procedure, that is performed every single landing would help?

[atakacs]

@hotDog

I was referring to this crash http://en.wikipedia.org/wiki/A330_test_flight_crash

Lots of contributing factors but the critical one is that within the window of opportunity they had to regain control the tests pilots clearly did not fully understand what the plane was doing... And frankly any automation that will insist on reaching target altitude regardless of pitch angle and available thrust is questionable.

Anyway I believe that AB automation is very well thought out and implemented. I also believe there are rare cases where the pilots, especially in dangerous and stressful situations, don't fully understand the imbrications of all those otherwise neat systems. At that time the "panic" button might come handy...

[SoaringTheSkies]

bsieker,
I have indeed thought about how many accidents might have been prevented by some of the systems in place. Sadly, I doubt we'll ever get those numbers, as no accident, no investigation, no findings, but the low accident numbers we see show that an extremely high percentage of flights are completely inside the system's gamut and those systems are doing their job.
What scares me is that the system, upon leaving it's "field of known good states" does not necessarily err towards safety, partially maybe because it lacks the "understanding" that something awkward is going on.
Let's be very clear, the given input is, at best, ambiguous:
Wheels on the ground and (probably) spinning
RA 0
one TL in REV, the other probably somewhere between IDLE and CLB.
From that data, the system tries not only to match it's internal state to the physical state of the airplane but also to the pilot's intentions.
My understanding is that the only indication of the pilot's intention the spoilers/brakes system has is the TLA. One forward, one reverse doesn't give more clues than a bunch of tea leaves. At least not without any sequence information to it (which I can't see being used from the diagrams).
I have not brought up the big red button and I'm not fully certain that it would indeed make sense to have such a thing.
My point was: logic that inhibits vital functions like the spoilers/brakes logic must in all cases err to the safe side.
Now we could argue what the safe side is, as in the case of a TOGA, fully deployed spoilers would prove catastrophic as well.
Generally speaking, computers or binary logic will outperform humans in almost all cases, as long as the input pattern matches what was anticipated in it's design.
Humans will sometimes fail as well, when presented with unexpected situations, but at least they have a chance to analyze the situation, understand it and take action. Computers don't.
So, the big red button is more a figure of speech, to me, than an actual button. Trying to find a way for the pilot to say "I have no idea what's going on inside the logic system, but it's clear to me that it's not the way it should be, give me full manual control". A real red button like this could, I agree, probably cause more harm than good, though.
Maybe, however, it's a function of making the system aware that it's caught in a state due to ambiguous signals. I'm not sure if the logic diagrams are simplified or if the logic is really just an "AND" of all inputs. Both main gear squat switches depressed, wheels spinning, maybe even nose wheel spinning, RA 0, one TL in reverse, only one signal missing from the full equation, maybe the system could assume a malfunction there and drop the single illogical input from the equation? Maybe the equation would have to take into account the sequence of events? If the pilot was attempting a go around, the sequence of TL movements would be different from a landing with one TL left in CLB. Then again, adding even more complexity to the equations can't be good either.
pj

[DozyWannabe]

HotDog, I think Atacks was referring to the A330 crash which killed Nicholas Warner (AB chief test pilot) and all on board.

However it was an oversimplification - While mode-confusion did play a part (AP in altitude acquire mode caused excessive pitch up while low and slow), the accident was also due to PF over-rotating and PNF (Warner) being distracted by preparing the test conditions for the next approach.

It was this incident that got AB to change their tune on certain aspects of their system design (multi-function knobs being a no-no, for example).

[M.Mouse]

My Boeing instructor in Seattle:-"Autothrust off first then Autopilot". Not once on Boeing's have i seen autothrust engaged on landing during a manual landing. B727,B737-2,3,400, B747-200,400. The last time i flew a Boeing was 5 years ago so maybe times have changed.

Just for completeness and accuracy, in my company the B777 is flown with the A/T engaged at all times, including flare and landing. The reason it can be is that, unlike all previous Boeing models, there is no pitch/power couple - the aircraft retrims automatically with power changes.

[Dream Land]

That's where the override button might come in handy, even if it might not be a big red "safe me, now!" button but an internal "SOL" state.

You can't buy entertainment like this.

[SoaringTheSkies]

Dreamland

That's where the override button might come in handy, even if it might not be a big red "safe me, now!" button but an internal "SOL" state.

You can't buy entertainment like this.

I beg your pardon?
I thought I had stated quite clearly where I see a potential problem and that I'm not talking about a physical button but some kind of "tie breaker" to escape situations where the built-in logic fails for some reason.

pj

[bsieker]

Originally Posted by SoaringTheSkies

My point was: logic that inhibits vital functions like the spoilers/brakes logic must in all cases err to the safe side.

The problem with ambiguous inputs is that they are, well, ambiguous.

So if the aircraft doesn't know where it is, there is no safe side.

Deploying full ground spoilers during deceleration on the ground is what you want and need. However, in final approach or during a go-around it is potentially catastrophic.

Just consider the one engine commanded to near-climb thrust (if we assume this is indeed what happened here). Is it always the safe side to throttle it to idle? Or perhaps it is the safe side to put the reversed engine to climb thrust, too?

I'm also involved with trains and the logic there seems much easier. Almost always the "safe thing" to do is simply to stop (not an option with an aircraft). But even there, an emergency stop has to be deferred until after, say, a tunnel.

My point is, things are complicated, and every idea, however good it may seem, has to be thought through with all its consequences. And so far nothing has turned out to be a silver bullet.

[HotDog]

Takacs, sorry I assumed you were talking about A320s, which is the subject of this thread. However the magic button would not have worked in either case. Strangley enough, there is a red panic button in simulators that will freeze motion to stop the box from departing the hydraulic actuators in case of a possible input malfunction. Wearing seat belt harness was SOP in the sim with my company.

[SoaringTheSkies]

Just consider the one engine commanded to near-climb thrust (if we assume this is indeed what happened here). Is it always the safe side to throttle it to idle? Or perhaps it is the safe side to put the reversed engine to climb thrust, too?

From what the diagram tells me, this specific part of logic is just sitting there util the input disabiguates itself, or actually, there's the "retard" callout that should take the pilot into the loop but is auto-cancelled at some point.

So there you have a logical sitting duck, making no decision at all because of a single ambiguous signal.

pj