PBL made some interesting points regarding data that promotes a level of safety to be gained by relying increasingly on the computer/automation. The problem is that the depth of inquiry and investigation over accidents, where the combined man/machine lash up failed, is orders of magnitude deeper than the depth of inquiry into those events where "it nearly went pear shaped" or other system issues arose but the plane landed safely. It is my guess that any number of events of that sort are never captured. There may be "conventional wisdom" or a variety of anecdotal evidence about how poor a given system is, but until failure, or near catastrophe, where is the data that allows one to make a case for change or improvement? Within each organization I suspect that the attention paid to the "not quite right but it didn't kill us this time" varies. That leads to the idea that data for analysis is further skewed, as a certain percentage of this will remain "in house" for a variety of reasons.
In gross terms, the analysis scheme PBL was resting upon in the linked article somewhat resembles "counting the hits and ignoring the misses." As a data collection method on the man/machine system, this seems a step toward a technique that is a No-No of significant severity. You have to account for the hits
and the misses to get a sense of what your data is telling you. (An example is the rigor of drug tests in the US that FDA gets all shirty about ... and even then the outcome isn't perfect). I am not convinced that data collection by exception is going to take the industry in the proper direction, since it looks to create a built-in bias.
As an industry (I recall discussing briefly with PJ2 some FOQA issues a while back) there are disincentives and obstacles to the industry wide sharing of "hey bubba" moments and lesser "it went wrong" incidents that were not fatal. But I also understand that there are programs to do just that.
A few pages back, one of the old hands called for a required debrief session after each leg or trip. Having grown up in military flying, that was part of the event. The sortie was not complete until we'd all sat down, cigarettes and coffee in the old days, coffee and nothing more recently, and walked the mission front to back in about ten to fifteen minutes to see what we did right, wrong, and what to do about any of it. The CRM environment the Navy got very involved with encouraged this in terms of the working the approach to the debrief as a no fault event.
That left the sticky issue of dealing with SOP and Rule breaches. If during a flight, something blatantly wrong was done or commanded, then what? (Oh, by the way, what rule set did the organization overlay on the system? Varies by organization). Sometimes, the PIC would address it formally. Sometimes, it was the PIC who was the culprit. The Navy's Anymouse program was able to bring to light a few of these things, via a non-attribution safety gram entering the flight safety system and "something not right" was aired rather than being buried. I will guess that airlines have similar structures in place. If the culture of the flying professionals in the organization is "I can be a better aviator/crewman/crewmember" each day, the above system worked better than when that attitude was not evident in the organizaiton from top to bottom.
What has this to do with Computers in the Cockpit and aviation safety?
The debriefing and the documentation of any and all, even seemingly minor, hitches and glitches on each and every system ought to be part of every flight. The designers and those who work on system improvement and adjustments need data in order to get get funds for system adjustments or improvements. So too those who keep track of training and proficiency of aircrews.
Are man/machine interface issues handled well enough in your (or any) organization?
Snipped the rest, as I am wandering into areas I don't know enough about.