Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

TAM A320 crash at Congonhas, Brazil

Wikiposts
Search
Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

TAM A320 crash at Congonhas, Brazil

Thread Tools
 
Search this Thread
 
Old 28th Aug 2007, 01:04
  #1901 (permalink)  
 
Join Date: Feb 2005
Location: flyover country USA
Age: 82
Posts: 4,579
Likes: 0
Received 0 Likes on 0 Posts
Do we really think they are only human errors?...
Insanity: doing the same thing over and over again and expecting different results. - attributed (perhaps imprecisely) to Albert Einstein
barit1 is offline  
Old 28th Aug 2007, 09:13
  #1902 (permalink)  
 
Join Date: Jan 2001
Location: Dallas, TX USA
Posts: 739
Likes: 0
Received 0 Likes on 0 Posts
There are several contributing factors to this accident. While the discussion of braking method is very interesting, I think it's almost academic given that the ground spoilers failed to deploy in this accident, as several previous accidents demonstrate how ineffective braking can be on wet runways without ground spoilers.

My own focus has been on the fact that the ENG2 TL was left in CLB detent, which prevented the GS from deploying (thus minimizing the braking action), and adding forward thrust to a decelerating aircraft. My particular focus has been on why the pilots failed to retard the ENG2 TL, which to me seems central to this accident.

Regarding PBL's comments about Raskin, the A320 is a heavily computerized aircraft, the first of its kind (FBW) in airline operations. The rest of the A320 family, the A330, A340, A380, 777, and 787 have since followed it into airline service. The very fact that all primary control inputs are feed into and processed by a computer makes Jef Raskin's Human Interface Design Rules for computers extremely relevant in my view. If a joystick for primary flight control input isn't a computer interface subject to HMI design rules, I don't know what is. On the A320, thrust levers also provide primary control input to a computer and are processed. While "modes" can be made to exist in mechanical controls, they are primarily the creation of computer programs, where the programmer determines what the control inputs mean, and how they are processed. This is the main reason why some set of Human Machine Interface Design Rules are needed when writing control interface programs, because without the disciplined guidance of design rules, a programmer could write anything (from good to terrible) as a control interface.

Regarding how the pilots interacted with the A320 throttle system in this accident, and given that the failure to retard ENG2 TL to idle caused everything to go wrong during this landing rollout, I'm going to try to put myself in the cockpit (as uncertain as this may be) during the landing.
As we know from the CVR transcript, both pilots were aware of the runway length and conditions (wet and slippery). Both were aware that ENG2 TR was inop. They briefed each other on these things, though some have correctly posted that the briefing was not extensive and did not include a concise plan of action.

My own opinion is that fear (and it relatives like anxiety, etc), cause the narrowing or tunneling of mental processing that's been discussed often in this thread. Fear seems to create a narrow focus on the circumstances causing the fear. But this narrowing focus seems to also include a kind of mental "load shedding", where the mind seems to "select out" anything in the environment that doesn't seem relevant. A fear response also seems to move more towards a "fight or flight" physical action based response, and away from higher levels of mental reasoning as a response. As others have pointed out, hearing seems to be one of the first things "selected out".

As these pilots neared touchdown, a couple of interesting things happened. First, the "retard" callout began about 5 seconds prior to touchdown. Then, 3 seconds after the retard callout started, one of the pilots pulled the ENG1 TL back to idle, but left the ENG2 TL in the CLB detent. Why was the "retard" callout ignored and why leave the ENG2 TL in the CLB detent? Or was the "retard" callout actually responded to by a pilot who simply pulling the ENG1 TL only back to idle? It's possible the pilots actually responded to the "retard" callout by pulling the ENG1 TL back to idle. However I think the reason for selecting ENG1 TL only to retard, was because the pilot who did this wanted to get the ENG1 TR deployed as soon as possible after touchdown, which in fact he did.

However these actions may already show some cognitive narrowing due to anxiety over landing in these conditions. Instead of pulling ENG1 TL only back to idle, they should have pulled both throttles back. They also should have delayed the deployment of reversers (or the one good reverser) until confirmation that the spoilers were deployed, otherwise brake performance would be abysmal. What the pilot did was a more action oriented response (get that reverser out ASAP) rather than a more reason oriented response (pull both TLs back, wait for touchdown, wait for spoilers, deploy TR).

