So is the industry prepared to move the weakest link in the chain from the flight deck to guy who wrote the code?? In reality this really doesn't do anything it would just maybe fix one problem and create a new one that doesn't exist at the moment.
I'm afraid it does exist at the moment, an A320 was written off because both pilots pulling back stick were unable to flare the aircraft for landing.
http://www.fomento.es/NR/rdonlyres/8...006_A_ENG1.pdf
A330 upset, note the use of the word "probably" in the report, not a comforting assessment. Captain retired with PTSD, one tough day at work. The report has a good discussion on computerisation.
One of the aircraft's three air data inertial reference units (ADIRUs) started outputting intermittent, incorrect values (spikes) on all flight parameters to other aircraft systems. Two minutes later, in response to spikes in angle of attack (AOA) data, the aircraft's flight control primary computers (FCPCs) commanded the aircraft to pitch down. At least 110 of the 303 passengers and nine of the 12 crew members were injured; 12 of the occupants were seriously injured and another 39 received hospital medical treatment.
Although the FCPC algorithm for processing AOA data was generally very effective, it could not manage a scenario where there were multiple spikes in AOA from one ADIRU that were 1.2 seconds apart. The occurrence was the only known example where this design limitation led to a pitch-down command in over 28 million flight hours on A330/A340 aircraft, and the aircraft manufacturer subsequently redesigned the AOA algorithm to prevent the same type of accident from occurring again.
Each of the intermittent data spikes was probably generated when the LTN-101 ADIRU's central processor unit (CPU) module combined the data value from one parameter with the label for another parameter. The failure mode was probably initiated by a single, rare type of internal or external trigger event combined with a marginal susceptibility to that type of event within a hardware component. There were only three known occasions of the failure mode in over 128 million hours of unit operation. At the aircraft manufacturer's request, the ADIRU manufacturer has modified the LTN-101 ADIRU to improve its ability to detect data transmission failures.
It is generally accepted that, for all but the simplest systems, it is impossible to guarantee the correctness of all the system requirements and associated assumptions.
The current aviation system has an enviable safety record; however, advances in technology are placing an increasing strain on our ability to assure the integrity of new and anticipated systems.
https://www.atsb.gov.au/sites/defaul.../ao2008070.pdf
Boeing 777 upset
The ADIRU OPS versions up to and including version -07 contained a latent software error in the algorithm to manage the sensor set used for computing flight control outputs which, after the unit went through a power cycle, did not recognise that accelerometer number-5 was unserviceable.
An anomaly existed in the component software hierarchy that allowed inputs from a known faulty accelerometer to be processed by the air data inertial reference unit (ADIRU) and used by the primary flight computer, autopilot and other aircraft systems.
When the hardware failure occurred, combined with the software anomaly, the crew were faced with an unexpected situation that had not been foreseen.
The software anomaly was not detected in the original testing and certification of the ADIRU.
https://www.atsb.gov.au/sites/defaul...503722_001.pdf
Pilot error would just be replaced by computer design and software coding errors.