Predictive maintenance systems look alike in a demo and differ in the field, and seven criteria expose the difference: how the system actually measures, whether it catches transient events, whether it sees current and energy next to vibration, how deep the AI’s diagnosis goes, what happens to a finding, how the platform connects to your other systems, and whether the vendor makes your team stronger. This guide gives you the seven questions and the reasons behind them, so you can score any vendor against them.
One thing first, in the open: we build one of these systems. We name no competitors here, and every criterion is phrased as a question you can put to anyone, including us. Where we explain how our own platform answers it, we say so explicitly.
1. Measurement architecture: snapshots, or the moments that matter
Most wireless vibration sensors run on batteries, and the battery dictates the behaviour: to survive for years, the sensor wakes up at intervals, takes a short measurement and goes back to sleep. Everything between two snapshots is invisible. A fault that develops between them waits for the next wake-up; a machine that alarms during the night gives you a reading from hours earlier; and someone owns a calendar of battery replacements across the plant.
The alternative is a line-powered wireless sensor. Our Wired Pro takes its power from a simple energy cable, streams over Wi-Fi, and because it never has to protect a battery, it analyses continuously in real time. Instead of transmitting everything blindly, it selects the moments worth keeping and sends the full spectrum and time waveform of those: its smart measurement strategy triggers on a change in RMS rather than on a fixed period.
| Battery-powered wireless | Line-powered wireless | |
|---|---|---|
| Power | Battery, replaced on a schedule | A simple energy cable |
| Measurement rhythm | Periodic snapshots | Continuous, real time |
| Transients (start-up, load change) | Only by luck | Captured, with spectrum and waveform |
| Ongoing burden | Battery calendar across the plant | None beyond the cable |
| Where it fits | Hard-to-reach, lower-criticality assets | Critical machines that earn continuous attention |
The honest conclusion is not that one architecture wins everywhere: it is that criticality decides, and a portfolio should offer both. Ours does; the same platform runs our battery-powered Infinity sensors where reachability rules, and Wired Pro where continuity pays.
Ask any vendor: what does your system see between two measurements, and what happens when the fault develops during a start-up?
2. One discipline is not enough: vibration, current and energy together
Vibration is the strongest single window onto rotating machinery, and it is still only one window. Electrical faults show most clearly in the motor’s current signature, which is why motor current signature analysis (MCSA) exists as a discipline. A platform that measures only vibration reads half the machine.
Our Duck measures current in real time at the same machine where the vibration sensors sit, and the platform reads both signals together: current becomes the second window onto the motor, confirming what vibration suspects and catching what vibration cannot see. That cross-check is what turns an anomaly into a root cause you can defend.
The same current measurement carries a second gift: energy. The platform tracks each machine’s consumption and matches faults with what they cost. A machine running with unbalance does not just wear its bearings; it burns extra energy every hour it keeps running. When maintenance can tell production what the fault costs per running hour, the negotiation over a stoppage changes character: the downtime request stops being a nuisance and becomes a business case.
Ask any vendor: can your system show me the same fault in two independent signals, and can it tell me what the fault costs in energy while I wait?
3. AI depth: an alarm is not a diagnosis
Every system on the market raises alarms. The question that separates them is who works the case after the alarm.
Our answer has two layers. The Reliability Agent works a case the way an experienced engineer would: it checks structure before blaming mechanics, compares against a month ago, and comes back with the evidence and an action to approve. And AHA, the automatic health assessment, is the one-button version: it runs the root cause analysis using the machine’s own context, including thousands of pages of equipment documentation, photographs and the accumulated knowledge base, and returns its assessment in minutes. Its reports say what changed rather than restating what was already known.
Depth shows in the output. A score you must trust is shallow, whatever the marketing says; a named fault with the spectrum evidence behind it, typically two to four months before the failure, is something your team can check, challenge and act on. The decision stays with people: the Agent proposes, a person approves.
Ask any vendor: show me a real report. Does it name the fault and show the evidence, or does it show me a number and ask for faith?
4. After the finding: work orders, parts, history
A diagnosis that dies in a dashboard changes nothing in the plant. The test of a platform is what happens next, without leaving it.
In our platform the path is built in. An alarm can open a work order by itself through the workflow builder, with the machine, the trigger value and the threshold already filled in. The Reliability Agent proposes work orders and a person approves them. Preventive schedules define when work is due and create the order when run. Behind the work orders sit an asset register, a parts catalogue with 23 categories and 14 kinds of stock movement, so the repair, the part it consumed and the machine’s history stay one record.
Ask any vendor: when your AI finds a fault, how many systems and how many people does it take before someone in the field holds a work order?
5. Integration: your data must not be a hostage
However good the platform, it is one system among many in the plant. What matters is whether it behaves like it: outbound webhooks on ten kinds of event, an inbound API scoped per area of the platform, and MCP so your own AI assistants can read trends, spectra and stock directly, and create a work order after a human approves it. Findings flow out to your ERP; each integration records when it last succeeded, when it last failed and what the error said.
Ask any vendor: can my ERP hear about a work order without a person copying it, and can my own AI assistant query the data?
6. The vendor should make your team stronger, not more dependent
A monitoring program lives or dies on whether the maintenance team trusts and understands the findings. That is a training problem, and a vendor’s attitude to it tells you how the relationship will age.
We put the material in the open: study books and practice exams across vibration, thermography, oil analysis, ultrasound, alignment and balancing, and 24 calculators that need no sign-up and print the formula they use. None of it is gated behind a purchase, because a team that understands the physics challenges the diagnosis, and a diagnosis that survives challenge is the one that gets acted on.
Ask any vendor: what will my team know after a year with you that it did not know before?
7. Proof: ask for cases with numbers
Marketing claims are free; case studies with numbers are not. Ask for real machines, real faults and real outcomes. From our own case studies: a press machine’s bearing failure was reported three months before it would have become a malfunction, and the opened bearing showed the abrasion exactly where the analysis pointed; a sugar mill’s unbalance and developing bearing failure were both confirmed in the metal at planned maintenance; a reciprocating compressor’s loosened mounting was caught from the spectrum before the compressor ever stopped.
Then hold every vendor, including us, to the same standard.
The seven questions, together
- What does the system see between two measurements, and does it catch transients?
- Does it read current and energy next to vibration, on the same platform?
- Does the AI name the fault with evidence, or produce a score to trust?
- Does a finding become a work order without leaving the platform?
- Can the ERP and your own AI assistants reach the data through webhooks, API and MCP?
- Will the vendor teach your team, or keep it dependent?
- Are there case studies with real machines and real numbers?
A system that answers all seven well is rare. That is precisely why the questions are worth asking.
Frequently asked questions
Are battery-powered or line-powered wireless vibration sensors better?
Neither is better everywhere; asset criticality decides. A battery-powered wireless sensor is right for hard-to-reach or lower-criticality machines, and it measures in periodic snapshots to protect its battery. A line-powered wireless sensor draws power from a simple energy cable, streams over Wi-Fi, analyses continuously and can capture transient events such as start-ups and load changes that periodic snapshots miss. On critical machines, continuous line-powered measurement sees what snapshots cannot.
Can vibration analysis alone catch every machine fault?
No. Vibration is the strongest single discipline for rotating machinery, but electrical faults such as rotor bar damage or supply problems show most clearly in the motor's current signature. A system that measures real-time current next to vibration reads the same machine through two independent windows, which both confirms diagnoses and catches fault types that either discipline alone would miss.
What does an integrated predictive maintenance platform actually mean?
It means one flow from measurement to action: sensors collect the data, the AI diagnoses the fault, the finding becomes a work order in the built-in maintenance module, and the result leaves the platform through webhooks or an API into your ERP. When these are four separate products, every join between them is manual work and a place where information dies.
How is AI root cause analysis different from alarm thresholds?
A threshold alarm tells you a value crossed a line; it does not tell you why. AI root cause analysis works the case: it reads the spectrum and the waveform, compares against the machine's own history, weighs the equipment's documentation and returns a named fault with the evidence behind it and an action to approve. The difference in practice is between 'vibration is high' and 'outer race damage on the drive-end bearing, plan a replacement'.
Do we need a certified vibration analyst before starting predictive maintenance?
No. A modern platform carries the analysis load: severity assessments, fault scores and root cause proposals are produced automatically, and your team's job is to bring machine knowledge and judge the proposed actions. Where customer contracts or audits require certified personnel, that requirement stands on its own; learning the fundamentals always helps, but it is no longer the entry ticket.
