The chain from machine to repair
Connected maintenance can sound abstract. It helps to follow a single reading on its journey. Suppose a sensor on a fan bearing measures vibration. Between that measurement and a repair, the reading passes through several stages, and a weakness at any stage can break the whole chain.
Stage 1: Sensing
The first link is the device on the machine: a vibration sensor, temperature probe, current sensor or a signal already inside the machine’s controller. These sensors in the field, sometimes grouped as IIoT sensors, convert physical conditions into electrical signals. Many include small processors that calculate summaries, such as an average level, before sending anything onward.
Quality here is critical. A poorly mounted vibration sensor or a drifting temperature probe produces misleading data that no later stage can repair.
Stage 2: Collection at the edge
Readings reach a gateway or local controller, often near the equipment. This device gathers signals from several sensors, time-stamps them, and may do early filtering. It can also keep a short buffer so data is not lost if the connection fails. Processing at this point, often called edge processing, reduces how much must be sent and allows a quick local alarm if something is clearly wrong.
Stage 3: Transport
Data moves across the plant’s network. This may involve wired Ethernet, wireless links or fieldbus connections, and the principles of industrial networking apply: reliability, sensible segmentation between office and control networks, and planned capacity. Maintenance data is usually less time-critical than control signals, so it should be arranged so that it never interferes with machine control.
Security is part of transport. Every connected device is a possible entry point, so access control, updates and separation of networks are normal expectations. Treat these as design requirements, not afterthoughts, and involve whoever is responsible for the plant’s network.
Stage 4: Storage and context
Readings land in a database or historian, where they are stored with time stamps and identified by the machine they belong to. Context transforms raw numbers into usable information. Each stream should be tied to a specific asset in the asset list, with details such as speed, location and sensor position. Operating state matters too: a high reading during start-up is normal, while the same reading at steady load may not be. Mislabeled or unlabeled data is among the most common reasons projects stall.
Existing supervisory systems, including SCADA systems, often already hold much of the process data and can be a convenient source to combine with new maintenance sensors.
Stage 5: Analysis and alert rules
Now the data is turned into judgments. At the simple end, this means comparing a reading with a limit or with the machine’s own baseline, or checking whether a trend is rising. At the more advanced end, statistical techniques or learned models look at many signals together. Whichever is used, the output should be an alert that is specific and understandable: which machine, what changed, how long it has been changing, and how confident the system is.
Good alert design limits how many messages reach people. A sensible approach includes sorting alerts into levels, such as “watch” and “act”, suppressing repeats, and ignoring known conditions like planned shutdowns.
Stage 6: Alert to work order
This stage decides whether the investment pays off. When an alert arrives, a named person reviews it. They may check the trend, ask an operator to look at the machine, or take a handheld reading to confirm. If the issue looks real, a work order is created, ideally with the evidence attached, covering what was observed, what is suspected, and the suggested inspection or repair.
Some systems create work orders automatically from alerts. Automation can save time, but it also risks flooding the system with low-value tasks, so many plants prefer a human check before a job is raised. Maintenance software can then schedule the job, reserve parts and record the outcome. Clear writing matters here too, because vague notes make later analysis harder.
Stage 7: Close the loop
After the repair, the technician records what was found: worn bearing, loose mounting, a false alarm. That outcome should flow back to whoever tunes the alert rules. If alerts frequently prove false, limits can be adjusted. If a failure happened without a warning, the team can ask what signal might have caught it. Without this feedback, the system never improves.
Where the chain commonly breaks
- A sensor fails or loses its battery and nobody notices that data has stopped.
- A gateway or network link goes down for a long period.
- Data arrives but is attached to the wrong machine.
- Alerts are sent to a shared inbox no one watches.
- Alerts are numerous and low in value, so people ignore them.
- A work order is created but never scheduled.
- Repair findings are never recorded.
Monitoring the monitoring system itself, with a simple check that every sensor has reported recently, prevents many silent failures.
Keeping it proportionate
A short chain on a few important machines, with clear owners at each stage, is more valuable than a sprawling system nobody maintains. Equipment work prompted by alerts should follow the manufacturer’s manuals, lockout and tagout style procedures and local rules, and be carried out by trained, authorized personnel.