From: "Mark A. Brown" <email@example.com> Date: 29 Jul 96 02:29:36 References: 1
View raw article or MIME structure
> I have been reading over the old archived posting of this news group > (many thanks to you, moderator!) and have come across a large number > of postings regarding accidents or near accidents involving automation > in the "glass cockpit" aircraft. A recurring theme seems to be the > pilot fighting the computer control system in an attempt to regain > manual control of the aircraft in an emergency. I'm not sure what you mean by "fighting the computer control system". Could you give some more specific examples, or do you have something like the following in mind. - Nagoya crash - primary reason for the crash appears to be that pilots triggered TOGA and then tried to override the autopilot's pitch up commands without disconnecting it. - This was with an older-generation Airbus aircraft which is not, I believe, a glass-cockpit type. You don't have to be in a glass cockpit to encounter automation problems. If you punch the A/P disconnect button you should get three-axis manual control back, glass cockpit or no, FBW or no. (Autothrust disconnect on the A320 etc. is a little more difficult because you have to move the thrust levers to synchronise the demanded thrust markers with the current thrust levels before you push the tit, otherwise you get a thrust demand change on disconnect, but again, if you disconnect, you get thrust control back.) BTW, "total" throttle control is a misnomer -- the pilot already has more limited authority of the engines due to FADEC. The more sinister problem with cockpit automation is _not_ the fact that pilot authority may be limited at the extremes of the flight envelope, but the fact that sometimes the pilot is not aware of the current mode of the autoflight systems, and the ramifications of being in a particular mode. Further, the computer's logic can sometimes be non-obvious and non-intuitive. For example, when you pulled the lever for ground spoiler on non-automated aircraft, then you got spoilers (perhaps gated by the weight-on-wheels or undercarriage compression sensor). Nowadays, the logic tends to be more tortuous, with factors like weight-on-wheels and wheel spinup speed being taken into account, and the fact that the handle has been pulled is just an indication that the command has been issued, not an indication that it has been executed. Just a personal opinion, but another worry is that over-reliance on automation may be leading to a loss of basic airmanship. IMHO, poor airmanship was displayed at the Mulhouse/Strasbourg accident (the pilot made a low, slow pass with his engines at flight idle over an airfield at below the height of obstacles in front of him), the Bangalore crash (pilots were slow to recognise the situation, slow to take control) and the Strasbourg/La Bloss Hill accident (pilots didn't monitor the situation sufficiently to realise that 3300 fpm descent rate had been selected instead of 3.3 degree flight path. The rate of descent on the VSI alone should have been enough to indicate something amiss). It is difficult to ascribe blame, with other factors -- please note that these are just my opinions. > I realize that some exotic high-performance military aircraft achieve > superior performance by accepting inherent instability which is neatly > overcome by mandatory autopilot assistance, and that such aircraft may > indeed be totally unflyable by ordinary mortals without such > continuous assistance. I find it beyond belief that newly designed > airliners of the past decade are unstable, other than to Dutch Roll > and our old friend phugoid oscillations. They _aren't_ unstable per se, and even FBW airliners may be flown in "direct law" with just "signal by wire" and no computer scheduling. > I also realize that some tiny additional increment in safety may be > achieved by automatically preventing overstressing the airframe by a > ham-handed pilot, but surely this is the classic case of a solution > looking for a problem. I would have though that things like alpha protection, _when properly applied and where the pilot understands the logic of the system_, are a good asset, especially in manoeuvres like terrain avoidance and windshear, where aggressive control inputs are needed. Again, the problem is more one of mode awareness, especially in control law changes which are essentially transparent to the pilot. If you're going to have FBW, then a change in control laws to give envelope protection is basically a software hack, and is straightforward -- there is no additional hardware cost in implementation. > Another pet peeve is the required manual computer keyboard input of > such numeric values as rate of descent. Not all numerical values are entered on keyboard, or this would be clumsy indeed. When flying the aeroplane via the autopilot, there are knobs or dials on the mode control panel which control numerals in windows. You turn the knob and the number clicks up or down. For example, with heading, if you want to turn left 10 degrees, you turn the knob left until the desired heading appears in the window. > I have no objection to this, > especially as no really graceful substitute for such data entry comes > to mind. But surely it would add very little cost to provide a > computer voice confirmation of exactly what the pilot has actually > entered, not, of course, what he THOUGHT he was entering. Problems here are habituation -- just because you provide a voice, there's no guarantee that it would be listened to -- and workload -- a voice may be a distraction where you are working in a busy terminal airspace, being vectored by ATC, descending and losing speed. A system employed by some airlines at the moment is to use the other person in the cockpit to confirm the value you've entered. The pilot not flying can make sure that you've put in the correct value, whereas a voice just repeats back what you've entered and does no "sanity check". Just my humble opinions. Mark.