There's a recent econtalk episode that delves into transferring control from machine to human. Specifically, regarding the air france disaster:
"The Air France story is a story about a failed handoff, where the automation onboard an airplane found a relatively minor fault and handed control of the plane back to the human pilots, too suddenly and ungracefully surprised them. And they had lost some of their skills flying too much with the automated systems and lost control of the airplane. Which actually was a perfectly good airplane about a minute into the crisis. And so they went from tens of thousands of feet flying through the sky and ended up spiraling into the ocean, tragically losing all aboard."
That tragedy was probably the seed of my concern. Lately i've been thinking a lot about how automated systems become brittle. The systems don't change, people forget the dependencies and requirements and in something real time like an airplane, the feel of the system.
A configuration management system that incorporated spaced repetition would be cool. Every once in a while, go into an incremental mode where you actually type in the commands. It has the added bonus of getting new people aware of the system. Sure, you can always just go read the source and figure it out. Having the system force some human awareness from time to time would be handy.
Why hand control back to a human when you can do even better?
Have them both handling control at the same time, reconcile the inputs in a sane manner (or have a master/slave where one is providing phantom inputs). Added benefit of being able to error check each other.
This was exactly the problem in the Airbus crash shown above; reconciling the inputs is hard. One pilot kept holding one stick back, unbeknownst to the other. This plane averages them by default, and therefore the plane stalled. That couldn't happen on a Boeing because the yokes are yokes (inputs on one are easily visible to both pilots) and physically linked.
(Supposedly the plane is supposed to loudly complain if the inputs diverge. I'm not sure if this happened.)
On the other hand, typical Airbus A330 operators probably have a lot better training about what diagnostic messages mean than typical HP LaserJet operators do.
On the other other hand, two pilots issuing opposite control inputs generally has a bit more impact than an empty printer tray. Boeing's relatively low-tech solution of making the two controls physically interlinked seems like a common-sense solution to a potentially immense issue.
But obviously the training did not suffice in the Air France case, because those were experienced Airbus pilots and they did not detect and resolve the contrary inputs.
As others point out, just because the warning is displayed as expected, does not make it a good warning.
In flight testing, whenever we encounter situations like this (the aircraft does not react as the pilot expects for a given input), we don't necessarily blame the pilot. Especially if multiple pilots get into the same mess. Then we know it's time to change how the aircraft behaves and bring it in line with what the pilots expect.
A little blinkenlight among the masses is easy to miss. Having your controls physically fight you because the other pilot is doing something is impossible to miss.
It was actually a voice alert. I'm not making any judgement about its appropriateness.
In fact by the time it arose, the aircraft may already have been in an unrecoverable dive (or whatever the word is for rapid descent while stalled), I don't remember. So it's not a primary cause of the accident.
A voice alert in a cockpit where people are probably frantically shouting at each other is just as ridiculous.
There's no substitute for physical feedback. It's instantaneous and impossible to miss. It's completely beyond my comprehension that Airbus eliminated it.
As I recall, the one pilot held full back stick all the way down, while the other pilot tried and failed to recover. Releasing the back stick and executing a normal stall recovery would have saved the airplane at just about any time.
I understand the Boeing approach of physical linkage to be the best idea, rather than any kind of indirect force feedback which is possible to misinterpret.
As for your last point, I'm not an expert, and I'm not as incredulous about this scenario as you seem to be. (As a teenager I did fly a lot in PC flight simulators, though.)
The non-technical Vanity Fair article I referred to claims that the accident investigators estimated the last point at which the aircraft could have recovered from the dive was around the time it passed 13,000 feet:
"Though precise modeling was never pursued, the investigators later estimated that this was the last moment, as the airplane dropped through 13,000 feet, when a recovery would theoretically have been possible. The maneuver would have required a perfect pilot to lower the nose at least 30 degrees below the horizon and dive into the descent, accepting a huge altitude loss in order to accelerate to a flying angle of attack, and then rounding out of the dive just above the waves, pulling up with sufficient vigor to keep from exceeding the airplane’s speed limit, yet not so violently as to cause a structural failure. There are perhaps a handful of pilots in the world who might have succeeded, but this Air France crew was not among them. There is an old truth in aviation that the reasons you get into trouble become the reasons you don’t get out of it."
If that's what they did then I believe it. I'm coming from a light aircraft background where stall recovery takes much less altitude. Still, they had about two thirds of their descent to initiate recovery before it became too late. If the controls had been linked, the other pilot would have discovered the problem instantly.
I don't understand why you'd want this averaging behavior at all.
When trying to get the plane onto the center of the runway, both pilots' actions are probably pretty correlated, and averaging could remove any noise (e.g., twitches).
But in many other circumstances, it seems like it would be downright dangerous. Something's in front of the plane. One pilot goes to the left, the other pulls to the right, and the system averages the commands and smashes straight into it.
The benefits of a marginally straighter landing don't seem like they would outweigh the potential of a massive catastrophe.
Perhaps all critical automated systems should have some level of Chaos Monkey testing built into them, though it might be best if it was good enough to not fail even if that test was failed.
Chaos Monkey is great. I'm suggesting something slightly different. Imagine you have a bunch of cent 6 machines that have been running great for years and years. upgrades go smoothly and deployment is a breeze. Now you need to upgrade to cent 7. Stuff that used to happen in init.d now happens in the systemd, for example.
Reviewing changes by hand every few months keeps you aware of what needs to happen. Automation doesn't get brittle, people forget how systems are flexible and inflexible. Spaced repetition would give people a chance to keep up with the current design, so when that crazy security vulnerability happens, you can jump in and change stuff knowing how it works, rather than having to figure it out on the fly.
I don't think it would take much. Configure a box today, tomorrow, next week, next month, 3 months, then perhaps every 6 months.
There are very smart people that sort of intuitively keep up with those kinds of changes. But those people change jobs. How do you get a mere mortal up to speed on 20-30 machine configurations? config management can configure hundreds of machines a day, no problem. but it's easy to forget what's really going into each of those boxes.
This is more about preserving organizational awareness, not so much robustness of a running system.
"The Air France story is a story about a failed handoff, where the automation onboard an airplane found a relatively minor fault and handed control of the plane back to the human pilots, too suddenly and ungracefully surprised them. And they had lost some of their skills flying too much with the automated systems and lost control of the airplane. Which actually was a perfectly good airplane about a minute into the crisis. And so they went from tens of thousands of feet flying through the sky and ended up spiraling into the ocean, tragically losing all aboard."
http://www.econtalk.org/archives/2015/11/david_mindell_o.htm...
https://en.wikipedia.org/wiki/Air_France_Flight_447