TAM A320 crash at Congonhas, Brazil

[hetfield]

@all

Be carefull to criticize CVR and/or FDR data have leaked to a public forum.

I've been banned from the TMA thread for doing this.

[bsieker]

Originally Posted by flyingnewbie10

I am no specialist,

Yes, we have noticed. And then please don't try to apply your knowledge from a completely different domain.

but where you read IRQ please read it as any circuit that handles asynchronous I/O, meaning that processing of I/O signals is not synchronized with all the FADEC scheduled processes , but rather is done through interrupts that call a specific function only when an I/O is performed, be it a small controler in a PC or a more complex device in a mainframe.

No asynchonous I/O on safety-critical real-time systems.

No multitasking/threading, either.

Avionics hardware bears no resemblance to either PCs or Mainframes.
Don't think Avionics software development is anything like "normal" software development, or that the structures are even remotely similar.
And don't assume avionics software developers are stupid enough to use async I/O or something as utterly useless (because essentially unverifiable) as pre-emptive multitasking. It is not done.

Please, before you try to apply your knowledge of how business/office software is "created" to the development processes of real-time safety critical system, learn something about the methods and techniques involved. Your skills and experience simply don't apply here.

No offence intended, but avionics software engineers know this stuff. You obviously don't even know the basics of real-time systems.

[bsieker]

Originally Posted by armchairpilot94116

3. Close Congonhas to jets the size of A320/ 737 and only allow planes with proven shorter runway requirements for landing and take off. And hope for the best.

A320 and B737 have proven stopping distances short enough for Congonhas. This was a freak accident that couldn't be predicted. Despite what all the whistleblowers will now try to tell us.