Three seconds after touchdown, the callout was made that there were no spoilers. If the anxiety level was pucker factor 3-4 on approach to landing, the realization and callout 3 seconds later that there were no spoilers, must have created immediate pucker factor 10 for both of these very experienced pilots, who knew exactly what no spoilers meant in those conditions. At pucker factor 10 the cognitive reasoning would have been narrowed greatly, as we know they never figured out in the 16 seconds from that callout until impact, that they needed to retard the ENG2 TL to have a chance at stopping (or a much lower speed overrun). In those 16 seconds, the responses all seem to be action based, "decelerate", "it can't", "oh my god", "turn, turn", rather than reason based, "why are there no spoilers", etc. Nothing against these pilots for what happened, as I think this is human nature that all of use are subject to.

Now to conclude my argument that the multimode throttle system in the A320 may have played a role in this accident, I would argue that since auto throttles is used a lot during the gate to gate time of an A320, the mode (or state) of "thrust lever angle DOES NOT equate to engine power" is probably the predominate mode (or state) of the throttle system while pilots are operating the A320. This however in not the mode (or state) used when the aircraft is on the ground, where trust lever angle DOES equate to engine power, and where the ground spoiler system thinks it does as well. The whole idea behind a single mode primary control is that the action and responses of that control are so consistent and predictable, that using the control becomes a habit so that one no longer has to think about or mentally process how that control functions. This is what Jef Raskin meant when he said you can "habituate" the control, if it’s modeless.

However it's not possible to fully "habituate" the function of the throttle system of the A320, because it has multiple modes. This means you have to think about how it functions at times. In the circumstances these pilots were in after touchdown, they apparently were not in a condition to notice (however I still wonder what “look this” was referring to in the transcript) or think through the meaning of the ENG2 TL position. My argument is that if the throttle system had been single mode in the sense that throttle lever position ALWAYS equated to engine power, then you wouldn't have to think about how it worked when you're in a situation where it's hard to think. It's very possible the pilots could have noticed and acted instinctively (meaning to act without thinking) to pull the ENG2 TL back. At pucker factor 10, performing actions is about all you can do.

Would a single mode throttle system have saved the day in this accident? I don't really know, but I do think it would have increased their chances.

Last edited by Flight Safety; 28th Aug 2007 at 09:26.
Flight Safety is offline  
Old 28th Aug 2007, 10:13
  #1903 (permalink)  
Per Ardua ad Astraeus
 
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Flight Safety
They briefed each other on these things, though some have correctly posted that the briefing was not extensive and did not include a concise plan of action.
- unless you have access to more of the CVR than we do, you cannot say this as fact. To avoid the howls of anguish, I DO hope they would have briefed fully, and EXPECT they did, but there is no available confirmation, so we do not know the briefed 'plan' for a wet and slippery CGH near max weight - if there was one, nor of any reminder about 'special' procedures. E.G. It is JUST possible that the 'inhibit GS' call took P2 a bit by surprise too?
BOAC is offline  
Old 28th Aug 2007, 10:20
  #1904 (permalink)  
 
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes on 0 Posts
Flight Safety,

as has been eloquently laid out by PBL, (have you bothered to read the paper he mentioned and done the exercise?), flat state spaces will not work for avionics systems as complex as are required to fly modern airliners.

As to the workings of the thrust levers: it is really terribly simple, and a confusion very unlikely:

In a normal flighth you really only need three positions. This flight was no different:

- FLX/MCT (or possibly TOGA in certain conditions) from takeoff to thrust reduction. This gives flexible (or maximum) take-off power and arms autothrust.
- CL throughout the entire flight from thrust reduction to flare. This activates autothrust, previously armed by setting (flexible or maximum) takeoff power.
- IDLE during flare.

During rollout you additionally may use REVERSE IDLE and MAX REVERSE.

