Mistakeology
My concern is a systems concern,
The software engineer works in an environment that makes assumptions about its upstream inputs (eg, a sensor might fail - et al,) and downstream consequences.
Within that is the acknowledgement that the downstream resources (eg. fault condition SOPs - et al.) cannot cater for all eventualities and so must rely on pilot professional competence & expertise.
The assumptions (eg middle value is safe - et al.) exploiting multiple redundancy can render the remaining two of three working transducers worse than a singleto, since failure of either would give an erroneoous result - the Australian 777 episode exemplified this,
Iin that case, flying with a faulty third channel was worse than the system having no redundancy, Has this now been built into all triple redundancy middle value systems?
In both that case and the ill fated Air France episode, incorrect transducer readings were not sufficiently visible to the pilots - the last resort safety sytem - for it to be obvious to them just what was happening. Even the last resort 'hand fly the beast' option has to be negotiatedwith a software system that is already percieved - at lest partially - as working otherwise than as intended,
It is the combination of reliance on the pilot and being unable to guarantee to present the information the pilot needs that give the total system a level of vulnerability that can make a safely redundant system dangerous in the presence of a known failure.
An MEL that says a defective component can be tolerated must demonstrate a safe system (including a suitably informed pilot) in the event of ANY subsequent failure.
And when the statisticians do their sums, making standard 'independence' assumptions, they must be obsessive about them, as must everybody from people buying components to the authors of safety procedures,