Or you mean only "stopping distances proven to be within 1900m with one engine at 75% N1 and with no spoilers?". Btw, as has been shown, the accident aircraft probably had a "provable" stopping distance short enough even in this failure scenario. (It remains to be seen if the brakes could have taken the amount of energy. I would try to calculate it, but would need mass and material (specific heat and maximum operating temperature) of the brake disks, and thrust force of the #2 engine for that.

4. Complete rezoning of the areas around the airport. Yes knock down buildings, rezone the whole area by government edict. Build that 10,000 foot runway (12,000 is no doubt better, everyone likes 12,000foot runways) and put in recommended RESA with EMAS. Make Congonhas state of the art. And hope for the best.

12,000'!

Yay!

Bring in the B747, the A330/340, the B777, he A380!

12,000' is even long enough for Concorde! Too sad she's not flying any more.

You know that this is what's going to happen, as soon as you have a longer runway.

Only shifts the problem.

[bsieker]

[...] the right TL idle detent,

Just a minor clarification: the IDLE position has no detent, it is merely a stop.

So it can happen when coming out of reverse, that the thrust lever is inadvertently moved to a few degrees above idle. The FCOM warns to look out for that possibility to avoid taxiing with excessive thrust (which could cause brake-overheating).

. At taxi speed:
- THRUST levers ........ FWD IDLE
[...]
When deselcting REV, be careful not to apply forward thrust by moving the thrust levers beyond the FWD IDLE position.

This is also perhaps one of the reasons why the ground-spoiler extension logic allows the thrust levers to be above idle.

[slip and turn]

Originally Posted by bsieker

Don't think Avionics software development is anything like "normal" software development, or that the structures are even remotely similar.

I am not as sure as you bsieker. I once worked in a City financial in-house development team where the team leader cut his teeth in Avionics software development. He just saw it as an interesting earlier step on the same ladder career-wise. He spoke of development of code around triple circuit voting, with logic gates very much like those already described long ago in this thread, and also that each of the three parallel voting circuits on the 'more important' systems would likely rely on a different chip e.g. a Motorola on one, a Siemens on another ... and same for other hardware to ensure uniqueness in each circuit, but there are always economic limits, and triple circuitry or not, it all has to come together in one place at each end of each system/sub-system (or sooner according to design?). So I think flyingnewbie10 has a valid query until someone shows us exactly how the system under review works and copes differently.

The test teams might well be creative and competitive in designing Use Cases to trip up the main development team, but again there are obviously economic limits to this.

It is always easy to say this pilot or that pilot is the component outside the documented envelope on the day, and that therefore no Use Case was considered in the development of the aircraft system to deal with what happened, but until pilots are not part of the overall system, that is not a valid argument at all. Pilots are still a trifle more complex than the aircraft they fly so it is incumbent on developers to make damned sure the interface can manage ALL the Interrupt ReQuests, or lack thereof, OR can and DOES abdicate to the Pilot in an immediately recoverable failsafe fashion.

Hence the talk of the big universal RED BUTTON earlier in the thread also, just in case that last part does not compute fast enough.

[PAXboy]

armchairpilot94116 As to 'options' at the field ... within a couple of days of the event, the politicians said that they would choose a new field and build a new airport. They even said that that they would select the location within 90 days. That is, almost certainly, not going to happen. Even if they wanted to build a new field, to select the location in 90 days would be irresponsible. There are already enough airports in the world that are built on unsuitable ground and in unsuitable locations and they took time to select those places!

If you ask the local population now, they will want a new field. If no new field is built, ask them again in five years and they will probably be happy with the convenience of the field being so close to town. London Heathrow has the same situation, as the town has grown up around it.

Until we see the report (probably two years from now) it is not possible to know if this is, indeed, a highly improbable (but sadly true) accident that is likely to be a one-off. Most accidents are one-off. The question will be if this fitted a patten and is it a patten that can prevented from repeating.

[NigelOnDraft]

Congonhas has several options: ....... Say restrict planes with T/R inop from operating there

Another marvellous idea! Ban BAE-146s etc. - nice short field aircraft, but banned since they don't have T/R

T/R Inop is an MEL/Performance issue... and as been pointed out here (and I had to be corrected), 1 x T/R Inop does not affect Ldg Dist calcs wet/dry. It does when more contaminated... so why invent more rules

2. Keep everything per above but add EMAS to all runway end zones as well as alongside the entire length of the runways. JUst EMAS every possible area as much as possible. And hope for the best.

Another excellent idea.... errr except the runways extend lengthways as far as possible, so you can only put EMAS in by reducing TORA/LDA... and I think you'll find the EMAS when taxied over (you know - the taxiway things that come off the side of runways) will not look too pretty

Let's get this into perspective. CGH is perfectly legal for A320s as it is, performance wise. Many operate in and out all the time. With / without T/R Inop. There has been a major accident which professionals will investigate. But the fact it went off the runway at ~100kts shows clearly it was not due to a "marginal performance issue", but some major factor(s) - almost certainly factors since most accidents have a chain which regrettably did not get broken.

NoD

[bomarc]

there is some truth in what nigel on draft has posted above.

but, we have a moral responsibility, at least in my mind, to try to not have people killed while on airplanes.

we can sacrifice a plane (air france toronto was destroyed, but everyone lived)

we can sacrifice a building

but not the people.

While we might all understand the ramifications of a short runway on a plateau, we are pilots and can choose not to land somewhere (granted we might lose our jobs).

passengers just by a ticket and trust that responsible parties do the righ thing.

I would bet money, that in the next ten years an airliner will go off the end of the runway somewhere on earth, and that additional precautions could save lives.

I am of the opinion that the industry and governement should take these precautions.(outlined above many times) And we as pilots should simply say, NO, to no thrust reversers at certain airports...and not on the basis of calculations...but instead on our own abilities and opinions. (certainly some will be fired for saying no to kiad or even edwards AFB)

safety must be in depth...if there are MORE holes in the swiss cheese, you have fewer safety options.

add them up. TR, EMAS, Grooves, no plateau...go for landing

start to lose the above and time to be cautious
---
someone mentioned the BAE146 and short runways...great plane for short fields...but I wouldn't take it into an icy covered runway like KDCA. Why? NO TR's.

[TripleBravo]

I would ask you about the detents. Is there any "diferentiated" device to check if the TLs are passing by them ? Do they serve to "interpolate" or "calibrate" the intermediary TLA readings ?

As far as I read the wiring schematic correctly, no, it's just analog position sensors and I have not looked into AMM or MPD on the calibration intervals. (Remember, both FADEC channels worked correctly at takeoff.)

Yes, a dual failure of a RAID5 backup system is remote, and it is not completely impossible that an aircraft system quits working also but we are talking about another planet when it comes to safety critical circuits. Your computer hardware wasn't tested literally months nonstop (!) by automated test equipment with almost every input combinations and analog voltage variations mathematically possible, which is just one test stage of many.

Unfortunately I am no expert when it comes to which Atmel / Motorola / Intel / Whatever does what at signal level and even when I found out it would be confidential. Please don't ask me for further details on electronics. Since I only want to put valid statements here and avoid speculations, this is beyond me but for sure looked into by the investigators.

[bsieker]

slip and turn,

Yes, I am aware that even avionics system design is done by humans, and such software is complex enough that there will be errors.

And as in any economic enterprise there are limits and budgets, but at least the big players (A and B) are very aware that delivering faulty software in ciritical systems will cause much more loss than budget cuts can save.

I was also not only talking about the development process but the software itself, which is a completely different beast, from, say, customer relation management.

Flyingnewbie may be experienced in software development, but I think he has little or no experience in embedded real-time system development for safety-critical systems.

Having said all that, no-one can say for certain that there was not a software-failure involved, but the chance is so remote, that even the unexplicable gross error of the pilot seems much more likely, particularly given the two precedents.

The point of an accident investigation, however, is not to give anyone "the benefit of the doubt", or to blame anyone, but to find out the most probable reason why it happened, and, ultimately, and most importantly, to prevent it from happening in the future.

Giving the pilots "the benefit of the doubt" is not helpful, if there is a chance that they did indeed commit this mistake, even if we cannot explain it (yet).

We must then, if it turns out to be a likely explanation, accept it, and look for means to prevent it. This will potentially do more good for future crews and travellers than looking for a fault in the software.

[borghha]

I saw on globo.com how TR are blocked: a valve is closed in the engine and a pin is introcuced in the mechanism itself, to prevent the panels from opening. But surely, this can't be the whole story? Is there no intervention in the FADEC? And could this intevention, or the lack of it, cause other failures or incorrect readings?

I followed the declaration of Y Malinge before the parliamentary commission life, and I was very surprised about the way he pre-empted the investigation, stating very categorically that the a/c hadn' t failed. I suppose he was just doing his job, ie. to defend AB. And one of the MP's, a junior female member, did ask why the extra alarm hadn't been made mandatory, and how much this would cost per a/c. But she didn't get an answer and was - rightly so - quite disturbed...

[bomarc]

Imagine an old second generation jet, with bucket reversers...you land and deploy the buckets

pretend for a second that the buckets just fall off the right engine...just pretend.

so there the pilot is, pulling the reverser levers more and more...all the gauges are right, EPR is the same on both engines, reverser ready lights are glowing

but the plane goes off to the left and isn't slowing down like it should.

is there some sort of electronic airbus equivilent of pulling reverse on both engines, reversers not deploying on the MEL'd side (right) and the right engine revving up? is it possible?

[slip and turn]

Thanks to our friend bsieker, and thanks Google, our friend also.

I just Googled for

embedded real-time system development for safety-critical systems

and added the words airbus and thrust.

One of the hits has immediately secured my interest and as it was dated 1995 has raised hairs on the back of my neck:
http://www.rvs.uni-bielefeld.de/publ...20speccrit.pdf

[armchairpilot94116]

to SDRUVSS: "pilots forgot how to land" (regarding to TL position) IS a possibility at least. The PF in the TAipei overrun did indeed leave TL #2 at 22.5. The jury is still out on that one at Bacolod.

to Nigel: I said aircraft with T/R inop, not if they were not designed into the aircraft as per Bae146 (great plane). But Bomarc is right too. The Bae146 can be in a pickle on short , wet and/or icy runways without the T/R designed in. Interesting to note that AB wanted to have no T/R on its A380, claiming no need for it. The governing agencies were not happy with that and they compromised. Now the A380 has them but only on the two inboard engines!!

And of course I dont mean to EMAS the taxiways for petes sake ( my fault as I did say the entire length of the runway) !! Planes are supposed to be on runways and taxiways but are not supposed to ever run in the grassy areas, right? EMAS the heck out of non running areas around runways if you dont lengthen Congonhas. EMAS is safe for support vehicles , it only collapses when the much heavier aircraft are on it per design. And is fixable . Its use once and discard but replaceable.

to bsieker: I dont sanction all the options I mentioned, just that they are options available (among possible others). And I dont mean that it has to have enough tarmac to stop an A320 with the exact situ per this accident. But having EMAS and/or much longer runways can turn a disaster into a much smaller event.

This was an accident and unintended, either a fault of man or machine or both. They couldnt stop it in Taipei either and they had nearly 4000 foot of runway left when brakes were manually applied. Only reduced from 146kts to 67kts (at overrun point)at best, in this nearly 4000 feet. The TAM crew had no chance to stop, unless they slammed on brakes at the TD zone right away, and even then they would be lucky to stay within the airport perimeter. Congonhas is not a whole lot longer then 6000 feet. And even if they managed to land within the first 1000 feet, and then within microseconds slammed on brakes , they still only had around 5000 feet or so at most to stop. They wouldnt have stopped if using the Taipei accident as a guide. But could be going slow enough that the 61 meter overrun area at runway end MAY BE able to contain the aircraft. AT BEST.
But if Congonhas had a longer runway and/or there was EMAS, we would be discussing a much less severe accident.

good link: (repaste) http://www.ifalpa.org/

Hindsight is 20/20 and we all have the luxury of time to figure things out. They had only seconds to realize the lever was in the wrong spot and/or slam on brakes. And actually the FDR proved that they were on the ball and started to brake , humanly speaking, actually less then 11 seconds. In other words they started braking as soon as humanly possible.
Someone said it here already....they were doomed the moment they touched down with one lever out of idle.

I will repeat what I said earlier, the Taipei crew NEVER DID figure out what was wrong during the event and the lever stayed in the wrong position throughout. They slammed on brakes after 15 seconds. No doubt some important seconds spent trying to mentally figure out what was happening (never seeing the wrong lever position). They just slammed on the brakes and were there for the ride for the duration.

[bsieker]

Nor it seems reasonable to say that they "forgot" that TL it a careful investigation, Bsieker.

Yes, "forget" may be an unfortunate wording, as it puts blame on the pilots. But the possibility that they did not retard the levers is there, backed by strong evidence, and has to be examined. If this turns out to be that case, this can only be the first step. The most important second step is to figure out why they could possibly have done that. This will be extremely hard, and may never come to a definite conclusion.

If my last post has wrong conclusions, please specifically point them out

As a computer scientist you should know that conclusions drawn from false premises are irrelevant.

You say the idle detent is just a stop so there´s no specific processing in the FADEC for this position ?

There is special processing for the idle position, namely that it disconnects A/THR. What I meant was just a technicality, that IDLE is not a detent, i. e. the lever doesn't latch or snap to the position. With the mentioned consequence that one can easily move the lever above IDLE accidentally coming from reverse.

I believe that it would be no problem if the condition for Autothrust deactivation was a TLA out of range (meaning any value out of the CLB range or any other A/Thrust valid thrust) independently of whether values "jump" or not. But is it really so ?

Autothrust works in the entire TLA region between CL and IDLE (2 engines operative), or MCT and IDLE (1 engine operative), respectively.

A/THR deactivates for any TLA position outside its active range, namely above CL (2 ENG) or MCT (1 ENG) (remains armed), and at IDLE (it is also disarmed, but can be rearmed, in which case it also engages again, but thrust is limited to IDLE.)

Sorry, I cannot answer the questions about the deviations in TLA graphs around/below idle. Probably only the experts analysing the FDR readout can.

Bernd

[slip and turn]

Originally Posted by Mad (Flt) Scientist, earlier today

edit: another possibility:
In order to move the speedbrake handle, they would have to push it down, thus disarming the GS. The disarming may indicate an attempt to manually deploy the speedbrakes - which of course wouldn't work in the landing config, but they may have forgotten that in the attempt to do SOMETHING.

Perhaps significant, the "it can't" statement on the CVR has been added at almost the same time as the GS disarm. Perhaps the references people have made to the crew being unable to move a lever (though there's no reference in the CVR which directly fits those early statements) - which many speculated meant a jammed TLA - actually occurs at about this time, and is referring to being unable to either move the Speedbrake lever or, once it was moved, to it not deploying the speedbrakes?

Page 23 of the Professor Peter B Ladkin paper, which looks like it may have survived a good 12 years of peer review, seems to offer the possibility of cycling the speedbrake lever to provide the necessary logic to re-arm the spoilers. I would not be surprised if Airbus captains of experience knew of this paper or some of the advanced less-than-intuitive logic concepts it touches upon.

bsieker has introduced us to an extremely complex subject so we'd better tread carefully ... firstly don't get excited when you read "TLA" in realtime embedded safety critical systems theory ... when the boffins use it, it sometimes means Temporal Logic of Actions not Thrust Lever Angle ...

edit: I have of course now easily discovered that Professor Ladkin's work generally on Commercial Aircraft Safety has long been recognised on PPRuNe - many of the contributors to this thread already know who he is and some of his peers post on PPRuNe. Indeed for those like me who are a bit slower on the uptake, we have been in his presence until a few days ago starting here:
http://www.pprune.org/forums/showthread.php?p=3430848#post3430848

Hats off ... and I think I will now also remove my clodhoppers.

[bsieker]

Originally Posted by slip and turn

One of the hits has immediately secured my interest and as it was dated 1995 has raised hairs on the back of my neck:
http://www.rvs.uni-bielefeld.de/publ...20speccrit.pdf

Yes, you found our website. Or rather PBL's university working group's website, with whom I am currently working.

Originally Posted by flyingnewbie10

One of the conditions is reverse thrust idle set (am I right here ?)

I'm not sure I'm with you here. "Reverse thrust idle set" is the POSTCONDITION, i. e. it's true after the necessary conditions have been met to deploy thrust reversers.

Be very careful when applying things in this paper to today's Airbuses: The Ground Spoiler logic was modified after the Warsaw accident.

Couldn't it be that something similar applies to idle TLA ?

I don't understand what you want to say.

[SoaringTheSkies]

I don't think an electronics failure is more than a red herring in this case.

If we look at the course of the events, it's rather more possible that they just did forget to retard the #2 TL.

However, and that's my whole reason to actively join this discussion, it should be carefully looked at
a) why this has happened and
b) why it could develop into such a disaster.

