TAM A320 crash at Congonhas, Brazil
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
borghha:
Doesn't this contradict your own statement? The computer (decides to) 'gives' GS IF the pilots do/had done ... So it is the computer that makes the decision here, ignoring completely that one of the human inputs was incorrect...
Doesn't this contradict your own statement? The computer (decides to) 'gives' GS IF the pilots do/had done ... So it is the computer that makes the decision here, ignoring completely that one of the human inputs was incorrect...
If the lever was left out of position, then it was a gross handling error, period. You can't blame the computer for that.
It was AB's decision not to make the adaptation mandatory, and the aviation authorities apparently didn't see it fit to override this decision. Had they overriden it, perhaps this accident would never have happened.
Cheers.
Join Date: Jul 2007
Location: BRU
Posts: 82
Likes: 0
Received 0 Likes
on
0 Posts
Dozy,
no I can t point you to the a paragraph in the report, because it is not in there, it only states that AB had developed a warning system and that it was going to issue a SB soo. I read here in this thread and in the press that the SW was marked 'desirable', not 'mandatory'. The TAM A320 was not equipped with this new ECAM and aural warning.
Greets
no I can t point you to the a paragraph in the report, because it is not in there, it only states that AB had developed a warning system and that it was going to issue a SB soo. I read here in this thread and in the press that the SW was marked 'desirable', not 'mandatory'. The TAM A320 was not equipped with this new ECAM and aural warning.
Greets
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Doesn t this contradict your own statement? The computer (decides to) 'gives' GS IF the pilots do/had done ... So it is the computer that makes the decision here, ignoring completely that one of the human inputs was incorrect... And allowing them just a few seconds to figure everything out, to correct their error (obey my logic!) because overriding the logic isn't possible!
It's the system design specification that says: "No GS unless WoW and TLs at idle".
Forty years ago that would have been implemented with baulks and electro-mechanical interlocks.
Today it's implemented in the computer logic.
A TL out of the idle detent means no GS in either case.
I know it's only one of the many issues here, but don't "blame" the computer for this particular aspect.
Join Date: Jul 2006
Location: On the side of the pitch!
Age: 47
Posts: 495
Likes: 0
Received 0 Likes
on
0 Posts
There seems to be lots of arguing about whether pilots should have less automation to keep them out of trouble. From my view, if you fully understand the system on the 320 you will know that if you leave a thrust lever in the CLB detent the ground spoilers will not deploy. Airbus placed this into the system in the beginning and has worked for 20+ years without incident. This is also within the FCOM. The command 'Retard' is there for a reason for heavens sake. I think someone stated that it couldn't be pilot error, unfortunately this time it blatently is.
One engine left in CLB, one in Reverse (not sure if it was full or idle reverse). No GS deployed, loads of lift still generated by the wings. Apparently going off the end of the runway above 100kts. As an Airbus pilot myself, this says to me a total lack of understanding of the system.
One engine left in CLB, one in Reverse (not sure if it was full or idle reverse). No GS deployed, loads of lift still generated by the wings. Apparently going off the end of the runway above 100kts. As an Airbus pilot myself, this says to me a total lack of understanding of the system.
Join Date: Dec 2001
Location: Finland
Age: 44
Posts: 121
Likes: 0
Received 0 Likes
on
0 Posts
For God's sake.
There is no more question what would have happened, if the pilot had moved TL2 to idle. At this point we can only assume that he didn't.
My point was totally lost to most of you, obviously.
In a case, where stopping the aircraft is the desired course of action, the automatics in the AB (no, it's not the computer who should be blamed) are not allowing for GS extension, IF a pilot makes a major operational mistake (like in the TAM case). Before anybody shouts that the computer cannot account for every possible scenario, I will respond that that is exactly why there should be a MANUAL way of assisting the aircraft to STOP.
Did anyone read what I wrote earlier? It's not just a question of "simply pulling TL2 to idle", and that's it. If they had figured it out, the aircraft in question would not be in a million pieces right now. Simple, eh? The point is that there is very little in the automation side (regarding this particular scenario) that would assist the human pilot in stopping the airplane. I will not repeat the points that I consider the most important parts that should need to be improved, but I still think that it is just not right to be under the mercy of LOGIC in a panic situation to be able to stop the plane.
Some people need to think outside of their education and "business as usual" type of thinking, where even this accident would have seemed nearly impossible. We have probable evidence to support that at least two crews have now made the mistake of leaving the other TL outside of detected IDLE, and thus have lost the majority of braking power as the result. Without any other means of correcting the situation, other than finising the one missing bit from the logic loop that is set incorrectly. And that is too much to ask from a human being in a situation where logic is tossed out the window.
Tero
There is no more question what would have happened, if the pilot had moved TL2 to idle. At this point we can only assume that he didn't.
My point was totally lost to most of you, obviously.
In a case, where stopping the aircraft is the desired course of action, the automatics in the AB (no, it's not the computer who should be blamed) are not allowing for GS extension, IF a pilot makes a major operational mistake (like in the TAM case). Before anybody shouts that the computer cannot account for every possible scenario, I will respond that that is exactly why there should be a MANUAL way of assisting the aircraft to STOP.
Did anyone read what I wrote earlier? It's not just a question of "simply pulling TL2 to idle", and that's it. If they had figured it out, the aircraft in question would not be in a million pieces right now. Simple, eh? The point is that there is very little in the automation side (regarding this particular scenario) that would assist the human pilot in stopping the airplane. I will not repeat the points that I consider the most important parts that should need to be improved, but I still think that it is just not right to be under the mercy of LOGIC in a panic situation to be able to stop the plane.
Some people need to think outside of their education and "business as usual" type of thinking, where even this accident would have seemed nearly impossible. We have probable evidence to support that at least two crews have now made the mistake of leaving the other TL outside of detected IDLE, and thus have lost the majority of braking power as the result. Without any other means of correcting the situation, other than finising the one missing bit from the logic loop that is set incorrectly. And that is too much to ask from a human being in a situation where logic is tossed out the window.
Tero
I support PPRuNe
Join Date: Jul 2007
Location: Belo Horizonte, Brazil
Posts: 162
Likes: 0
Received 0 Likes
on
0 Posts
To coin a phrase, "all they had to do" was retard the additional thrust lever.
I don't know why they didn't.
I don't know why they didn't.
Join Date: Aug 2007
Location: Buenos Aires, Argentina
Age: 78
Posts: 12
Likes: 0
Received 0 Likes
on
0 Posts
Rob21 has said:
"If we allow computers to make such an important decision (I WON'T GIVE YOU GS NOR A/B IF YOU DON'T MOVE BOTH TLs TO IDLE), we need to teach computers also how to put "hands on" and really correct our (pilots) mistakes."
A T-shirt, some 20 years ago, has said:
"To err is human, to really foul things up requires a computer"
Being not a pilot at all, but having worked with computers (the big and blue ones) for more than 30 years, I agree 100% with that T-shirt.
Best regards,
Jorge.
"If we allow computers to make such an important decision (I WON'T GIVE YOU GS NOR A/B IF YOU DON'T MOVE BOTH TLs TO IDLE), we need to teach computers also how to put "hands on" and really correct our (pilots) mistakes."
A T-shirt, some 20 years ago, has said:
"To err is human, to really foul things up requires a computer"
Being not a pilot at all, but having worked with computers (the big and blue ones) for more than 30 years, I agree 100% with that T-shirt.
Best regards,
Jorge.
Join Date: Aug 2007
Location: Toronto
Age: 53
Posts: 5
Likes: 0
Received 0 Likes
on
0 Posts
I've been a lurker here for a long time and until now have never felt the need to participate in any conversations as a simple passenger.
I have a question though about this accident. In this case it appears the TL1 is set to reverse, and TL2 is still set to be making thrust. Aside from the obvious visual clue as to this situation (i.e. looking at the thrust levers) is there any other warning that the TL's have been set in a postion that should clearly never occur in any phase of flight.
The computer logic appears to default to assuming the plane is not landing unless both TL are pulled back, and as such prohibits the extension of GS. It would seem to me that in the case where one TL is set to reverse and the other to make thrust a special warning could be necessary, as clearly the human operator may be somewhat overwhelmed at the time trying to figure out why the plane is not slowing down and in this case has not noticed a fundamental error.
Of course this also falls into the category of you can't have a warning for everything, especially those things that seem so basic as TL setting.
I have a question though about this accident. In this case it appears the TL1 is set to reverse, and TL2 is still set to be making thrust. Aside from the obvious visual clue as to this situation (i.e. looking at the thrust levers) is there any other warning that the TL's have been set in a postion that should clearly never occur in any phase of flight.
The computer logic appears to default to assuming the plane is not landing unless both TL are pulled back, and as such prohibits the extension of GS. It would seem to me that in the case where one TL is set to reverse and the other to make thrust a special warning could be necessary, as clearly the human operator may be somewhat overwhelmed at the time trying to figure out why the plane is not slowing down and in this case has not noticed a fundamental error.
Of course this also falls into the category of you can't have a warning for everything, especially those things that seem so basic as TL setting.
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by SinBin
There seems to be lots of arguing about whether pilots should have less automation to keep them out of trouble.
- the pilots can see at a glance what the automation is doing, and
- they can override the automation when it's doing something nobody in the design office thought of, or if they did, put it into the highly improbable category.
The "pilot in the loop" and "pilot monitoring the automatics" discussion happened 50 years ago.
Automation won. But until the pilots are turfed out of the cockpit, they should still be allowed to do their job.
As you may have guessed, I'm part of the "moving TLs" clan.
What was good enough for Concorde should be good enough for the flying Coke Can.
Join Date: Apr 2004
Location: near EDDF
Posts: 775
Likes: 0
Received 0 Likes
on
0 Posts
@ teropa (#1742)
You can not cover every dumb with a logic without making the system to complex.
Complexity is (IMHO) the biggest enemy of failsafe.
You accuse some people >>not to thing outside of their education and "business as usual"<<, but do you?
You pick up one "fault"(?) and want to correct it. But don´t you thing that AB didn´t thing about this?
This kind of logic (one TL far idle) is an additional protection not to get Groundspoiler in AIR.
Groudspoiler inhibition in Air without any exception is (IMHO) more important than getting them on ground under all circumstances.
my 2cent
You can not cover every dumb with a logic without making the system to complex.
Complexity is (IMHO) the biggest enemy of failsafe.
You accuse some people >>not to thing outside of their education and "business as usual"<<, but do you?
You pick up one "fault"(?) and want to correct it. But don´t you thing that AB didn´t thing about this?
This kind of logic (one TL far idle) is an additional protection not to get Groundspoiler in AIR.
Groudspoiler inhibition in Air without any exception is (IMHO) more important than getting them on ground under all circumstances.
my 2cent
Join Date: Jul 2007
Location: BRU
Posts: 82
Likes: 0
Received 0 Likes
on
0 Posts
tero wrote
Couldn t agree more tero. Of course it is vital to understand the underlying logic, but do all pilots get enough training for them to understand it? And even if they do, they could get into trouble during an emergency, as has happened more than once now. It seems quite arrogant to eliminate certain pilot errors (GS while airborne) and others not at all, and to make things worse, avoiding the GS error means in this case that it is impossible to recover from a disastous scenario, because as the psychologist here already explained, retarding both TL being routine, you just don t think back to that action if you failed to do so because another task - 1 TR inop - disturbed that routine. And was the 'error' the TAM crew made (i TRL in CLB, 1 put in TREV Max - !no unwanted TR deployment!) less unlikely to happen or less unprofessional than a GS deployment command in the air? Do AB have an hierarchy of human error vs system logic? Maybe they do...
The point is that there is very little in the automation side (regarding this particular scenario) that would assist the human pilot in stopping the airplane. I will not repeat the points that I consider the most important parts that should need to be improved, but I still think that it is just not right to be under the mercy of LOGIC in a panic situation to be able to stop the plane.
Join Date: Feb 2007
Location: FRA
Age: 47
Posts: 5
Likes: 0
Received 0 Likes
on
0 Posts
What was the reason of T/R inop.?? What actions where made during maintenance?
Can you imagine (is it electrically, system, software possible) that deactivating T/R was coincident with wrong TL readouts? Is there any possibility of technical maintenance error during T/R inop. which lead to wrong readouts or different system behaviour?
Is there any technical future to protect the ABcft (Boeing) to have the T/R activated while inflight? How it is made??
What can happened when there is such a technical assurance and we had T/R on one engine inop.??
What was finally prior to disaster SOP of TAM in case of 1 TR inop. MEL because I lost the trace? Could it have an psychological input?
The question without the answer ever – did the crew had the same remembering callouts about one TR only at the previous landings?? (I would opt for continuous CVR and probably CIR)
How about different psychological scenario to presented here already. In previous landings they (more ore less together) forgot about the rule not to put the MEL restricted eng. to reverse.. (especially F/O position CPT who had made the previous landings as PF) and after being instructed by his college they both keep attention to the problem of 1TR inop. problem with too much attention?
I am curious of the two accidents with similar ending similar findings.. and no 100% prove.
How about TransAvia accident?
Do you remember Murphy’s and Fire-fighters rule of a thumb that reason is most likely be closes to the place where the most significant damages has happened.. So combined T/R inop. and wrong setting of TL leading to disaster.. is in my opinion a little too much for calling it HF errors.
Try also an Reverse Engineering in this case..
Just my 2 cents..
Can you imagine (is it electrically, system, software possible) that deactivating T/R was coincident with wrong TL readouts? Is there any possibility of technical maintenance error during T/R inop. which lead to wrong readouts or different system behaviour?
Is there any technical future to protect the ABcft (Boeing) to have the T/R activated while inflight? How it is made??
What can happened when there is such a technical assurance and we had T/R on one engine inop.??
What was finally prior to disaster SOP of TAM in case of 1 TR inop. MEL because I lost the trace? Could it have an psychological input?
The question without the answer ever – did the crew had the same remembering callouts about one TR only at the previous landings?? (I would opt for continuous CVR and probably CIR)
How about different psychological scenario to presented here already. In previous landings they (more ore less together) forgot about the rule not to put the MEL restricted eng. to reverse.. (especially F/O position CPT who had made the previous landings as PF) and after being instructed by his college they both keep attention to the problem of 1TR inop. problem with too much attention?
I am curious of the two accidents with similar ending similar findings.. and no 100% prove.
How about TransAvia accident?
Do you remember Murphy’s and Fire-fighters rule of a thumb that reason is most likely be closes to the place where the most significant damages has happened.. So combined T/R inop. and wrong setting of TL leading to disaster.. is in my opinion a little too much for calling it HF errors.
Try also an Reverse Engineering in this case..
Just my 2 cents..
Join Date: Jul 2007
Location: the City by the Bay
Posts: 547
Likes: 0
Received 0 Likes
on
0 Posts
what should Airbus do?
Lets put together a list of what Airbus should do with the A320 in view of this latest tragedy. Please add or subtract as appropriate and be sure to explain why?
1. Any recommended actions post the Final Report of this new accident should be made "mandatory" rather then just "suggested" as post the Taipei - Sungshan overrun.
2. The SB post Taipei overrun should be made mandatory. CRC, Master Warning and Ecam message to alert of TL miss-position.
3. In addition, the Taipei authorities proposed "RETARD" call to continue in the event of one TL being above idle. I propose add the engine number to that to pertain to the TL that is not in idle (ie RETARD TWO , RETARD TWO, RETARD TWO). This call not to end until the pilot puts the lever into idle. Or takes other action as in Go Around.
4. In the event that the pilot does not retard one TL to idle in spite of all warnings, the engine in question should idle (and not match TL position after Autothrust disengages) until the lever is MOVED . This helps resolve the ambiguity of having one T/R deployed and yet the other engine in CLB.
5. Heavy brake application on the landing roll should mean only one thing: COME TO COMPLETE STOP ASAP. And therefore Ground Spoilers and all other facilities to bear to come to COMPLETE STOP NOW!! There should be no ambiguity about the pilots intentions when heavy braking is applied.
1. Any recommended actions post the Final Report of this new accident should be made "mandatory" rather then just "suggested" as post the Taipei - Sungshan overrun.
2. The SB post Taipei overrun should be made mandatory. CRC, Master Warning and Ecam message to alert of TL miss-position.
3. In addition, the Taipei authorities proposed "RETARD" call to continue in the event of one TL being above idle. I propose add the engine number to that to pertain to the TL that is not in idle (ie RETARD TWO , RETARD TWO, RETARD TWO). This call not to end until the pilot puts the lever into idle. Or takes other action as in Go Around.
4. In the event that the pilot does not retard one TL to idle in spite of all warnings, the engine in question should idle (and not match TL position after Autothrust disengages) until the lever is MOVED . This helps resolve the ambiguity of having one T/R deployed and yet the other engine in CLB.
5. Heavy brake application on the landing roll should mean only one thing: COME TO COMPLETE STOP ASAP. And therefore Ground Spoilers and all other facilities to bear to come to COMPLETE STOP NOW!! There should be no ambiguity about the pilots intentions when heavy braking is applied.
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes
on
0 Posts
Do AB have an hierarchy of human error vs system logic? Maybe they do...
Whereas a pilot error that I dream up sat at my desk, but which hasn't happened yet, gets dismissed as "there's no way that could happen, and anyway the SOP deals with it" so we don't design it out.
The regs aren't derived from first prinicples; they're the basis of experience, and anything 'new' takes us outside the regulatory comfort zone.
AC621 has made everyone gunshy of inadvertent in-air GS deployment, so we (all) design it out.
I support PPRuNe
Join Date: Jul 2007
Location: Belo Horizonte, Brazil
Posts: 162
Likes: 0
Received 0 Likes
on
0 Posts
Aero Magazine
"E importante dizer, porem, que apos o problema em Taiwan, a autoridade aeronautica local recomendou que a Airbus alterasse o sistema de alerta aos pilotos no caso de posicionamento incorreto das manetes, pois considerou que os avisos sonoros antes do pouso nao foram suficientes para lembrar os pilotos de corrigirem a situacao... ...... ... ...
A Airnus divulgou que houve modificacoes em seu sistema e que teria sido adotado um alarme sonoro para avisar os pilotos no caso de uma configuracao incorreta das manetes mas nao soube informar se o PR-MBK tinha recebido essa modificacao."
It is important to say, however, that after the problem in Taiwan, the local aeronautical authority recommended that Airbus should alter the alert system to the pilots in case of incorrect positioning of the TLs, because it considered that the sound warnings before touching down were not sufficient to alert the pilots to correct the situation... ... ... ...
The Airbus said that they made modifications in their system and that they did adopt a sound alarm to alert the pilots in case of an incorrect configurations of the TLs but they did not know if the PR-MBK had received this modification.
A Airnus divulgou que houve modificacoes em seu sistema e que teria sido adotado um alarme sonoro para avisar os pilotos no caso de uma configuracao incorreta das manetes mas nao soube informar se o PR-MBK tinha recebido essa modificacao."
It is important to say, however, that after the problem in Taiwan, the local aeronautical authority recommended that Airbus should alter the alert system to the pilots in case of incorrect positioning of the TLs, because it considered that the sound warnings before touching down were not sufficient to alert the pilots to correct the situation... ... ... ...
The Airbus said that they made modifications in their system and that they did adopt a sound alarm to alert the pilots in case of an incorrect configurations of the TLs but they did not know if the PR-MBK had received this modification.
Sun worshipper
Join Date: Dec 2001
Location: Paris
Posts: 494
Likes: 0
Received 0 Likes
on
0 Posts
bsieker,
I spent more time than expected on the Tai Pei accident.
As I suspected, I was rambling on the CGH instance and your posts were on the Airbus ( ? ) *explanation.*
Going back to your previous post,
[i]Quote:
- A/THR working normally in speed mode, using engine #2
If we consider the initial conditions, they were with A/THR on, in speed mode. Therefore, the FMGS was instructing BOTH FADECs to provide enough thrust ( = EPR ) to comply with the approach speed requirements.The value observed on the graph is ~ 1.06 EPR.
- TL #1 set to idle. No problem, just limits thrust usable by A/THR to idle
for that engine.
- TLA EPR value for Eng #1 becomes 0.98
As we know now that the delta value that triggers a disconnect ( .15 EPR ), the idling of #1 T/L isn't enough to cause an A/THR disconnect, which you correctly picked-up :
TL#1 is pulled to idle at around 18:48:22, A/THR only disconnects at 18:48:29. So it seems this was not the case.
- TL #1 set to reverse:
. TLA EPR becomes NCD ("no computed data")
. FMGC continues to use last valid value (0.98) . This paragraph applies to #1 engine, and I agree with your conclusions.
During that time ,#2 FADEC had been *instructed* by the FMGS to start compensating for the deceleration due to the reducing output from #1 (remember we're still in the A/THR approach mode in which, in order to give the A/THR faster reactions, longitudinal acceleration is introduced in the ADR-to-FADEC link ). This shows in the small rise of the #2 engine EPR.
The following is a hard act to follow, as it's in all certainty a double translation : A text in English --> translated into Chinese, for the benefit of local officials --> and given back to a translator for the final text in English !.
On top of all this, there are apparently quite a few inaccuracies :
1. the .75 EPR is in all probability to be read as "75% of the rated EPR ".
2. a reduction of .2 EPR seems to me excessive, and ".02 EPR reduction" a lot more likely.
FMGC uses 0.98 (last valid) as TLA EPR value. The report again:
the FMGC ARINC acquisition behaviour (per design) in case of NCD is to keep the last EPR TLA valid value.
It also says,
the condition triggers when the "THR TARGET feedback of one FADEC is different by 0.15 from the ATHR EPR TARGET limited to the corresponding EPR TLA.
. FADEC uses a value of 0.75 with engine in reverse (FADEC EPR target feedback is upper limited to EPR TLA, EPR IDLE is reduced by 0.2 when reverser is deployed more than 15% (0.98 - 0.2 makes 0.78, but I assume that's close enough))
. comparison of the two values (0.98 and 0.75) is greater than 0.15.
. if that condition persists for more than 1.8s, A/THR disconnects.
According to Airbus, this condition was the one triggering the disconnect in Taipei-Sungshan. Doesn't mean it has to be, here, but the timing implies it.
Agree,
I'll try and get the book on this system and I'll come back to on a pm.
Anyway, whatever the conditions - and you might be right as the *feedback values* could be totally unrelated to the performance of the engine and its T/R-, the conclusion applies to us :
"Consequently the EPR comparison becomes invalid and the ATHR is
disconnected after 1.8 sec with the corresponding warning .That involuntary
ATHR disconnection allowed the thrust to be frozen on engine2 whose lever
was at CLB notch !"
In other words, TLA #1 in the reverse range triggered an A/THR disconnect with a thrust lock on #2 Engine, to the last valid commanded EPR, even though its T/L was left in the CLB detent.
Regards.
I spent more time than expected on the Tai Pei accident.
As I suspected, I was rambling on the CGH instance and your posts were on the Airbus ( ? ) *explanation.*
Going back to your previous post,
[i]Quote:
- A/THR working normally in speed mode, using engine #2
If we consider the initial conditions, they were with A/THR on, in speed mode. Therefore, the FMGS was instructing BOTH FADECs to provide enough thrust ( = EPR ) to comply with the approach speed requirements.The value observed on the graph is ~ 1.06 EPR.
- TL #1 set to idle. No problem, just limits thrust usable by A/THR to idle
for that engine.
- TLA EPR value for Eng #1 becomes 0.98
As we know now that the delta value that triggers a disconnect ( .15 EPR ), the idling of #1 T/L isn't enough to cause an A/THR disconnect, which you correctly picked-up :
TL#1 is pulled to idle at around 18:48:22, A/THR only disconnects at 18:48:29. So it seems this was not the case.
- TL #1 set to reverse:
. TLA EPR becomes NCD ("no computed data")
. FMGC continues to use last valid value (0.98) . This paragraph applies to #1 engine, and I agree with your conclusions.
During that time ,#2 FADEC had been *instructed* by the FMGS to start compensating for the deceleration due to the reducing output from #1 (remember we're still in the A/THR approach mode in which, in order to give the A/THR faster reactions, longitudinal acceleration is introduced in the ADR-to-FADEC link ). This shows in the small rise of the #2 engine EPR.
The following is a hard act to follow, as it's in all certainty a double translation : A text in English --> translated into Chinese, for the benefit of local officials --> and given back to a translator for the final text in English !.
On top of all this, there are apparently quite a few inaccuracies :
1. the .75 EPR is in all probability to be read as "75% of the rated EPR ".
2. a reduction of .2 EPR seems to me excessive, and ".02 EPR reduction" a lot more likely.
FMGC uses 0.98 (last valid) as TLA EPR value. The report again:
the FMGC ARINC acquisition behaviour (per design) in case of NCD is to keep the last EPR TLA valid value.
It also says,
the condition triggers when the "THR TARGET feedback of one FADEC is different by 0.15 from the ATHR EPR TARGET limited to the corresponding EPR TLA.
. FADEC uses a value of 0.75 with engine in reverse (FADEC EPR target feedback is upper limited to EPR TLA, EPR IDLE is reduced by 0.2 when reverser is deployed more than 15% (0.98 - 0.2 makes 0.78, but I assume that's close enough))
. comparison of the two values (0.98 and 0.75) is greater than 0.15.
. if that condition persists for more than 1.8s, A/THR disconnects.
According to Airbus, this condition was the one triggering the disconnect in Taipei-Sungshan. Doesn't mean it has to be, here, but the timing implies it.
Agree,
I'll try and get the book on this system and I'll come back to on a pm.
Anyway, whatever the conditions - and you might be right as the *feedback values* could be totally unrelated to the performance of the engine and its T/R-, the conclusion applies to us :
"Consequently the EPR comparison becomes invalid and the ATHR is
disconnected after 1.8 sec with the corresponding warning .That involuntary
ATHR disconnection allowed the thrust to be frozen on engine2 whose lever
was at CLB notch !"
In other words, TLA #1 in the reverse range triggered an A/THR disconnect with a thrust lock on #2 Engine, to the last valid commanded EPR, even though its T/L was left in the CLB detent.
Regards.