Perhaps obscured by all the attention the apparent battery problem in the Boeing 787 Dreamliner is getting, another high-end aircraft problem has slipped by under the radar, so to speak.
A Wall Street Journal article (registration required) explains how Airbus engineers worked on a subsystem to enhance sensors for detecting icing on the A330 and other models. The engineers found the “icing-prevention devices championed… can have the opposite of their intended effect, causing key sensors on its aircraft to freeze up and triggering a potentially dangerous dive.”
That's not good at all, and it's a caution flag for all engineers. As processor- and software-based controls become increasingly pervasive and even dominant, they are being tasked to see more, know more, and do more. As a consequence, they are being connected to more and more sensors. Today's cars, of course, are a clear example of sensor-laden trends in mass-market product design. These sensors are generally analog in nature, even if their output is digitized, and they require analog signal conditioning.
The problem is that sensor technology is very good, but not perfect. It's not just a matter of miscalibration or a slight misreporting, such as being off by a fraction of a degree. Sometimes, how and where the sensor is positioned, what's positioned around it, nearby materials, or unrelated forces impinging on the sensor can cause it to give a very incorrect output — and you may not know it. (This article from Design News, a sister site, offers an example.) Everything seems OK, self-test circuits report all is well, and you're in blissful ignorance of the serious problem you have.
It's a problem that most sensor-laden designs can have, where apparently good sensors and their channels may report conflicting or contradictory results.
Engineers face a long list of sensor-channel issues, including internal and external noise, data corruption, ground loops, and supply-rail problems. That's why you really have to ask yourself the tough questions. How do I know this data is good? Am I making major decisions based on unverified — or unverifiable — readings? Is there a way I can independently cross-check what the system is being told? Can I provide a known change in the sensor's physical parameters and see if it provides a reasonably correct change in output signal? Besides the laws of physics, should I also worry about the law of unintended consequences here?
Have you even been in a situation where your sensors gave misleading results and thus caused major system performance problems? How did you finally figure out what was happening? What did you do to solve the problem, once you figured it out — or did you?