The Cheapest Sensor Is the One Already Installed

Every asset monitoring conversation reaches the same fork. One path costs a capital budget, a procurement cycle and eighteen months. The other starts on Monday.

The expensive path is the default because it is the one vendors propose: instrument everything, then build analytics on top. It is not wrong, exactly. It is just an odd place to start when most industrial estates are already producing far more telemetry than anyone reads.

Start with what is already reporting

Pumps, meters, controllers, SCADA historians, building management systems — these have been logging for years. The data is usually in one of three states: retained but never queried, retained at a resolution too coarse to be useful, or discarded after a rolling window because nobody articulated a reason to keep it.

Before specifying a single new sensor, the question worth answering is what the existing instrumentation would tell you if somebody looked. That answer costs an integration rather than a capital programme, and it does two useful things: it produces value in weeks, and it tells you where the genuine blind spots are — which is a much better basis for a hardware order than a vendor's coverage map.

We have taken this route on both underground network monitoring and field operations, and the pattern holds: the first real finding almost always comes out of data the client already had.

Access cost is the whole economics

In field and buried infrastructure, the cost that dominates is not the sensor. It is getting a person to the asset.

That single fact should drive the entire design. It means:

• A sensor that needs its battery changed is not a sensor, it is a scheduled site visit with a component attached. Energy harvesting is not a refinement here; on a buried run it decides whether the deployment is viable.
• Diagnosis has to happen before dispatch. Knowing there is a fault somewhere on a run is barely better than knowing nothing. Knowing which section, and being navigated to it, is what removes the exploratory excavation.
• A false positive costs a real journey. Alert thresholds that would be merely annoying in a software system have a per-incident cost in a physical one, and teams learn to ignore a channel that cries wolf.

Predict the failure, not the reading

Threshold alerting tells you something has already gone wrong. That is worth having and it is not what the technology is for.

The interesting layer is trajectory: a pressure reading drifting within its acceptable band, a flow profile changing shape, a pump drawing marginally more current each week. None of those trip a threshold. All of them precede a failure, and all of them are visible in data most operators already hold.

This is also where the honest limits sit. Predictive maintenance works where there is enough failure history to learn from, and on assets that fail rarely there simply is not. Where that is the case, saying so is better than shipping a model that produces confident nonsense about equipment nobody has ever seen break.

Fit the operator, not the org chart

The most reliable way to waste this investment is to build the dashboard for the person who signed for it.

The operations manager wants trends and an estate view. The technician wants to be told where to go and what to bring. If the technician's interface is a filtered version of the manager's, it will be used once. Their job is not to browse an estate; it is to fix a specific thing, ideally without a second trip.

Which is why the useful test for any field-facing monitoring system is not how much it displays. It is whether the person who drives to the site arrives knowing what they will find and carrying the right part.

---

iLeaf's energy and asset monitoring practice began with oil and gas and now covers pipelines and utility networks — including ARMO, which is in the case studies.