Even if bsieker will shoot me again for saying this:
The non moving throttle levers have their share in making this possible, and for three reasons: first, if they were moving with AT (or flown manually) there's just no possibility that they would be sitting in the CLB detent. Very simple, no room for error.
Secondly, moving TLs are feeding back aircraft actions using two additional sensory channels: peripheral vision (specifically sensitive to motion) and tactile, when the pilot has his hands on the lever.
Thirdly, and a little more "meta", the way the throttle quadrant works here is different from most other civilian aircraft, to say the least. Retarding the levers to idle really has nothing to do with bringing the engines to idle, they are already very close to ilde by the AT It's a metaphor for the pilot to tell the plane "we are committed to this landing". It really disconnects the AT and enables the GS and AB system. Unlike the Boeing design, the same TL also controls the reversers, which might have added to the confusion in this case.

I think it's a very reasonable hypothesis that the pilots might have been in some kind of "tunnel vision", having the inop TR on the tops of their minds, focusing on the one TL only and the fact that only this one should be brought into reverse and over that leaving the other one where it was all the way.

Is this a bad mistake? Sure.

Now, as they touched down in that configuration, the PM called out "no spoilers". Another alley into tunnel vision. Everybody on here knows the remedy for that no problem by now: bring back that thrust lever!
They were focussed on spoilers. So what did they touch? The spoilers lever, effectively disarming the spoilers. What were they hoping to get? I don't know. But I find it very reasonable that, if a system you expected to work fails, you first touch the controls for that system. Then, when they concluded that they were not getting any deceleration, they applied manual brakes (and thank you PBL for debunking the 11s myth brought up earlier) and were hoping for the best which, as we know, did not happen.
So here they are, plagued with two problems:
- no spoilers
- no autobrake
What do they touch? The controls for those two systems. Natural. Tunnel vision.

