Vibration and Condition Monitoring Software: Why a Developing Bearing Fault Depends on Who Looked This Week

Why condition monitoring data goes stale in three places at once

A reliability manager at a paper mill has nine hundred machines on route. Two analysts collect them with handheld units on a monthly cycle. The big turbomachinery is wired into a protection rack and its data lives somewhere else entirely. Oil samples go to an external lab and come back as PDFs in an inbox. Thermography images sit in a folder on a shared drive named by date. Every one of those four streams is telling the truth about the same gearbox. None of them is talking to the others.

The failure that gets everyone's attention later looks like this in hindsight. Wear metals climbed in the oil report six weeks out. The route data showed a bearing tone appearing at a defect frequency four weeks out, but it was inside the alarm band so nothing triggered. A thermography survey caught a warm bearing housing three weeks out and the image was filed. The machine seized on a Sunday. Nothing was hidden. The evidence was sitting in three systems and one folder, and no human had reason to open all four on the same day for the same asset.

What that costs is not subtle. Unplanned failure of a critical mill motor or a main compressor is priced in production per hour, which is why condition monitoring gets funded at all. In our work with plants and mines the recurring pattern is not a lack of data, it is that an analyst spends the majority of a week collecting and only a fraction of it analysing, and that the analysis reaches a planner as a comment rather than as a scoped job. The programme then gets judged on whether it caught the last big one, which is a coin flip when the review is manual.

Problem 1: every platform is married to its own hardware

This deserves a fair statement, because the incumbents here are good at what they do. Emerson AMS Machine Works is strong and it is built around CSI analysers. SKF @ptitude Observer is a mature database and it assumes SKF collection hardware. Baker Hughes Bently Nevada System 1 is the right answer for continuously monitored turbomachinery on 3500 style protection racks and it is not trying to be a route database for nine hundred pumps. Augury has a genuinely capable model and it runs on Augury sensors on the asset types Augury has trained.

The problem is not that any one of them is weak. It is that a real plant has two or three of them plus a lab. Spectra export in incompatible formats, sometimes as a proprietary binary, sometimes as a flat file with a header that changes between firmware versions. Machine identity does not match across systems, because the route database calls it MILL-DRIVE-2-NDE and the protection rack calls it point 4B on rack 12 and the CMMS calls it a functional location with a code your maintenance team invented. Nobody sells the joining layer, because each vendor's commercial interest is that you standardise on them, and you are not going to rip out a working protection system to do that.

What a custom build does first, before any analytics: one asset and machine train model that every source maps into. Driver, coupling, gearbox, driven equipment, each with bearings identified by part number so defect frequencies are computed rather than guessed. Measurement points carry a stable identity with a mapping table per source system. This sounds like plumbing because it is plumbing, and it is the reason every analytics project that skipped it produced a dashboard nobody trusted.

Problem 2: alarm limits are generic, and generic is why nobody trusts the alarms

ISO 20816 gives evaluation zones for broadband vibration by machine class and support type. It is a useful starting point and it is not an answer for your machine. A pump on a stiff concrete plinth and the same pump on a skid have different acceptable levels. A variable speed drive breaks fixed frequency bands entirely, because the bearing defect tone moves with shaft speed and a static band either misses it or screams constantly.

The result at most plants is alarm fatigue. Analysts turn limits up until the noise stops, and then the system is decorative. Or they leave them at vendor defaults and triage a hundred alerts a week by eye, which is the same as having no alarms with extra steps.

What a custom build does: order normalised bands, meaning bands defined as multiples of running speed rather than fixed hertz, with speed taken from a tachometer channel or from the drive over the historian. Statistical limits derived from each machine's own baseline period rather than from a class table, with a documented override where an engineer has a reason. Rate of change alarms, because a bearing that doubles its defect amplitude in two weeks matters more than one that has sat slightly raised for three years. And band definitions per bearing part number so a new bearing type does not require a manual recalculation.

Problem 3: the route is a calendar, not a risk decision

Nine hundred machines get collected monthly because that is what the route says. The criticality of those machines varies by orders of magnitude. Some of them should be online continuously and some of them are worth collecting twice a year. The route exists in its current shape because someone built it once and nobody has had a defensible basis to change it.

