We are asked fairly often to review a condition monitoring proposal that an asset owner has received from a vendor, and sometimes to review one of our own. The questions that decide whether the programme will still be running in two years are rarely about the sensor. They are about what happens around it. Here are the six we put to any proposal, including ours.
1. How long is the baseline, and who has agreed not to shorten it?
Every alert worth having is a deviation from that asset’s own normal. Normal has to be measured, across the operating conditions the asset actually sees: duty and standby, summer and winter, loaded and empty. On rail that means weeks of traffic across the timetable; on a pump it means the full range of duty points. The baseline period is the first thing squeezed when a programme runs late, and shortening it is the most reliable way to produce a year of false alarms. Ask for the baseline period in writing and ask who has the authority to protect it.
2. Where does the alert land?
An alert that stays inside the monitoring vendor’s portal changes nothing. Maintenance behaviour changes when the alert becomes a notification, a work order, or at least a line in the system the planner already opens every morning. Ask which system the alert lands in, who receives it, and what the work order looks like when it does. If the answer is “log in to the dashboard”, the programme depends on someone remembering to.
3. Who owns the thresholds after commissioning?
Thresholds are tuned during commissioning against real conditions and then drift out of date as the asset ages, duty changes, or a neighbouring machine is installed. Someone has to own them. If that person is the vendor, the contract needs to say so and price it. If it is your engineer, they need to be able to change a threshold without raising a ticket. Either is workable; an unanswered question is not.
4. What happens when the link drops?
Sites without reliable connectivity are the norm, not the exception. The question is whether a dropped link costs you latency or data. Local buffering, resumable uploads and a visible queue on the dashboard are the difference between “the site was offline for a day” and “we have no data for Tuesday”. Ask to see the queue, not just to be told about it.
5. Where is the data, and who can see it?
For government and regulated-industry clients in the Gulf this is usually a hard requirement rather than a preference: data hosted in-country, on infrastructure the client’s IT team can be walked through, with role-based access that separates the operator who acknowledges an alert from the engineer who changes a threshold. Ask for the architecture diagram before the pilot, not after.
6. What does the engineer see when they click the alert?
A traffic light is not evidence. The engineer deciding whether to raise a work order needs the waveform, the spectrum, which band moved, by how much against the baseline, and for how many captures in a row. If the proposal cannot show you that screen for a real event, it cannot show your maintenance team either. The monitoring programmes that last are the ones where the engineer trusts the alert because they can see why it fired.
The common thread
None of these questions is about sampling rate, sensor axes or wireless standards. Those matter, and most current hardware clears the bar. The programmes that fail do so at the seams: between commissioning and steady state, between the portal and the CMMS, between the vendor and the engineer who inherits the thresholds. Ask about the seams.
Images: JX Nippon Oil Negishi Refinery - panoramio by FoxyStranger Kawasaki, CC BY-SA 3.0, via Wikimedia Commons; Oil pipelines, jubail desert, Saudi Arabia - panoramio by Suresh Babunair, CC BY 3.0, via Wikimedia Commons.
