Accident Analysis: Hardware versus software
A little history’s in order. When Piper introduced the Arrow in 1967, the company equipped it with a revolutionary safeguard for a complex trainer: an elegantly simple system to prevent gear-up landings by extending the gear whenever the combination of airspeed and power setting dropped below a pre-set level. It worked beautifully for its intended purpose. Flying with a factory pilot, AOPA Pilot’s reviewer found herself unable to touch down before the gear extended, even when she tried.
Unfortunately, it sometimes also worked when it wasn’t needed. If the pitot mast controlling the system iced over, the gear could come down in IMC. If the pilot tried to climb at too low an airspeed, it would refuse to retract, preventing the airplane from gaining either airspeed or altitude. Manually overriding the gear added to pilot workload at inconvenient times, and in 1988 Piper issued a service bulletin—later retracted—recommending its removal. A senior member of AOPA’s management—who recently experienced that difficulty with gear retraction after takeoff—said in no uncertain terms that he’d prefer the airplane let him control it directly rather than trying to save him from himself.
The same could be said about advances such as envelope protection. Do you want the aircraft fighting you when there’s a good reason—say, collision avoidance—to make an extreme maneuver? But it’s also true that in-flight upsets cause far more deaths than midairs. Ultimately, it’s a question of what to trust: your own judgment and skill, or the vision of engineers and programmers who tried their best to anticipate your needs. Should this be a difficult choice?