What a custom build does: interval by consequence and by condition. A machine with a rising trend moves to a shorter interval automatically and drops back when it settles. Machines with a criticality that justifies it get flagged for permanent sensor installation with the business case attached. Collection effort follows risk instead of following the map of the plant, which in our experience is what frees analyst hours without cutting coverage where it counts.

Problem 4: the diagnosis dies between the analyst and the planner

An analyst writes: high 1x with harmonics, suspect misalignment, recommend laser alignment check at next opportunity. That reaches the planner as a notification with the text pasted in. The planner raises a job called check vibration. A fitter goes out, finds nothing obviously wrong, closes it. Three months later the coupling fails. Nobody was negligent. The diagnosis lost all of its specificity in transit.

What a custom build does: the recommendation becomes a structured object, not prose. Fault type, confidence, affected component, recommended task with an actual scope, required tooling, and a due date derived from severity. That maps into a maintenance notification with the correct catalogue codes so it can be reported on later, and the job plan attached to it is the one the analyst intended. The analyst also gets told when the job is scheduled and when it is executed, which is the loop that today does not exist.

Problem 5: nobody checks whether the diagnosis was right

This is the quiet failure of most condition monitoring programmes. When the machine comes apart, the findings go into a repair report that lives with the workshop. It never returns to the analyst who called it. So the programme cannot answer the two questions a plant manager will eventually ask: how many of your calls were correct, and how many failures did you miss.

What a custom build does: force closure. Every diagnosis has an outcome field that gets completed when the work is done, with the actual finding, photographs, and the failure mode confirmed or corrected. That gives you a hit rate you can defend at budget time, and it gives you the labelled dataset that any machine learning worth having requires. This is the honest position on AI in condition monitoring: anomaly detection without labels produces a lot of alerts and no diagnosis, and the useful models are the ones trained on your own confirmed outcomes. Start collecting labels the day the system goes live and the model becomes worth building in year two.

What this costs and how long it takes

A first release with the unified machine train model, ingest from two or three sources, the alarm engine, a triage queue and CMMS notification creation runs $60,000 to $130,000 in 12 to 16 weeks. That is a working system for one plant, not a proof of concept. Adding raw waveform and spectrum storage with in-browser analysis, order tracking for variable speed assets, oil analysis and thermography ingest, criticality driven route scheduling, mobile collection support, closure reporting and ML triage runs $150,000 to $400,000 over 6 to 12 months.

Cost drivers specific to this category: raw waveform volume, because storing time waveforms for nine hundred points monthly is a real storage and query design problem rather than a rounding error, and clients who want three years of history need that decided up front. Proprietary export formats, because reverse engineering one vendor's binary is a contained piece of work and doing it for three is not. Historian integration, particularly if speed and load context has to come from a control system through an OPC layer with its own security review. Hazardous area constraints if you want new wireless sensors, which is an electrical engineering project sitting next to a software one. What keeps cost down: start with one plant, the top hundred machines by consequence, and two data sources.

Build versus buy, honestly

Buy if you are single vendor end to end with under about two hundred monitored machines. Emerson or SKF will serve you well and a custom build would be an expensive way to reproduce features you already have. Buy also if your problem is that you have no data at all: install sensors and a vendor platform first, run it for a year, then decide. Software does not create measurements.

Build when two or more of these are true. You have analyser hardware from more than one vendor and no single view. Your machine identity does not match across CM, historian and CMMS, so nothing can be reported together. Your alarms are either ignored or turned off. Your diagnoses reach planners as free text and lose their scope. Or you cannot state your programme's hit rate, which means you cannot defend its budget.

How to choose a developer for condition monitoring software

Ask them what an order is, and whether their alarm bands move with shaft speed. If the phrase 1x and its harmonics is unfamiliar and they talk about generic anomaly detection instead, they will build you a dashboard and you will turn it off within a year.

Ask how they will store waveforms. You want to hear a specific plan for time series storage, downsampling for trend views, and retention policy, with numbers attached to your point count and collection interval. A team that has not thought about this discovers it when queries start taking forty seconds.

Ask which vendor exports they have actually parsed, by product and version, and what happens when a firmware update changes the header. Ask the same about your CMMS: which notification type, which catalogue profile, which codes.

Ask who owns the code, the repository and the infrastructure accounts, and get it in writing before kickoff. At Digital Heroes the client owns all of it from the first commit and is free to hire anyone else to continue. The whole point of building rather than buying here is escaping vendor lock, so accepting a new lock from your developer would defeat the exercise.