Start with the failure, not the sensor
It is tempting to begin a connected-monitoring project by buying sensors and seeing what the data shows. A more reliable approach is to start with a list of how the machine is likely to fail, then choose measurements that would show those failures developing.
A centrifugal pump, for example, may suffer from bearing wear, seal leakage, misalignment or cavitation. Each of those leaves different traces. Bearing wear shows up in vibration and temperature. Seal problems might appear as leakage or rising seal-area temperature. Choosing signals that match real failure modes keeps the system small and meaningful.
What to measure
Common measurements for rotating equipment include:
- Vibration, often the most informative signal for bearings, imbalance and looseness.
- Temperature, for bearings, windings, gearboxes and electrical connections.
- Motor current or power draw, which can reflect load changes, mechanical drag and some electrical faults.
- Pressure and flow, which show whether a pump or compressor is performing as expected.
- Oil condition or particle levels, where lubricated systems are involved.
- Run hours and operating state, which provide context for everything else.
That last item is easy to overlook. A vibration reading means little unless you know whether the machine was running at full load, idling or starting up. Pairing condition signals with operating context is what allows a meaningful comparison from one day to the next.
How often to sample
Different faults develop at different speeds. A slowly worsening temperature trend may need only a reading every few minutes or even less often. Vibration signals used to detect bearing defects may need to be captured in short, fast bursts, since the useful information sits in rapid fluctuations. Sampling faster than needed fills storage and network capacity for little gain, while sampling too slowly can miss the very change you are looking for.
A common compromise is to compute summary values at or near the sensor, such as an overall vibration level or a peak value, and send those frequently, while capturing full detailed waveforms less often or only when a summary value crosses a limit.
Transmitting the data
Readings travel from the machine to the people and software that use them. The route usually involves a local gateway, plant networking and then a historian, a cloud service or an on-premises server. Reliability matters more than speed in most maintenance uses. If a link drops, the gateway should store readings and send them when the connection returns, so that trends have no holes.
Wired connections, wireless sensors and existing control-system signals can all play a part. Wireless sensors are often attractive for older equipment because they avoid running cable, though battery life and signal quality in busy industrial environments need checking. Anything connected to plant networks also raises industrial cybersecurity questions, so network segmentation and access control should be considered from the start rather than added afterward.
Turning readings into action
Data only has value if it changes what people do. A workable chain looks like this:
- Establish a baseline for each machine while it is known to be healthy.
- Set alert limits, starting with simple thresholds and adjusting them as experience grows.
- Decide in advance who receives an alert and what they should check first.
- Record the finding and the repair outcome, so that future alerts can be judged against history.
Simple rules are often enough to start. A rising trend, or a reading that deviates from the machine’s own normal range, can be more useful than a fixed number copied from a general guideline. Later, industrial data analytics or statistical methods can refine these rules, but they depend on clean records.
Data quality problems to expect
Connected systems fail in ordinary ways. Sensors drift, mounting positions change after a repair, cables are damaged, clocks fall out of sync, and readings are mislabeled when equipment is replaced. A reading that suddenly jumps is sometimes a failing sensor rather than a failing machine. Good practice includes checking that sensors produce plausible values, flagging missing data explicitly, and recording when a sensor is moved or replaced. Regular calibration checks are part of the same discipline.
Keeping the scope manageable
Plants that try to connect everything at once often end up with more alerts than anyone can review. A narrower pilot, covering a handful of important assets, lets a team learn what a useful alert looks like and how much effort follows from it. The number of alerts should stay below what the maintenance team can realistically investigate. Once the process works for a few machines, it can be extended using the same pattern.
Finally, keep humans in the loop. Connected data tells you where to look; an experienced technician with a handheld instrument or a careful visual check often confirms what is happening. The aim is to point skilled people at the right machine at the right time, not to remove them from the process.