Seems to me like redundancy and failure analysis was an afterthought for the design team. This is a case that proves, do a complete analysis before actually going ahead with a build. I have worked at many places where they wanted me to just design on the fly. I would fight them to let me do a complete requirements, failure, and design analysis before doing the full project. But, I was told otherwise.
For the record, that company was audited. After which, complete analysis was a requirement.
Reports suggest that the pilot believed the faulty airspeed readings and was pitching the aircraft up until it stalled. The aircraft was capable of flight, it just had a bad instrument. If I'm ever faced with a similar situation I hope I don't make the same mistake.
There was a crash in Washington DC back in the Eighties that was similar. The engine thrust sensors in the aircraft had iced up during takeoff and were giving an erroneous reading. Even though the aircraft was stalling the pilot never increased power because he believed that one instrument rather than the data he was collecting from all the other sources.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.