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;
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.
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.