v Optimizing Reliability: Step 2 – Calculate Sensor Failure Points - Tignis

Optimizing Reliability: Step 2 – Calculate Sensor Failure Points

Author: Jon Herlocker


Optimizing reliability of existing sensors

Previously, this blog series discussed optimizing your use of existing sensors in lieu of always adding new ones to improve your asset reliability monitoring. But you’ll always have some sensors, and you’ll always need a strategy for maintaining them. A key part of this strategy is detecting when sensors fail or need recalibration, along with detecting other possible system faults. Sensors are physical equipment, and like any equipment, they have a useful lifespan, and over time need to be serviced or replaced.

Guess what? Like in step 1, you already have much of what you need to mitigate these risks. Just as physical laws can be overlaid with a digital twin to produce “virtual” sensor results as shown in the previous example, similar principles can be applied to root out the failures of individual sensors and other suspicious conditions within an existing system.

Let’s look at an example. The drawing below shows a portion of a system where water flows out of two chillers through a single junction. Attached to the junction is closed valve, and a pipe leading to the next part of the system. Four flow sensors operate at key points: one for each of the chiller locations where water flows out, one where the water continues out of the junction, and one where the junction connects to the closed valve.

For this example, you can apply physics to a digital twin schema to yield data that indicates the system is either in proper operation or out of whack somehow. Physics tells us that the combined flows out of the chillers should total what flows from the other side of the junction, and since the valve is closed, the outgoing pipe should carry that entire flow (minus minor corrections for pipe friction, and so on).

If F1 + F2 equals F3, the subsystem shown here is in correct operation. But if the monitoring system finds a significant difference between the combined flow in and the net flow out—which it can only do if it’s programmed with a digital twin and physics-based rules—it’s able to report the anomaly, indicating either a faulty flow sensor, or a leak somewhere in the system, or maybe the “closed” valve isn’t fully closed after all.

In this way, you rely on physics-based modeling and your digital twin to do the work of telling you there’s a problem, instead of relying on more error-prone methods, like human observation, or waiting for trouble to occur—or, very commonly, getting unhelpful alerts based on system rules that might be conflating or misreading sensor data. The next post in this series will focus on this concept of bogus alerts, and talk about using these same principles to sort through sensor data and look past “false positive” readings to get to root cause analysis faster when issues occur.