And all the time they seem to have been oblivious of the root cause: the trust lever.

Could a system be designed to be more forgiving of this root error? I say it could. A manual option to deploy spoilers and thus commit to the landing might have helped, or, the other way round, a system that deploys spoilers on manual braking.

I have actually no idea if or if not Boeing has similar issues in their a/c design and it doesn't matter either. I'm not comparing one over the other because I would have any sort of preference. I'm looking at this from a human / machine interaction point of view.

When an Airbus official then sais "the plane has performed as designed" I can't help thinking that this sentence has a certain cynical sound to it. Almost as if "design" was out of the realm of what should be looked at.

pj

[armchairpilot94116]

to STS:

Yes I alluded to that possibility in my post 1394: (the example given in the link is telling)

Could it have been a case of Tunnel Vision?
http://www.airlinesafety.com/editori...ngapore006.htm

This is an article trying to explain the Human Factor regarding the accident involving a Singapore Airlines 747 at take off from TAipei Taoyuan International Airport on Oct.31, 2000.

Could the Congonhas TAM accident crew have also been affected likewise? By the known challenge that landing at Congonhas on a wet evening on a resurfaced, ungrooved runway would be? And failing basic airmanship (idle the throttles on landing) because of this overwhelming attention to the task at hand?

[bsieker]

