true, but coding errors aren't processor faults.



Yes, it will, because those ARE processor faults, and, if they exist, shouldn't exist consistently throughout all the mfg's production. If they do, the mfg is legally liable, and that should show up quickly and result in the bankruptcy of the mfg. and its elimination from the gene pool. These would show up in a test environment, however, and not in an application. Since the goal is to detect processor faults and not necessarily to design a bomb-proof application, I think that's adequate. If an MCU is subjected to the typical 100-hour burn-in in such a fixture, and cycled over its specified temperature and voltage range, it should stand out if there's a fault. Normally, there would only be one device under test, and two control devices known to be "perfect."



If the inputs are garbage and the outputs are consistent, it won't detect that condition, because it's not a processor fault.

The Shuttle, BTW, didn't use triple redundancy, but, rather a dual redundancy scheme, combined with algorithms designed to anticipate valid "next" inputs. There were two of everything, including the wiring and sensors, e.g. LVDT's, etc. in the pre-'86 version, which was the one I analyzed post-Challenger-disaster.



True, but that can also be made redundant, in which case it will, again, be detected unless all the CPLD's are defective in exactly the same way. Aside from that, you really must draw a boundary between the test system and the device under test. Remember, there normally would only be one device under test, and two control devices known to be "perfect."



That, too, is all too true!

RE