I do not see at all why this would not be habituating. I fyou fly at autothrust, you leave the thrust levers alone, if you require manual thrust, you disconnect autothrust (thumb-pushbutton at the side of the levers, aptly named "instinctive disconnect") and move the levers as required. Simple.

And to repeat the argument agains the assertion that it is great that the thrust levers always equate to engine power: that can be so habituating that one might fail to realise that it is not true in case of an engine failure (there have been examples, cited just recently in this thread). Being used to looking at the instruments to gauge engine parameters instead of the levers, helps.

That is not to say that either design philosophy is inherently better than the other, but (again) to point out that it isn't that easy.

To strain the car metaphor again: some older cruise control systems actually moved the accelerator pedal, but many modern ones don't. A side-effect of "FADEC" for cars. Will that confuse the driver?

Bernd
bsieker is offline  
Old 28th Aug 2007, 10:49
  #1905 (permalink)  
 
Join Date: Sep 2001
Location: Toronto
Posts: 2,558
Received 39 Likes on 18 Posts
To strain the car metaphor again: some older cruise control systems actually moved the accelerator pedal, but many modern ones don't. A side-effect of "FADEC" for cars. Will that confuse the driver?
The cruise control for my car is the non-moving gas pedal type like many others. There are times I have forgotten it's still on when the car accelerates by itself and I have to choose to accept the acceleration or cancel it

However the engine goes down to throttle off when I put in the clutch or touch the brakes -- something that may have helped at Congonhas.

Also there's only one engine.
RatherBeFlying is offline  
Old 28th Aug 2007, 10:55
  #1906 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Flight Safety
The very fact that all primary control inputs are feed into and processed by a computer makes Jef Raskin's Human Interface Design Rules for computers extremely relevant in my view.
The reason I keep harping on about this is that there seem to be quite a few people on this forum who think that they can design and analyse HCI to control systems, without showing that they have any interest in the rather large engineering literature on such things. So we see the same sophomore-level arguments. Your suggestion is not one of those, however; it actually references the literature. And is therefore worth thinking about.

Its weakness is that it has a simple refutation, which I indicated.

