Vibration and Condition Monitoring Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does a condition monitoring build keep expanding past the dashboard?

The request is usually modest: one screen showing all our machines. Two weeks in it becomes clear that the screen needs a machine identity that every source agrees on, and the route database calls a machine one thing, the protection rack calls it a point on a rack, and the maintenance system calls it a functional location with a code your team invented. So the asset model comes in scope. Then alarms, because a screen without thresholds is wallpaper. Then bearing part numbers, because defect frequencies have to be computed rather than guessed. Then the maintenance system, because an alarm nobody can act on is noise.

This is not scope creep, it is the actual shape of the problem. The analytics everyone wants sit on top of plumbing nobody wants to pay for, and skipping the plumbing is why so many condition monitoring dashboards get switched off within a year.

Scope by plant and by consequence. One plant, the top hundred machines by failure consequence, two data sources, one alarm engine and notifications raised into the maintenance system. That is a working system rather than a proof of concept, and it makes the case for the rest. Put waveform storage, order tracking for variable speed assets, oil and thermography ingest and any machine learning on a written exclusion list for release one.

What goes wrong with machine identity and historic measurement data?

Identity is the harder half and it is almost always underestimated. Your route database, your protection rack, your historian and your maintenance system each name the same machine differently, and the naming was done by different people in different decades. Matching them is manual work that requires a reliability engineer who knows the plant, not a script, and it takes longer than the parsing work everyone budgets for.

Historic measurement data brings its own problems. Sensor mounting locations moved and the point kept its name, so a trend spans two physically different measurements. Machines were rebuilt with different bearings and the defect frequencies changed, invalidating any band defined before the rebuild. Analysers were replaced and the new one applies different filtering, so amplitudes shift for reasons unrelated to machine health. Speed context is frequently missing entirely, which makes older data uninterpretable on a variable speed asset.

What works: build the asset and machine train model first, with driver, coupling, gearbox and driven equipment, and bearings identified by part number so defect frequencies are computed. Give each measurement point a stable identity with a mapping table per source system. Then mark every historic discontinuity you can find, meaning rebuilds, sensor moves and analyser changes, so a trend line does not silently combine two different things. In our delivery experience the identity mapping consumes more calendar time than the ingestion code, and projects that assume the reverse slip in month two.

Why do the vendor exports and historian feeds break after launch?

Vendor exports break at firmware boundaries. A flat file whose header changed between analyser firmware versions will parse into the wrong columns without raising an error, which is worse than failing. Proprietary binary formats are a contained piece of work for one vendor and a considerably larger one for three, and each remains a maintenance obligation as the vendor updates their product.

Historian feeds break on context rather than on values. Speed and load are the context that makes a vibration reading meaningful, and they arrive through a control system layer with its own security review, its own change control and its own availability. When the historian is unavailable for a morning, readings collected in that window have no speed context, and an order normalised band cannot be evaluated against them.

Laboratory results are the third channel, arriving as documents rather than as data, with sample identifiers that may or may not match your asset naming.

The controls that hold this together are boring and effective. Validate every ingested file against an expected shape, with a hard stop when the header or column count changes rather than a best effort parse. Alert when an expected export has not arrived. Store the speed context alongside every measurement rather than looking it up later. And start the historian access conversation before the project starts, because it runs on somebody else's change control, not yours.

What happens when alarm limits and diagnosis closure are not covered?

These are the two gaps that decide whether the system is used or ignored. Generic alarm limits produce alarm fatigue, and alarm fatigue is terminal. ISO 20816 gives evaluation zones for broadband vibration by machine class and support type, which is a useful starting point and is not an answer for your machine on your foundation. A pump on a stiff concrete plinth and the same pump on a skid behave differently. A variable speed drive breaks fixed frequency bands entirely, because the defect tone moves with shaft speed and a static band either misses it or screams constantly. Analysts then turn limits up until the noise stops, and the system becomes decorative.

What covers it: bands defined as multiples of running speed rather than fixed frequency, with speed taken from a tachometer channel or from the drive. Statistical limits derived from each machine's own baseline rather than from a class table, with documented engineering overrides. Rate of change alarms, because a defect amplitude that doubles in a fortnight matters more than one sitting slightly raised for three years.

Closure is the second gap and it is the one that ends programmes at budget time. When a machine comes apart, the findings go into a repair report that lives with the workshop and never returns to the analyst who called it. So the programme cannot answer the two questions a plant manager will eventually ask: how many calls were correct, and how many failures were missed. Force closure on every diagnosis with the actual finding, photographs and the failure mode confirmed or corrected, and you get both a defensible hit rate and the labelled data set any useful machine learning requires.

Should you build custom or configure what you already own?

Configure if you are single vendor end to end with under roughly 200 monitored machines. Emerson AMS Machine Works is strong and built around its own analysers, SKF @ptitude Observer is a mature database that assumes SKF collection hardware, and both will serve you well at that scale. A custom build would be an expensive way to reproduce features you already have, and we would tell you so.

Do not replace Bently Nevada System 1 for continuously monitored turbomachinery on protection racks. That is the right tool for that job and it is not trying to be a route database for nine hundred pumps. Augury has a genuinely capable model on the asset types it has been trained for, and if that matches your fleet it is worth evaluating properly.

Also do not build if your real problem is that you have no data. Install sensors and a vendor platform, run it for a year, then decide. Software does not create measurements.

Build when you have analyser hardware from more than one vendor and no single view, when machine identity does not match across monitoring, historian and maintenance systems so nothing can be reported together, when alarms are ignored or switched off, or when you cannot state your programme's hit rate and therefore cannot defend its budget.

How do hidden costs get into the quote?

Four items. The first is raw waveform volume. Storing time waveforms for nine hundred points monthly with three years of retention is a real storage and query design problem, and the retention decision has to be made before the design rather than after. A quote that does not ask your point count and collection interval has not priced this.

The second is proprietary export formats. Reverse engineering one vendor's binary is contained work. Doing it for three is not, and each one carries an ongoing obligation when firmware changes.

The third is historian integration, particularly where speed and load context comes through a control system layer with a security review attached. That is elapsed time on somebody else's calendar and it should be a named line rather than an assumption.

The fourth is hazardous area constraints if you want new wireless sensors, which is an electrical engineering project sitting alongside the software one, with its own certification and its own contractor. Ask for all four separately before comparing proposals.

What separates a build that works from one that fails here?

Four questions, and the first one is decisive. Ask what an order is, and whether their alarm bands move with shaft speed. If the phrase one times running speed and its harmonics is unfamiliar and they pivot to generic anomaly detection, they will build you a dashboard and your analysts will turn it off inside a year.

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

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 maintenance system: which notification type, which catalogue profile, which codes. Generic integration experience does not transfer to a plant.

Then settle ownership in writing before kickoff: repository, cloud accounts, data export and the right to hire another firm. At Digital Heroes the client owns all of it from the first commit. 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 entirely.