IoT Predictive Maintenance for Infrastructure: A Guide

Reactive, preventive, predictive

Three maintenance strategies, and most organisations run all three simultaneously without having decided which asset belongs in which category.

• —Reactive: fix it when it breaks. Cheapest per intervention, most expensive per failure. Appropriate for low-criticality assets where failure is an inconvenience rather than an event.
• —Preventive: service on a fixed schedule. Predictable and easy to plan, but it replaces components that had remaining life and still misses failures that arrive early. Most industrial maintenance defaults here.
• —Predictive: service when observed condition indicates it is warranted. Requires continuous measurement of something that correlates with degradation. Highest data requirement, lowest total intervention cost when it works.

The honest framing is that predictive maintenance is not universally superior — it is superior for assets where failure is expensive and degradation is measurable. Applying it to a cheap, redundant component is over-engineering. The first useful exercise is not sensor selection; it is deciding which assets actually justify the investment.

What to measure

Degradation announces itself physically before it announces itself as failure. Which signal leads depends on the failure mode.

Vibration

The workhorse for rotating equipment — pumps, motors, fans, gearboxes. Bearing wear, imbalance, misalignment, and looseness each produce characteristic frequency signatures, often well before any audible or thermal symptom. If you monitor one thing on rotating machinery, monitor this.

Temperature

Broad and cheap. Rising temperature indicates friction, electrical resistance, restricted flow, or cooling failure. Thermal sensing is easy to deploy and interpretable without specialist analysis, which makes it a sensible starting point for teams new to condition monitoring.

Current and power draw

Electrical signature analysis catches mechanical problems indirectly — a motor working harder against a failing bearing or a blocked impeller draws more current. Often deployable at the panel without touching the asset itself, which matters where access is difficult.

Structural strain and tilt

For bridges, towers, retaining structures, and buildings. Slow-moving signals where the value lies in long-baseline trend rather than instantaneous reading, which places specific demands on data retention.

Environmental context

Humidity, ambient temperature, and pressure rarely predict failure alone, but they are what stop you misreading the primary signals. A temperature rise during a heatwave is not the same event as the identical rise on a mild night.

The data architecture problem

This is where most implementations quietly fail, and the failure is architectural rather than analytical.

Current value is not enough

Many monitoring deployments store only the latest reading, overwriting history. That supports threshold alarms and nothing else. Prediction requires trend, and trend requires history at meaningful resolution. A system that cannot tell you what a bearing was doing eight weeks ago cannot tell you it is degrading — only that it has already crossed a line.

Why time-series storage

Sensor telemetry is append-heavy, time-ordered, and queried in windows. Relational databases handle this poorly at high frequency: index maintenance on every insert becomes the bottleneck. Time-series databases such as InfluxDB are built for exactly this shape — rapid ordered writes, efficient time-window queries, and retention policies that downsample old data rather than discarding it.

The practical pattern is to split by data type: high-frequency readings into a time-series store, asset and organisational metadata into a document store where relational-style lookups belong. Trying to serve both from one engine is a common early mistake.

Transport

MQTT dominates sensor telemetry for good reasons: a lightweight publish/subscribe protocol designed for constrained devices and unreliable networks, with quality-of-service levels that survive intermittent connectivity. Polling sensors over HTTP at high frequency is an anti-pattern — it wastes power on battery devices and scales badly. For delivery to browsers, WebSocket push replaces polling for the same reason.

Why spatial context changes the outcome

A conventional alert says: sensor 4471 exceeded vibration threshold. Someone now has to work out what asset that is, where it sits, what it feeds, and whether anything else nearby is also drifting. That lookup is friction, and friction at 2am produces slow or wrong responses.

When telemetry is bound to positions inside a 3D twin, the alert arrives as location and context: this pump, on this level, in this plant room, with these two neighbouring units also trending upward and this access route to reach it. Diagnosis starts from context rather than from a device identifier.

Spatial context also exposes correlations that tabular monitoring hides. Three unrelated assets degrading simultaneously reads as coincidence in a list. Seen in space, sharing a wall with a newly commissioned compressor, it reads as a cause.

A sane implementation sequence

The programmes that survive tend to follow roughly this order.

• —Rank assets by consequence of failure. Cost of downtime, safety exposure, replacement lead time. Instrument the top of that list, not the easiest-to-reach equipment.
• —Identify the failure mode you are actually trying to catch, then pick the sensor that leads it. Instrumenting first and looking for patterns afterwards is how deployments generate data nobody uses.
• —Establish baseline. Anomaly detection requires knowing what normal looks like across a full operating cycle, including seasonal variation. This takes time and cannot be skipped.
• —Start with generous thresholds and tighten them. Alert fatigue kills credibility faster than missed alerts, and a system people have learned to ignore is worse than no system.
• —Connect alerts to the work order process. An alert that does not create an actionable task is an observation, and observations do not prevent failures.
• —Review outcomes and feed them back. Every prediction that proved right or wrong is calibration data. Programmes that never close this loop stagnate at their initial accuracy.

Security considerations

Connecting operational equipment to a network expands the attack surface, and industrial deployments have historically been careless here. Minimum expectations:

• —TLS on every sensor connection. Unencrypted MQTT on a shared network is readable and, worse, writable by anything else on that network.
• —Per-device credentials, not a shared secret. A single compromised device should not grant access to the whole fleet, and revocation should not require re-provisioning everything.
• —Role-based access with tenant scoping enforced server-side. Access decisions made in the client are not access controls.
• —Segmentation between operational and corporate networks, so sensor telemetry paths cannot become a route into control systems.

Katana IoTwin authenticates sensor, drone, and user traffic through Firebase Auth with role-based access control over TLS, stores high-frequency telemetry in InfluxDB with asset metadata in Firestore, and binds every sensor to its position in the 3D twin — so an anomaly arrives as a location rather than a device ID.