Originally Posted by flyingnewbie10

Did you state that one of the A/Thrust deactivation conditions is a TLA at idle or any place at or below idle ?

Are we discussing about <if (TLA == 0) deactivate()> or about <if (TLA <= 0) deactivate() > ?

A little excursion into Airbus terminology is probably required.

A/THR can be: disconnected, armed, active.

disconnected: neither armed nor active, thrust is always controlled manually

Armed: A/THR arms automatically when FLX or TOGA thrust is set at take-off, it can be armed manually by pressing the A/THR button.

Active: A/THR becomes active, when
- A/THR is armed AND
- Thrust levers are moved into the active range.

Pushing the thrust levers forward deactivates A/THR, but leaves it armed, it reactivates when thrust levers are moved back to CL, or below, but are kept above idle.

Pulling (both) thrust levers to idle disconnects A/THR. It is no longer armed.

(To go to Reverse, you always have to go through idle, there is a hard mechanical stop. So you cannot just "jump over" idle.)

A/THR can be disconnected by pushing the "instinctive disconnect" button at the side of the thrust levers. In this case thrust adjusts to meet the lever position.

Pushing the A/THR button disconnects A/THR. As do several tests performed in the FADEC, these are termed "involuntary disconnect". In all these cases thrust is locked at the time of disconnect. It matches TLA as soon as thrust levers are moved.

In this accident, as only one TL was pulled to idle, A/THR did not disconnect in the standard way. (As you can see, ATS switches off some seconds after TLA #1 reached IDLE.)

For the exact explanation why A/THR disconnected shortly afterwards, see p148 of the Taipei-Sungshan Incident report.

I cannot explain why engine 2 EPR rose to 1.26, then fell back, and only then did A/THR disconnect.