There are a few hundred researchers, and a few thousand HCI professionals, in the world who spend their time thinking about such things. They hold conferences. If you think that your view has merit, and that it has been somehow missed by the HCI community (most of whom are very well aware of Raskin's work), then I suggest you write it up and submit it to one of those conferences for peer review. It will go to someone to be refereed who knows about interfaces to control systems.

It will probably come back with a two-sentence refutation similar to mine (unless it comes to me, in which case it will be identical with mine).

There are also some things wrong with your further chain of reasoning.

Originally Posted by Flight Safety
While "modes" can be made to exist in mechanical controls, they are primarily the creation of computer programs, where the programmer determines what the control inputs mean, and how they are processed.
There is an equivocation hiding in here.

A mode is exhibited when a control action results in one function F in environment A, and a different function G in environment B. The values of the environmental parameters A and B define the mode under some suitable way of saying what parameter settings are equivalent.

When you command thrust reverse on a B767 in flight, you don't get thrust reverse. So a mode is exhibited: let us call them "GROUND" mode and "AIR" mode. This mode change is accomplished through an interlock. Interlocks have been around since whenever, and in mechanical systems this is one of the words that is often used; there are others.

But "mode" itself is a word which came into use to describe the different sets of environmental parameters which were sensed to determine what function F was executed, when digital computation started replacing mechanics and analog-electrical control. So people tend to think that "modes" come with digital computation, whereas they were around long before. It is, however, true that modes became more prevalent with the advent of digital control. This is because (to say it again) they are how one controls the complexity of the state space.

In software design for other uses, one speaks of "hierarchical decomposition". There is no other known way of controlling the complexity of the state space. Some control-system specification methods, such as Statecharts, which has been prevalent in the aviation industry since David Harel proposed it a couple decades ago for use by IAI, actually rely on modes as the main design function. Statecharts specify hierarchical state machines, and that word "hierarchical" means that you have modes, at least in the innards of the design. Since the user of such systems also has a complex state space, modes bubble through inevitably to the user interface. Other systems such as Lustre, the basic specification instrument for SCADE, also involve hierarchical state machines.

So modes are basic. You don't have to like them, but if you are advocating that people drop them, it becomes incumbent upon you to suggest how the systems can be designed without them.

If you want a flat state space, you could always just go back to B727-like controls but implement them electrically, such as in the back-up direct-law control to the B777 FCS. But no one would buy your airplane. They wouldn't just not buy it because it was old-fashioned. They wouldn't buy it because the generation of airplanes with digital control systems has by and large a statistically significantly better safety record than older generations, and most people who buy these airplanes think it has something to do with the digital control and flight management systems.

without the disciplined guidance of design rules, a programmer could write anything (from good to terrible) as a control interface.
That suggests an inappropriate view of how these systems actually become implemented. Crudely put, modern control systems are written by designing state machines on your screen and "pressing the button" to have code come out. No programmer using these systems can just "write anything". And programmers don't write control interfaces. Control interfaces are designed by HCI specialists or engineering psychologists or whatever you want to call them, and are evaluated directly as well as derivatively through many thousands of hours with test pilots in simulations. And then these designs are passed on to the design engineers who put them into the CAD system and then "press that button" to get the object code.

One is free not to like modes, but there is no better alternative for these applications. If you want to give up modes, you will also give up functionality. That is a hard technical constraint, and is the reason why no control system design engineer will listen to you if you try to persuade himher to go modeless.

PBL

Last edited by PBL; 28th Aug 2007 at 11:14. Reason: Grammar
PBL is offline  
Old 28th Aug 2007, 12:39
  #1907 (permalink)  
 
Join Date: Aug 2007
Location: Brazil
Age: 71
Posts: 131
Likes: 0
Received 0 Likes on 0 Posts
Al Zimer,

I understood from the CVR's tanscripts that was the PF who said (@ 18:48:33) "Look this!", and not the PNF (or pilot monitoring). And this is what puzzles me. Please, follow me on this: I believe almost everybody here agree that the PF (pilot flying) is looking out, at the runway, during the flare (18:48:21).
Especially on this flight, touchdown on the right spot is crucial. Let's imagine the pilot will continue looking out during touchdown (18:48:27). So I believe the PF is still looking at the runway when he gets the call "spoilers nothing!" (18:48:29).

Where I'm trying to go is: The pilot flying has his eyes out to the runway, and has his hands (and feet) on the controls. So it's not hard to imagine that when he says "Look This!" (18:48:33) , can only be two things: 1- Something ABNORMAL he sees outside (I don't think so) or, 2- Something ABNORMAL he feels on the controls.

Now, let's imagine he had his right hand on only one TL (left). He reduced this TL to idle, then reverse. It worked fine, so what he "felt" on the controls that was so ABNORMAL, to the point he exclaims "look this"?

Let's imagine now that he had his right hand on both TLs and he is looking out to the runway. He reduced both TLs to idle, but "feels" something ABNORMAL with the TLs, thus the exclamation "Look this!"

His exclamation (look this) really puzzles me. If this exclamation had come from the pilot monitoring, this could mean many things. But coming from the PF, in a critical phase of flight when the PF is "only" looking out to the runway and "feeling" the controls, this tells me something happened with the TLs.

Thanks for your patience.

Rob
Rob21 is offline  
Old 28th Aug 2007, 12:59
  #1908 (permalink)  
Paxing All Over The World
 
Join Date: May 2001
Location: Hertfordshire, UK.
Age: 67
Posts: 10,150
Received 62 Likes on 50 Posts
(non pilot speaking)
Flight Safety
(however I still wonder what “look this” was referring to in the transcript)
Indeed. I have said it before in this thread: The need for video cameras on the flight deck is growing. It has been proposed that one camera is mounted centrally to look at the pilots and that another is placed in the roof looking down onto the central quadrant (as I believe it is called). The information would be digital and stored along with all the other data.

Sampling rates would have to be very high to catch every flick of a switch. In this case (if the data was readable) we would see what they were pointing at and the truth about the thrust levers.

I understand that many pilots were against the introduction of CVR but these are now accepted as being helpful in saving lives. Cameras will follow this route.

PBL's excellent setting out of 'Modes' made me remember that we all operate in Modes every minute of the day. Sometimes these come into conflict and/or confusion. We might be doing our regular job but, when we walk out of the office we change Mode.

If your work is to be a teacher, you may have to exert discipline towards a student, even when your own Mode is pushing you to act like a parent. You have to decide which Mode is in force and balance them, perhaps using some experience as a parent to be a better teacher. If you are walking in the High Street as a parent but a student greets you - you have to partially change mode.

Now, I appreciate that flight Modes are exclusive to others Ground OR Air - not half and half but I thought that introducing the Human Modes (which are usually mixed!) might remind us of how we all live in Modes and constantly move between them.
PAXboy is offline  
Old 28th Aug 2007, 18:31
  #1909 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Marciovp,

Originally Posted by marciovp
The Airbus software that TAM is going to buy and install in all A320s is called FW3.
I am not aware of that form of designation in AI products. But I don't by any means know them all. Do you (or anyone) happen to know to what kind of object it refers?

PBL
PBL is offline  
Old 28th Aug 2007, 19:44
  #1910 (permalink)  
 
Join Date: Jun 2002
Location: Geneva, Switzerland
Age: 58
Posts: 1,907
Received 3 Likes on 3 Posts
If you want a flat state space, you could always just go back to B727-like controls but implement them electrically, such as in the back-up direct-law control to the B777 FCS. But no one would buy your airplane. They wouldn't just not buy it because it was old-fashioned. They wouldn't buy it because the generation of airplanes with digital control systems has by and large a statistically significantly better safety record than older generations, and most people who buy these airplanes think it has something to do with the digital control and flight management systems.
You most certainly have much more expertise in this field than me but you will have a hard time making me believe that no one would buy an A320 because it's T/L are fitted with motion feedback mechanisms...

I would even venture that regardless of the pontification about the HCI community and the supposed irrefutable quality of the AB FWB software I'm rather convinced that there are common sense improvements that could be at least considered to improve those systems which I still see as contributing factors to this tragic - and not unique - accident.
atakacs is offline  
Old 28th Aug 2007, 19:59
  #1911 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by atakacs
regardless of the pontification about the HCI community and the supposed irrefutable quality of the AB FWB software
Sorry, I've missed that. To whose comments are you referring?

PBL
PBL is offline  
Old 28th Aug 2007, 20:43
  #1912 (permalink)  
 
Join Date: Jun 2002
Location: Geneva, Switzerland
Age: 58
Posts: 1,907
Received 3 Likes on 3 Posts
Originally Posted by atakacs
regardless of the pontification about the HCI community and the supposed irrefutable quality of the AB FWB software
Sorry, I've missed that. To whose comments are you referring?
I have a very strong feeling (partly induced by reading your otherwise excellent posts) that the FWB community response to the Congonhas crash is "those guys goofed up big time and there is not a single thing we could improve in our FWB software. Actually if you think otherwise then your are incompetent in this field, hence unqualified to discuss it."

Don't get me wrong, I don't want to start any kind of flame war. It's just that I am seeing too many posts in this thread that point in the above direction.

Let me reiterate that I am pretty much convinced that this tragedy raises many valid questions about HMI and that they deserve consideration and possibly action. I might be wrong but I feel like they are not addressed and might not be in the future.
Just my 2c anyway

Last edited by atakacs; 28th Aug 2007 at 20:43. Reason: typo
atakacs is offline  
Old 28th Aug 2007, 20:58
  #1913 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
atakacs,

OK, thanks for the clarification. I was concerned that you might be misinterpreting some of my interventions. My comments on software, modes and state spaces concern (obviously, so I hoped) the technology of digital control systems and are independent of manufacturer.

PBL
PBL is offline  
Old 29th Aug 2007, 00:20
  #1914 (permalink)  
 
Join Date: Aug 2003
Location: Sale, Australia
Age: 80
Posts: 3,832
Likes: 0
Received 0 Likes on 0 Posts
From AIN
Brazilian Aviation Agency Losing More Leaders
The leadership of Brazil’s Agência Nacional de Aviação Civil (ANAC) is collapsing under the pressure of international criticism. ANAC director Jorge Brito Velozo, formerly of the Departamento de Aviação Civil, will resign today, and president Milton Zuanazzi is expected to resign by the end of the week, according to Adalberto Febeliano, executive vice president of the Associacão Brasileira de Aviacão Geral (Brazilian Association of General Aviation). The two resignations follow last Friday’s resignation by ANAC director Denise Abreu. The agency has been under intense scrutiny, Febeliano said, following the 2005 bankruptcy of Varig Airlines, last year’s Gol 737/ExcelAire Legacy 600 midair, the air traffic controller strike early this year and the TAM crash at Congonhas Airport in July. “Everyone was under criticism after those four large events,” Febeliano told AIN. “The public, especially the large media, wanted them to be guilty. They pointed their fingers at the agency the same way they pointed their fingers to the Legacy pilots last September. It is really more a matter of public pressure than of real mismanagement.”
Brian Abraham is offline  
Old 29th Aug 2007, 00:28
  #1915 (permalink)  
 
Join Date: Sep 2001
Location: 38N
Posts: 356
Likes: 0
Received 0 Likes on 0 Posts
“The public, especially the large media, wanted them to be guilty. They pointed their fingers at the agency the same way they pointed their fingers to the Legacy pilots last September. It is really more a matter of public pressure than of real mismanagement.”
When you need a scapegoat, the folks in charge of the process which has gone wrong are pretty good candidates, eh?
arcniz is offline  
Old 29th Aug 2007, 00:36
  #1916 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
I have a very strong feeling (partly induced by reading your otherwise excellent posts) that the FWB community response to the Congonhas crash is "those guys goofed up big time and there is not a single thing we could improve in our FWB software. Actually if you think otherwise then your are incompetent in this field, hence unqualified to discuss it."

Don't get me wrong, I don't want to start any kind of flame war. It's just that I am seeing too many posts in this thread that point in the above direction.

Let me reiterate that I am pretty much convinced that this tragedy raises many valid questions about HMI and that they deserve consideration and possibly action. I might be wrong but I feel like they are not addressed and might not be in the future.
Just my 2c anyway
I agree

This is not the first nor probably the last time that we will argue that a perfectly sound system has been screwed up by the unanticpated actions of man.

But can we or should we continue to argue that the screw ups are unanticipated? Was this accident really a surprise?

will the next one with all the same ingredients be a surprise?
Will the investigation stop short of looking at the man/machine interface and the smoke trail pointing at the precendents to this accident in numerous previous similar events?

Where was the regulator in their review of the previous accident/incidents with all the same similarities? Could we not see that a catastrophe was coming?
lomapaseo is offline  
Old 29th Aug 2007, 02:40
  #1917 (permalink)  
The Reverend
 
Join Date: Oct 1999
Location: Sydney,NSW,Australia
Posts: 2,020
Likes: 0
Received 0 Likes on 0 Posts
the central quadrant (as I believe it is called
It's called the pedestal. Cockpit cameras would not have prevented this accident and could equally happen on a 737 if the pilot retards just the one thrust lever after touch down.
HotDog is offline  
Old 29th Aug 2007, 03:34
  #1918 (permalink)  
I support PPRuNe
 
Join Date: Jul 2007
Location: Belo Horizonte, Brazil
Posts: 162
Likes: 0
Received 0 Likes on 0 Posts
FM3

PBL said: I am not aware of that form of designation in AI products. But I don't by any means know them all. Do you (or anyone) happen to know to what kind of object it refers?
The press in Brazil published widely the news that TAM was going to install the new software from Airbus named FM3 in all its planes (US$5000.00 a piece)

See here in Brazilian Portuguese:

http://www.estadao.com.br/estadaodeh...imp34988,0.php

It says that TAM was going to install this software in all planes. That Airbus had produced it but instructed that it was a "desirable" software not a "mandatory" one. It will warn the pilots in sight and sound when the two TLs are pointing to opposite sides as it seems to have been the case with the disaster A320.

Sorry, this is as far as I could go. But will keep an eye on it.

Going back to my road analogy...just a little modification. We have three accidents in a road turn with a specific brand of automobile. Of course there is human error involved...but we would not look at that specific automobile to see how it could induce or make it more possible the human error?...

Just pushing the issue... (should I go back to my Cherokees?...)
marciovp is offline  
Old 29th Aug 2007, 03:41
  #1919 (permalink)  
I support PPRuNe
 
Join Date: Jul 2007
Location: Belo Horizonte, Brazil
Posts: 162
Likes: 0
Received 0 Likes on 0 Posts
ANAC

Just for the record, ANAC (National Agency of Civil Aviation) on being investigated showed that with a few exceptions most directors were political appointees who knew nothing about aviation. That many of these directors accepted a large number of airline tickets from the companies they were suppose to regulate and...a bizarre thing: when a federal judge decided to close Congonhas for being unsafe, one director brought to the judge a regulation that said that no airplane should land in Congonnhas with one reverser locked up. With that documento the judge liberated Congonhas...but... the regulation never was made official. It seems clear that instead of regulating the airlines they were working with them, and receiving favors from them. This is why they are in the news. I don´t see scapegoating here.
marciovp is offline  
Old 29th Aug 2007, 08:30
  #1920 (permalink)  
 
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Sdruvss
No one answer me?
What is behind the logic of not deploying armed spoilers, even after manual braking is applied, if TLA is not in idle? I don't understand that. Please, I would like to understand.
I think this is a very good and valid question. I have also discussed this with PBL, and we made the following observations (PBL, feel free to correct me):

1/ Using manual braking alone as a signal to deploy ground spoilers will not work, as brakes may inadvertently be pressed in flight when making rudder inputs.

2/ Combined with any of the "on-the-ground" conditions (wheels spinning or (MLG struts compressed and RA <6ft)) it looks like a good idea. We'd still need to consider the late-go-around ("touch and go") scenario, in which rudder inputs may be needed, and brake inputs may occur, and ground spoiler deployment would be fatal.

3/ We consider it useful, as a previous poster said (I'm sorry I can't remember the name), to think of the thrust levers as "Stop"-levers. I want the aircraft to stop: I pull the thrust levers back. Although they are not really brake-levers, they work as such after touchdown: they are the only directly flight-crew-controlled inputs to the ground-spoiler extension logic, which in turn activates automatic braking.

The "LOSS OF BRAKING" memory item has as the first point after "If no braking available" (when using manual brakes):

REV ...... MAX

I have remarked before that it looks like the crew in this accident did not think they had "lost" braking, and did not fully and immediately apply the memory item.

It is also a question of whether or not they considered the less-than-satisfactory performance of the manual brakes to be "No braking available", in which case they would have gone to the next item on the list(REV: MAX), and taken a second look (touch) at the thrust levers.

I had asked experienced A320 flight crews for what situations exactly said memory item was trained:
  • Only failure of autobrake after it had initially been active?
  • And/or failure of manual brake if no autobrake was selected?
  • Also in a case like this where autobrake fails to engage because of failure of GS deployment?

For the third case the memory item would to be more aptly called "NO BRAKING"

As has also been suggested, it might be useful to do some data mining through collected flight data (properly anonymised) to find out how often one T/L was "forgotten" at a position above "near idle" without dire consequences.


---

Originally Posted by marciovp
Going back to my road analogy...just a little modification. We have three accidents in a road turn with a specific brand of automobile.
This one doesn't hold water.

1/ This is the first such accident at this corner (airport)

2/ there have actually been more accidents of this kind with the other brand of car, than the one involved in this accident: there have been more runway excursions on landing with B737-300/400/500 than there have been with A320, as shown by PBL in post #1316 (p.66).

So this is like saying: A Mercwagen has crashed here, so let's look at what is wrong with Mercwagen cars, when in fact more BMGs have crashed in the same way. But still people insist that there is something wrong with Mercwagen, but not so with BMG.

Bernd
bsieker is offline  


Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.