TAM A320 crash at Congonhas, Brazil
Pira, BOAC, thanks for the responses on my query.
My own 767 experience was, if the a/t's weren't disconnected at/near touchdown (in the flare), they would move forward and seek to maintain the approach bug speed.
That the thrust levers are moved aft to IDLE at touchdown by the a/t system in a Boeing under ALL conditions (when a/t's engaged of course), is new information for me. That was not my understanding of the Boeing a/t system, so thanks for the information.
Is it correct then to assume that the PF does not need to pull the thrust levers aft to IDLE at touchdown and that system design would do it automatically, (even though s/he will routinely do so on every occasion)?
In the Airbus 320/340 fleet types, with the thrust levers in the CLB detent, the a/t system will seek to maintain Vapp until disconnected by retarding the t/l's to IDLE. The AB AOM states that the t/l's should be retarded to IDLE at 20ft, (on an autoland, at 10ft).
Sorry to press this but as can be seen the differences and the understandings are varied and what better place to sort them out than here?!
clearedtocross;
A little room, please. Have you ever experienced a spirited discussion within your own professional group regarding "variations on a theme" in terms of the behaviours of operating systems and solutions to complex programming issues with varying but equal validity?
You are reading such a discussion, which, I add, is being carried on in the public's full glare with full access by non-experts of all manner. The discussion is of aircraft design subtleties which, according to the accident record, have not resulted in an untoward wholesale carnage that the word "clueless" may inadvertently be implying, but which may have contributed, more through ergonomic/human factors issues than mechanical failures, to some accidents.
Fleshing out details, understandings and outcomes to extremely rare circumstances is what is happening here and it is an extremely good and healthy thing as you can see. Would that the medical profession were as openly engaged in the subtleties of risk analysis, "accident prevention" and other iatrogenic "disorders" which are related to thousands of deaths each year.
I appreciate that you are not a professional pilot, but as a system engineer of computerized systems you will know that a 'big red button' design concept is permits a single-point failure to "jeopardize the mission" if you will. The circumstances are so extremely rare in which such a design concept would be helpful and there are so many circumstances which such a system improperly engaged could result in an incident or accident that the notion is entirely impractical - the extreme rapidity with which this (and other) accident(s) occurred and the absolute certainty with which such a decision would have to be made precludes a such a crew action even if such a system could ever be successfully designed let alone certified. Go-around capability from very low altitudes on a Category II or III landing must be certified for a touchdown during such a go-around maneuver, and is one such example where an incorrect decision would be catastrophic. The "one-button-saves-all" approach is magical thinking and not appropriate to aviation.
The history of software development in commercial aircraft has been one of carefully considered, extremely conservative developments for the reasons we are reading here. The history of introduction incidents on both Boeing and Airbus aircraft shows that automation and flight safety are compatible and that the introduction has been (despite what many including myself initially thought), a successful one. Accidents such as we are struggling greatly with at this moment do not serve to illustrate exceptions to these successful technological developments but serve instead as warnings.
Human factors/human error cannot be eliminated by technological or software solutions no matter how brilliantly and practically conceived. Instead, error-trapping behaviours, recursive SOPs which, while not too cumbersome, provide checks-and-balances on a moment-by-moment basis during critical phases of flight, hold more promise but in the end, the interface between "blind technology" and sentient humans will always be a risk-point.
The areas of human factors, accident prevention through flight data analysis programs (FOQA or FDA), line-oriented safety awareness (LOSA) programs, aviation safety reporting (ASR) programs are significant endeavours which are designed to capture trends and untoward patterns before they become accidents.
Despite the adjective "cheesy" being employed by a poster here to describe Reason's (and I must assume others' such as Helmreich et al) work, accident prevention through data analysis is an area with great promise, for, after all, investigating an accident only prevents the second one, not the first.
My own 767 experience was, if the a/t's weren't disconnected at/near touchdown (in the flare), they would move forward and seek to maintain the approach bug speed.
That the thrust levers are moved aft to IDLE at touchdown by the a/t system in a Boeing under ALL conditions (when a/t's engaged of course), is new information for me. That was not my understanding of the Boeing a/t system, so thanks for the information.
Is it correct then to assume that the PF does not need to pull the thrust levers aft to IDLE at touchdown and that system design would do it automatically, (even though s/he will routinely do so on every occasion)?
In the Airbus 320/340 fleet types, with the thrust levers in the CLB detent, the a/t system will seek to maintain Vapp until disconnected by retarding the t/l's to IDLE. The AB AOM states that the t/l's should be retarded to IDLE at 20ft, (on an autoland, at 10ft).
Sorry to press this but as can be seen the differences and the understandings are varied and what better place to sort them out than here?!
clearedtocross;
I am baffled to recognize that most guys in this thread after some 700 posts are still rather clueless as to what happens when auto this and that is selected and lever this and that is left where it should not be and auto such and such is inop and why it might be possible to have one engine screaming in reverse and the other trying full blast to keep the speed.
You are reading such a discussion, which, I add, is being carried on in the public's full glare with full access by non-experts of all manner. The discussion is of aircraft design subtleties which, according to the accident record, have not resulted in an untoward wholesale carnage that the word "clueless" may inadvertently be implying, but which may have contributed, more through ergonomic/human factors issues than mechanical failures, to some accidents.
Fleshing out details, understandings and outcomes to extremely rare circumstances is what is happening here and it is an extremely good and healthy thing as you can see. Would that the medical profession were as openly engaged in the subtleties of risk analysis, "accident prevention" and other iatrogenic "disorders" which are related to thousands of deaths each year.
I appreciate that you are not a professional pilot, but as a system engineer of computerized systems you will know that a 'big red button' design concept is permits a single-point failure to "jeopardize the mission" if you will. The circumstances are so extremely rare in which such a design concept would be helpful and there are so many circumstances which such a system improperly engaged could result in an incident or accident that the notion is entirely impractical - the extreme rapidity with which this (and other) accident(s) occurred and the absolute certainty with which such a decision would have to be made precludes a such a crew action even if such a system could ever be successfully designed let alone certified. Go-around capability from very low altitudes on a Category II or III landing must be certified for a touchdown during such a go-around maneuver, and is one such example where an incorrect decision would be catastrophic. The "one-button-saves-all" approach is magical thinking and not appropriate to aviation.
The history of software development in commercial aircraft has been one of carefully considered, extremely conservative developments for the reasons we are reading here. The history of introduction incidents on both Boeing and Airbus aircraft shows that automation and flight safety are compatible and that the introduction has been (despite what many including myself initially thought), a successful one. Accidents such as we are struggling greatly with at this moment do not serve to illustrate exceptions to these successful technological developments but serve instead as warnings.
Human factors/human error cannot be eliminated by technological or software solutions no matter how brilliantly and practically conceived. Instead, error-trapping behaviours, recursive SOPs which, while not too cumbersome, provide checks-and-balances on a moment-by-moment basis during critical phases of flight, hold more promise but in the end, the interface between "blind technology" and sentient humans will always be a risk-point.
The areas of human factors, accident prevention through flight data analysis programs (FOQA or FDA), line-oriented safety awareness (LOSA) programs, aviation safety reporting (ASR) programs are significant endeavours which are designed to capture trends and untoward patterns before they become accidents.
Despite the adjective "cheesy" being employed by a poster here to describe Reason's (and I must assume others' such as Helmreich et al) work, accident prevention through data analysis is an area with great promise, for, after all, investigating an accident only prevents the second one, not the first.
Join Date: Aug 2005
Location: SEA (or better PAE)
Posts: 215
Likes: 0
Received 0 Likes
on
0 Posts
Pira just a comment on your post #703:
Reliability is a measured value of statistical nature. Defining one or the other product "more reliable" asks for excluding your subjectivity and using the metrics exclusively, which unfortunately is not the case with your comment.
.
I don't want to enter in a discution about which aircraft is best, because I believe both have good qualities, but no one can deny Boeing is a simpler,thus more reliable aircraft.
.
Last edited by Grunf; 30th Jul 2007 at 19:43.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
PJ -
- we are outside my experience range here since I do not use A/T when manually flying (as per the Boeing rec), so I can only confirm that in the 'FLARE' manoeuvre (ie Dual channel) an engaged A/T will close to idle. There is some speculation elsewhere on PPRune that a single channel approach will 'FLARE' but I do not support this, having never seen or heard of it. I have, however, seen the min speed reversion cut in during a manual flare (possibly above 27'RA) and then the A/T will attempt to maintain bug speed + a bit, so I suspect the A/T may not retard outside a 'FLARE' condition, but as I say it is not a 'normal' area of 737 operation.
moved aft to IDLE at touchdown by the A/T system in a Boeing under ALL conditions
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
Some review of what statistics there are may be in order.
The A320 family was introduced in 1988 and until October 2006 there were 2,880 aircraft of this family delivered (Flight International, 24-30 October 2006). That amounts, assuming a constant rate, to 160 aircraft per year, assuming no attrition (there has been some, of course, namely 18 hull losses, but I am ignoring it). Taking a service year to have 333.33 days and taking each aircraft to fly an average of 6 legs per working day, that is 2,000 landings per aircraft per year. At 160 aircraft per year from 0 (at this point in 1988) to October 2006,
that is a total of 18 years at 160 aircraft per year, which amounts to 27,360 aircraft years (take the arithmetic mean of 18 and multiply by 160). At 2,000 landings per aircraft per year, that is a total of between 54 million and 55 million landings.
Of those (let us take it as) 55 million landings, there have been 3 in which some issue related to thrust control has resulted in an accident, with a total of 3 deaths (ground deaths, no passengers and no crew). These incidents are
* 22 March 1998, at Bacolod
* 28 Aug 2002, at Phoenix
* 18 Oct 2004, at Taipei-Sung Shan
Even if we suppose that TAM Congonhas on 17 July was an addition to that list, that is still less than one serious problem every 10 million landings.
Just to put that in perspective, the U.K. Health and Safety Executive considers a risk to be "broadly tolerable" if it is less than one in a million per year. British roads are the second-safest in Europe, and one has one chance in 20,000 per year of dying on the roads in the U.K. The "background level of risk" from all sources is taken to be one in a hundred per year.
So, at most one thrust-control screw-up every ten million landings. If we take the average flight in an A320-series airplane to be 1.5 hours (including the customary 15 minutes for ground ops), that amounts to at most one thrust-control screw-up every 15 million flight hours. How many total career hours on A320-family airplanes are people likely to have? Say 10,000? That is, just one in 1,500 career A320-series pilots may have a thrust-control problem on landing just once in hisher career.
I don't see much of an argument there for querying the logic of the system design. With the best available digital-system design principles we can only guarantee freedom from error to within about one in 100,000 logic actuations, and we are talking about this system design to be about 100 times more reliable than that.
I was taught, from day 1 of my flight training:
* stabilised approach
* approach speed about 1.3 times stall speed
* gear down (and welded
)
* flare when within appropriate distance from ground
* throttle to idle
As far as I know, this is standard procedure on all airplanes.
When designing automation for flying, then one principle enunciated by Charles Billings and others which has gained currency is that of "human-centered automation". That is, in a device with human operators, the automation should be designed to support the human-operator tasks. Since this list above is more or less axiomatic, the question becomes how automation could best support these actions. Since the pilot must fly the airplane, heshe must ensure a stabilised approach and not the airplane - there are times when one
wants to deviate (to avoid hitting intruders, for example). V.Ref is ensured through autothrottle. Gear down is aided through warnings and inhibitions, as is throttle retardation.
The question whether the thrust should automatically be set to idle at flare is a question of subtleties and extraordinary situations which would occur, if at all, then very rarely. As has been pointed out (subsequent to this post) by others, the human mind is limited in its ability to conceive of these rare extraordinary situations, so one must be very careful about reaching too far.
For all but a handful of cases in 55 million landings, relying on the pilot to retard the throttle upon flaring has proven to be appropriate, as one might expect. Because all pilots are trained to do it from Day 1. Before the phenomenon, of some rare pilots in some very rare landings in the A320 not retarding thrust levers, is well understood, it seems to me premature to suggest building in prophylaxis in the landing logic, unless one can be assured that it introduces no new anomalies into other rare situations.
This is an edited post, the original being shortened due to my apparent inability to handle the editing SW.
The A320 family was introduced in 1988 and until October 2006 there were 2,880 aircraft of this family delivered (Flight International, 24-30 October 2006). That amounts, assuming a constant rate, to 160 aircraft per year, assuming no attrition (there has been some, of course, namely 18 hull losses, but I am ignoring it). Taking a service year to have 333.33 days and taking each aircraft to fly an average of 6 legs per working day, that is 2,000 landings per aircraft per year. At 160 aircraft per year from 0 (at this point in 1988) to October 2006,
that is a total of 18 years at 160 aircraft per year, which amounts to 27,360 aircraft years (take the arithmetic mean of 18 and multiply by 160). At 2,000 landings per aircraft per year, that is a total of between 54 million and 55 million landings.
Of those (let us take it as) 55 million landings, there have been 3 in which some issue related to thrust control has resulted in an accident, with a total of 3 deaths (ground deaths, no passengers and no crew). These incidents are
* 22 March 1998, at Bacolod
* 28 Aug 2002, at Phoenix
* 18 Oct 2004, at Taipei-Sung Shan
Even if we suppose that TAM Congonhas on 17 July was an addition to that list, that is still less than one serious problem every 10 million landings.
Just to put that in perspective, the U.K. Health and Safety Executive considers a risk to be "broadly tolerable" if it is less than one in a million per year. British roads are the second-safest in Europe, and one has one chance in 20,000 per year of dying on the roads in the U.K. The "background level of risk" from all sources is taken to be one in a hundred per year.
So, at most one thrust-control screw-up every ten million landings. If we take the average flight in an A320-series airplane to be 1.5 hours (including the customary 15 minutes for ground ops), that amounts to at most one thrust-control screw-up every 15 million flight hours. How many total career hours on A320-family airplanes are people likely to have? Say 10,000? That is, just one in 1,500 career A320-series pilots may have a thrust-control problem on landing just once in hisher career.
I don't see much of an argument there for querying the logic of the system design. With the best available digital-system design principles we can only guarantee freedom from error to within about one in 100,000 logic actuations, and we are talking about this system design to be about 100 times more reliable than that.
I was taught, from day 1 of my flight training:
* stabilised approach
* approach speed about 1.3 times stall speed
* gear down (and welded
)* flare when within appropriate distance from ground
* throttle to idle
As far as I know, this is standard procedure on all airplanes.
When designing automation for flying, then one principle enunciated by Charles Billings and others which has gained currency is that of "human-centered automation". That is, in a device with human operators, the automation should be designed to support the human-operator tasks. Since this list above is more or less axiomatic, the question becomes how automation could best support these actions. Since the pilot must fly the airplane, heshe must ensure a stabilised approach and not the airplane - there are times when one
wants to deviate (to avoid hitting intruders, for example). V.Ref is ensured through autothrottle. Gear down is aided through warnings and inhibitions, as is throttle retardation.
The question whether the thrust should automatically be set to idle at flare is a question of subtleties and extraordinary situations which would occur, if at all, then very rarely. As has been pointed out (subsequent to this post) by others, the human mind is limited in its ability to conceive of these rare extraordinary situations, so one must be very careful about reaching too far.
For all but a handful of cases in 55 million landings, relying on the pilot to retard the throttle upon flaring has proven to be appropriate, as one might expect. Because all pilots are trained to do it from Day 1. Before the phenomenon, of some rare pilots in some very rare landings in the A320 not retarding thrust levers, is well understood, it seems to me premature to suggest building in prophylaxis in the landing logic, unless one can be assured that it introduces no new anomalies into other rare situations.
This is an edited post, the original being shortened due to my apparent inability to handle the editing SW.
Last edited by PBL; 31st Jul 2007 at 11:46.
Join Date: Dec 2006
Location: washington,dc
Posts: 486
Likes: 0
Received 0 Likes
on
0 Posts
IF a pilot has to do everything, every time, he is in the loop.
if he watches the machine do everything every time he is monitoring and slightly removed from the loop.
if he expects the plane to do everything and then wonders why it doesn't...he is dead.
if he watches the machine do everything every time he is monitoring and slightly removed from the loop.
if he expects the plane to do everything and then wonders why it doesn't...he is dead.
Join Date: Jul 2007
Location: Paris, France
Posts: 14
Likes: 0
Received 0 Likes
on
0 Posts
Among the 700 posts was this brilliant exercise of pure logic:
The perspective to get close to what made sense to the crew on that moment worth waiting for the next 700 posts.
None of this process described deals with or accomodates the broader organizational aspects which may or may not play a crucial role in creating an environment conducive to an accident. Investigations into corporate culture, training priorities and footprints, corporate predispositions and priorities (or not) to fostering a safety culture are all part of any investigation as are the immediate human factors which may have led a perfectly sentient, highly trained crew to mis-perceive or simply not see circumstances which would permit a crew to interpret an extremely high-risk event as "normal". No crew sets out to end up this way, so the human factors question which must be answered is, "what, in the moment, 'made sense' to the crew which caused them to act in the way they did?" We who sit with both time and huge amounts of data need to re-build the few seconds in which such interpretations were made by professional, highly-experienced airmen.
Join Date: Jan 2005
Location: Grand Com f'Ort
Posts: 376
Likes: 0
Received 0 Likes
on
0 Posts
"brilliant exercise of pure logic"..?
brilliant exercise of pure logic
Anytime now, someone will post 'No-one goes to work to die' as their own work.
Join Date: Jan 2006
Location: here, there, everywhere
Posts: 279
Likes: 0
Received 0 Likes
on
0 Posts
Discussion re. the Airbus thrust control system reminded me of this thread:
http://www.pprune.org/forums/showthr...Airbus+landing
The thread starter asks:
What baffled me (and it was BEFORE the TAM crash), was that there were several different answers to the original question... That shows that the AB non-moving TL design, if not flawed, is at least prone to confusion and not fool-proof enough. To much of "what is it doing now's"...
Just my 2p. worth
http://www.pprune.org/forums/showthr...Airbus+landing
The thread starter asks:
What happens if I do not set THRUST idle in
AUTO LANDing even after touchdown ????
AUTO LANDing even after touchdown ????
Just my 2p. worth
PJ2
Affirm. You know what you write about, and you do it better than most. I would sleep well with you in the cockpit because you know your systems and you know the what it is all about in aviation.
But I disagree about the "extremly rare circumstances". This forum has had many issues about technically inspired human factors, regardless of the makes. Far too many accidents have occurred because the pilots where not grasping the basic problem, confused by the behaviour of the plane and thus did not come up with a timely solution. Frozen over EPR gauges, plastic tape on the pitot tube, FMS route not being properly programmed, confusion about altitude, climb rate or speed selection an the autopilot, cabin altitude warning misinterpreted, you name it.
I am fully aware that human factors play a major part in these dramas, but we all know that ergonomics and simple procedures can save the day together with crew training, CRM and intelligent assisting systems. Pilots may be selected for quick thinking and memorizing complex procedures, but this ability has its limits as with all other professions.
I often had discussions about complex software issues. And I always voted for the simplest solutions, those where an operator feels assisted by the computer(s) and not thrown out of the control loop. Frankly, in my humble amateur opinion, the logic of the AB system to land a with one TR inop does align quite a few holes in the Swiss Cheese slices and the conditions that have to be met most certainly do not qualify as "easily understandable". And from reading the thread I doubt that all busdrivers could recall them in the few seconds that where left to the poor TAM crew once committed to land. Maybe the implemented logic saved a lot of other planes in distress. But in a fully automated plane i'd rather have my red button, possibly together with a green one for use in go-around.
The guys at Midway probably too, together with a lot of others that failed to stop within the fences.
Affirm. You know what you write about, and you do it better than most. I would sleep well with you in the cockpit because you know your systems and you know the what it is all about in aviation.
But I disagree about the "extremly rare circumstances". This forum has had many issues about technically inspired human factors, regardless of the makes. Far too many accidents have occurred because the pilots where not grasping the basic problem, confused by the behaviour of the plane and thus did not come up with a timely solution. Frozen over EPR gauges, plastic tape on the pitot tube, FMS route not being properly programmed, confusion about altitude, climb rate or speed selection an the autopilot, cabin altitude warning misinterpreted, you name it.
I am fully aware that human factors play a major part in these dramas, but we all know that ergonomics and simple procedures can save the day together with crew training, CRM and intelligent assisting systems. Pilots may be selected for quick thinking and memorizing complex procedures, but this ability has its limits as with all other professions.
I often had discussions about complex software issues. And I always voted for the simplest solutions, those where an operator feels assisted by the computer(s) and not thrown out of the control loop. Frankly, in my humble amateur opinion, the logic of the AB system to land a with one TR inop does align quite a few holes in the Swiss Cheese slices and the conditions that have to be met most certainly do not qualify as "easily understandable". And from reading the thread I doubt that all busdrivers could recall them in the few seconds that where left to the poor TAM crew once committed to land. Maybe the implemented logic saved a lot of other planes in distress. But in a fully automated plane i'd rather have my red button, possibly together with a green one for use in go-around.
The guys at Midway probably too, together with a lot of others that failed to stop within the fences.
Join Date: May 2004
Location: Canada
Posts: 52
Likes: 0
Received 0 Likes
on
0 Posts
Here is a good article on the accident...........
http://www.salon.com/tech/col/smith/.../brazil_crash/
Dave Fisher
http://www.salon.com/tech/col/smith/.../brazil_crash/
Dave Fisher
Join Date: Aug 2005
Location: SEA (or better PAE)
Posts: 215
Likes: 0
Received 0 Likes
on
0 Posts
Bomarc, with all do respect and regarding your post #732,
Pilot is always in the loop, be that B or AB or whatever OEM we talk of, for decades in the past.
Were you ever exposed to any level of flight laws curriculum in any form, with all do respect? Sims (real ones), guidance and control commercial s/w or equipment design/support?
How can you say that with a straight face?
As for the automation in aviation and all the related issues (guidance, control and all the aspects of flight mechanics) benefits are immense. Its (automation's) application should be an axiom, IMHO.
Or maybe I misread your statement? In that case, apologies.
Cheers
IF a pilot has to do everything, every time, he is in the loop.
if he watches the machine do everything every time he is monitoring and slightly removed from the loop.
if he watches the machine do everything every time he is monitoring and slightly removed from the loop.
Were you ever exposed to any level of flight laws curriculum in any form, with all do respect? Sims (real ones), guidance and control commercial s/w or equipment design/support?
Automation is not the answer to safer flying.
As for the automation in aviation and all the related issues (guidance, control and all the aspects of flight mechanics) benefits are immense. Its (automation's) application should be an axiom, IMHO.
Or maybe I misread your statement? In that case, apologies.
Cheers
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Grunf
As for the automation in aviation and all the related issues (guidance, control and all the aspects of flight mechanics) benefits are immense. Its (automation's) application should be an axiom, IMHO.
I would expect the automation to do the tedious part of the job better than me, be it a simple heading hold or performing an autoland.
I would NOT expect it to do something that I wouldn't do in the first place.
Join Date: Aug 2005
Location: SEA (or better PAE)
Posts: 215
Likes: 0
Received 0 Likes
on
0 Posts
I fully agree. Of course that still does imply the improvement of safety with automation. One might add appropriate amount of automation. B vs AB (why not including OEM from Russia, Ukraine etc?), it does not matter.
Sadly, cases like this might become (and they probably will) cause for a new control s/w update.
Sadly, cases like this might become (and they probably will) cause for a new control s/w update.
Last edited by Grunf; 30th Jul 2007 at 22:59. Reason: spelling
Join Date: Aug 2005
Location: fl
Posts: 2,525
Likes: 0
Received 0 Likes
on
0 Posts
Automation is nice on a perfect day if you want to auto land but what about the day you touch down on an icy or slick runway and say one reverser doesn't work? How about if both reversers work but the crosswind has you cocked into the wind but sliding off the downwind edge of the runway with the reversers in full reverse but you have plenty of runway left? Does the automation know to reduce reverse to stay on the runway and even with a bit of pilot skill use the differential reverse to help get you straight again? All the Boeings I flew, on auto land, the pilot controlled the reversers but can't imagine letting the auto land control everything else while you only managed the reversers on a situation like that. You certainly have little time to monitor annunciators about deceleration, etc. I know this has little to do with this accident, just how monitoring automation takes you out of the loop.
Join Date: Feb 2002
Location: Somewhere between Europe and Africa
Posts: 154
Likes: 0
Received 0 Likes
on
0 Posts
Even in autoland , AB doesn't put automatically reverse. This still has to be done manually.
Automation is nice on a perfect day? of course it is, and most of the days are perfect too.
By having automation, doesn't mean you're out of the loop. You are telling the "automation" what the aircraft should do and if you don't like it, there's always that little red button and voilá...
But now talking about the other red button clearedtocross talked about, I find one glitch. If Mr. murphy is on and that button is inoperative?
I believe pilots do like the "stop and think later" mindset, that's why we have procedures to do in case of emergencies. When we don't have the time to think, we quickly analyze the situation and take proper action. Either way the aircraft doesn't stop...
Check Six Krueger....
Automation is nice on a perfect day? of course it is, and most of the days are perfect too.
By having automation, doesn't mean you're out of the loop. You are telling the "automation" what the aircraft should do and if you don't like it, there's always that little red button and voilá...
But now talking about the other red button clearedtocross talked about, I find one glitch. If Mr. murphy is on and that button is inoperative?
I believe pilots do like the "stop and think later" mindset, that's why we have procedures to do in case of emergencies. When we don't have the time to think, we quickly analyze the situation and take proper action. Either way the aircraft doesn't stop...
Check Six Krueger....
The "one-button-saves-all" approach is magical thinking and not appropriate to aviation
Still, there are some cases where a clean way to reset the systems to basic operation (throttle are in sync with engine thrust for instance...) complemented some optional aditional and basic help to recover from emergency situations (stop the plane NOW, get to level flight NOW, Go Around NOW) could save the day...
Just my 2c
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
....where the pilot simply doesn't understand what's happening with the plane. The Airbus chief test pilot and 6 fellow airmen were killed in such an occurrence (ok, it's a bit of oversimplification)...
Quite to the contrary I'd expect the aircraft not to try to "over think" but just do what it's asked to do... Ok I understand there is no easy response here but I very much feel that in the TAM case (a) it could have stopped from the touch down point and (b) the pilots never fully realized what was going on... 
Again my 2c... will revisit this post in a year with the full report at hand.
Again my 2c... will revisit this post in a year with the full report at hand.
Last edited by atakacs; 30th Jul 2007 at 23:12.