A large part of this that is being missed is that the software is providing conflicting cues and there is a mismatch between what the airplane is doing and what the software is indicating, and what other software is commanding. We are in a new regime of problems that did not occur prior to software being a large part of the mix. Prior to the 1980s these accidents were pretty linear, but that is just not the case anymore. I would recommend Nancy Leveson's "Safeware" to get some basis for what we are seeing. I am doing a talk at ISASI in SAN coming up here in a couple of weeks (
http://isasiannualseminar.com/) with one of the MIT research professors in which we are directly addressing the issue of how to analyze accidents that are part of a complex system, in particular where software is part of the mix. It is complicating things far more than most realize. We are demonstrating STAMP as applied to Asiana 214 as an example of the power of the technique developed by Nancy. I hope you can attend, it will be worthwhile.
One of the issues is that we have to get some back to basics going in training. Automation is supposed to be a workload reducer ideally. Where old heads back in the day who went from dials to automation had the challenge of learning to reduce their workload by incorporating it; more and more that is shifting to pilots who don't know what to do without it, or how to manage their workload when its operating degraded. Systems....avionics/automation knowledge, to include associated hardware and software, is becoming more and more important as automation advances; yet still seems to be a weaker point in some accidents. Sure, when the A320 was new at Air France in 1988, and the crew put flight 296 into trees by placing the jet into a square corner that it would not allow them to recover from in the way they wanted to recover; that can be attributed to the newness of automation and its capabilities and limitations (such as alpha protection) at the time being less than ideally understood, and contributing in a tertiary manner to the errors made. But today, we've come so far as to where automation is the standard rather than the exception, and systems understanding should be well above what it appears to be in some of these accidents. Not talking knowing how to build the automation, but how to reasonably use it and what to expect from it in both normal as well as abnormal situations.
And even further, what to do when it becomes abnormal to the point of being more hinderance than help. The F-117 was one of the earliest planes after the F-16 with fly-by-wire that was tied into an autopilot that was cued by an INS-derived nav/attack computer. The training on that jet was
very automation-heavy focused: what the automation does, how it does it, when it does it, why it does it, how it tells you what its doing, what its capabilities and limitations are, what happens when different malfunctions occur and how it tells you what's occurring at those times as well as what it now cannot do for you. The idea was to stay ahead of the jet and its automation at all times when being a systems monitor, but more importantly, when to step in as a pilot and take things over yourself when things stopped looking/feeling/sounding right with what the jet was doing or what it was telling you, especially if its telling you that its "sick", or otherwise operating degraded for some reason. Being ready to either go degraded or take manual control, was something that one had to always be prepared for and ready to execute, just like as if flying a single-engine Cessna and always having somewhere out in front of your windscreem ready to be a landing place to aim for were the engine to quit.
Whether and to what depth (if so), similar levels of understanding are taught at airlines around the world today with regards to automation aircraft, Im not sure. But if the crash of AF447 is any indication, then we may be wanting to ask ourselves again, "how are WE doing business" as it comes to factors which should have been apparent to the experienced hours-wise crew here; yet ended up not being.