Hey BOAC,
I'm jumping in here and want to start by saying that as a long-term lurker and occasional poster I have a deep and abiding respect for you and your opinions. Alas I haven't had the joy of being at the controls of an aircraft since my AEF days (I ended up with long hair, pacifism and rock music in short measure around the age of 14
, but I do know a fair bit about the process of software development. And while I didn't end up having the skill to work in the kind of real-time software development that backs up FBW technology, I was fortunate enough to be taught by someone who was.
While I agree substantively with the point that pilots be trained in identification of automation failures and correct responses to same, I feel that the quote you posted betrays some misunderstanding of the processes involved.
• Review all software control and hardware control logics and
combinations thereof to ensure that all probable defect possibilities
are identified
I was privileged enough to be shown examples of the processes that Airbus went through to define potential system failure points, and I have to say that "exhaustive" doesn't even begin to describe the tiniest fraction of the detail they went into (I suspect that Boeing were every bit as stringent). Software engineering at its purest is a discipline that is the equal of any more traditional mode of engineering one can think of. The problem is that as with any engineering discipline, the scope of failure testing is limited by the imagination of the engineers concerned. Mistakes were made, and compounded with bullish sales techniques, when the first failures occurred there was a sense of falling to hubris. But the same could also be said of transitioning from props to jet transports, or from mechanical to hydraulic controls.
• Review the processes used to introduce modifications to control
software since issuance of the original type certification, e.g. consider
a recertification process; and
• Verify that appropriate resolutions for such occurrences have been
developed and are in place to prevent un-commanded actions that
can result in an accident.
Again, not something limited to software-based automation, and resolution of such should be treated as any other AD. Every software modification that I've heard of being applied to flight control systems - even those considered major in terms of importance - have tended to be very minor in terms of the actual physical effect produced. Having said that I do agree that any such changes, and any alterations to piloting technique prior to those changes being applied, should be communicated to pilots at the first opportunity.
• Improve the robustness of the software/hardware logic through the
introduction of additional parameters to consider prior to an automatic
change is critical control surfaces.
Here I come back to engineering. In software, as in mechanical or any other engineering discipline, added complexity tends to increase potential points of failure. As such, any engineer worth their salt will be very careful about introducing an increase in complexity. In the case of BA056, armed with the information from that incident one could make a good case that extra input parameters would be helpful. However, it is a decision that should be made in a logical manner, and certainly not in the heat of the moment.
• Introduction of a flight deck crew “alert/approval/override” facility prior to an inadvertent change to critical control surfaces.
An understandable reaction in the circumstances, but again one must be wary or added complexity (and like it or not, an override does introduce further complexity).
• Account for spurious mechanical and electrical failures and their
impact on the software and hardware logic system.
We're back to the limits of engineering experience and imagination. There's absolutely nothing wrong with the statement - but again you'd be amazed how many failures are accounted for in the design of such systems. It is, alas, impossible to account for all of them. In the case of BA056 we're talking about a dual engine failure at a hot and high airfield caused by a side-effect of a maintenance procedure that only affects a single type of engine. I think in this case the oversight should be forgiven.
• Operators should provide flight crews with more basic hand flying and simulator flight training on new generation aircraft to address the
technological developments in aviation, inclusive of effective stall
training.
I'd call that stating the bleedin' obvious, and that any air transport operator using advances in automation as an excuse to skimp on training should have the book thrown at them. Regardless of how easy automation makes things when the winds are fair, preparation for and understanding of how things can go wrong should be paramount in pilot training before graduating from single-engine circuit-bashing. But the firms doing the training at the early stages must take responsibility too.
Getting down to the fundamentals, the fact is that advances in aviation have come at the price of painfully-learned lessons before and after the introduction of digital technology in the flight deck. The killer is and always has been human complacency.