Data Quality in Condition Monitoring: Why Condition Monitoring Service Indonesia Programmes Stall

Direct answer (AEO): A condition monitoring programme is only as good as the comparability of its data, and comparability is destroyed by small, mundane inconsistencies rather than by gross errors. A transducer moved ten centimetres along a bearing housing, a mount changed from stud to magnet, a reading taken at partial load instead of full load, a sample drawn cold rather than running, an asset re-tagged without updating the database — each of these changes the measurement by more than most developing faults do. The result is a trend that reflects the measurement method rather than the machine, and a programme that generates confident findings which turn out to be wrong. In Indonesian operations, the programmes that stall almost never fail on analytical capability; they fail because nobody owns measurement consistency, and the data history becomes unusable before anyone notices.

Is your monitoring data trustworthy? Contact Tiaravib — email info@tiaravib.com or WhatsApp +62 821-1378-3727.

Comparability Is Not Accuracy

Condition monitoring teams tend to focus on instrument accuracy: calibration certificates, frequency response, transducer sensitivity. These matter, and they are almost never the reason a programme fails. The defining requirement is comparability — the ability to compare today’s reading with the same measurement taken previously under the same conditions. Accuracy without comparability produces precise numbers that cannot be interpreted.

This distinction has a counterintuitive consequence. A slightly inaccurate instrument used consistently at the same point, on the same mount, at the same load produces a trend that is entirely usable, because the bias cancels out in comparison. A perfectly accurate instrument used at a point that moves between surveys produces data that is worthless for trending, because the change being observed may be entirely a change in measurement. Plants that invest in better instruments while neglecting measurement discipline get worse data than plants with modest instruments and rigid consistency.

The practical implication is that data quality is a procedural and organisational problem, not an instrumentation one. This is why it persists: it is nobody’s favourite subject, it produces no visible output, and its absence only becomes apparent months later when a trend turns out to be an artefact.

The Four Root Causes

In practice, data quality failure traces to a small number of recurring causes. All of them are simple to fix in principle and all of them recur because nobody is accountable for preventing them.

No defined measurement point. If the technician decides where to place the transducer each visit, the point will drift. A stud mounted on the bearing housing at a marked location is a defined point; “the drive end bearing” is not. The requirement is a documented point per machine with a physical or procedural marker, recorded so that a different technician on a different day produces a comparable measurement. Where mounting pads cannot be installed — a common situation on older equipment and on hot surfaces — the procedure must at minimum define the location by dimension and orientation, and require that it be recorded.

No operating condition record. Vibration amplitude varies with load and speed; oil analysis results vary with temperature and running time. A reading with no record of the conditions under which it was taken cannot be compared with a reading taken under different conditions. This is the most commonly omitted element in Indonesian programmes, and it is fatal to trending because a load change of twenty percent can shift amplitude more than an advancing fault will over several months. The measurement record must capture load, speed, and relevant temperatures alongside the value, and analysis must account for them.

No route adherence discipline. A route that is completed in full every interval produces a usable history. A route that is completed in full most intervals, sometimes partially, occasionally skipped, produces a history with gaps and inconsistent intervals that makes rate-of-change calculations meaningless. Because trend analysis depends on the relationship between value and time, irregular intervals destroy it. This is the failure mode that affects outsourced and internal programmes equally, and it is what the continuity clauses in a well-designed monitoring service agreement exist to prevent.

No asset identity control. Equipment is re-tagged during projects, renumbered during audits, and sometimes recorded under different identifiers in the monitoring system and the maintenance system. When identity changes, the history either breaks or, worse, attaches to the wrong machine. A monitored asset whose identity is not strictly controlled will eventually accumulate a history that mixes two machines, producing trends that are actively misleading.

Interventions and the Missing Context

One data quality problem deserves separate treatment because it produces confident and completely wrong conclusions: unrecorded interventions.

A machine is realigned during a maintenance window. Its vibration drops. The trend shows a step improvement that an analyst who does not know about the realignment may interpret as an anomaly requiring investigation, or may use to conclude the machine’s previous baseline was wrong. A bearing is replaced and the signature changes completely, but if the replacement is not recorded the new signature looks like a developing fault. A lubricant is changed and wear metal concentrations reset, which looks like a machine that healed itself.

The fix is procedural and trivial: every maintenance intervention on a monitored asset must be logged against that asset and visible on the trend. This requires the monitoring system and the maintenance system to share asset identity — the point raised above — and it requires that the person performing the repair records it where the analyst will see it. In plants where these two systems do not talk, the analyst is routinely working with a history that omits the most significant events in it.

This is also why the practical value of integrated data is higher than it first appears. A machine learning model trained on a history that omits interventions will learn the interventions as machine behaviour and produce nonsense predictions. No analytical sophistication recovers from a history that does not record what was done to the machine.

Detecting a Data Quality Problem

Data quality problems announce themselves in a small number of characteristic ways, and an experienced reviewer can often identify a compromised programme from a handful of trend charts.

The clearest sign is step changes coinciding with something other than the machine. A jump in amplitude on a specific date that matches a personnel change, a route re-planning, a maintenance campaign, or a database migration is almost certainly a measurement artefact rather than a machine change. Machines deteriorate gradually; measurement systems change abruptly.

The second sign is statistics that are too clean. If every machine on a route shows a nearly identical variance, or if readings cluster suspiciously tightly around a round number, the data may be being entered from memory or reconstructed rather than measured. This is uncomfortable to raise and it happens, particularly where routes are rushed.

The third sign is findings that do not corroborate. When a monitoring report flags a developing fault that inspection does not confirm, repeatedly, the data is suspect before the analyst is. A programme whose findings are consistently not confirmed by physical evidence has a measurement problem, and continuing to refine the analysis will not fix it.

The fourth is missing history — not gaps in the recent weeks, which are visible, but a baseline period that turns out to be thinner than assumed. Many programmes discover after two years that their “trend” is three data points separated by irregular intervals, which is not a trend at all.

Recovering a Compromised History

Where the data has become unusable, recovery is possible and takes months rather than weeks. The sequence is to stop collecting bad data first, then establish a new baseline deliberately.

Fixing the measurement definition comes first: documented points, recorded conditions, controlled asset identity, and intervention logging. Only once the new regime is stable should a baseline period begin, running consistent measurement at a defined interval for long enough to establish what normal looks like — typically two to three months for a monthly route. During that period no alarms are set and no findings are issued, because there is no reference to issue them against. This is politically uncomfortable; the plant will ask why the programme has gone quiet. The answer is that a programme issuing findings from an invalid baseline is worse than a programme that is honestly rebuilding.

After the baseline period, thresholds can be established per machine rather than from tables, because a per-machine baseline is the only defensible basis for an alarm. The implementation roadmap sequencing applies here even to mature programmes recovering from bad data: information quality first, then baseline, then analysis, then alarms.

The organisational lesson is that preventing this is far cheaper than recovering from it. A programme with modest instrumentation, rigid measurement discipline, and one accountable owner outperforms a programme with excellent instruments and no consistency controls — and it costs less, because consistency is a procedural commitment rather than a capital one.

Related practice for Indonesian operators is set out in outsourcing and SLA design and online monitoring roadmap.

The practical remedy connects directly to how a monitoring programme is interpreted at a remote diagnostic centre, where data arriving without condition context cannot be assessed at all.

Key Takeaways

• Comparability, not accuracy, is what makes condition data usable; a consistent imperfect instrument beats an inconsistent perfect one.
• Small inconsistencies — a moved transducer, a changed mount, an unrecorded load — shift readings more than most developing faults.
• The four root causes are undefined measurement points, missing operating condition records, broken route intervals, and uncontrolled asset identity.
• Unrecorded maintenance interventions produce confident wrong conclusions, and only integrated asset identity between systems solves it.
• Step changes coinciding with personnel, route, or system changes are measurement artefacts, not machine changes.
• Recovery requires stopping bad collection first, then a deliberate baseline period with no alarms set.

Frequently Asked Questions

Is instrument accuracy or measurement consistency more important?

Consistency, by a wide margin. A slightly inaccurate instrument used at the same point, on the same mount, at the same load produces a usable trend because the bias cancels out. A highly accurate instrument used at a point that moves produces data that cannot be trended at all.

What is the most commonly omitted measurement record field?

The operating condition — load, speed, and relevant temperatures. Without it a reading cannot be compared with a reading taken under different conditions, and a modest load change can shift amplitude more than a developing fault does over several months.

How can we tell whether a step change is a fault or a measurement artefact?

Check what else changed on that date. Machines deteriorate gradually; measurement systems change abruptly. A step coinciding with a personnel change, route re-planning, maintenance campaign, or database migration is almost certainly an artefact rather than machine behaviour.

Why do unrecorded repairs cause misdiagnosis?

Because they change the signature legitimately, and without a record the change appears to be a developing fault. A realignment improving vibration, a bearing replacement altering the spectrum, or an oil change resetting wear metals all look like machine events rather than interventions unless they are logged against the asset.

Can a corrupted data history be recovered?

Yes, but it takes months. Stop collecting bad data first by fixing measurement definitions and recording; then run a deliberate baseline period of two to three months with no alarms set; then establish per-machine thresholds. Issuing findings from an invalid baseline is worse than a programme that honestly rebuilds.

Who should be accountable for measurement quality?

One named person. Not a committee and not a procedure document nobody reads. The owner is accountable for measurement point definition, condition recording, route completion, and asset identity — and the role is only effective if route completion and data integrity are visible to management.

To discuss data quality or rebuild a compromised monitoring history, contact Tiaravib at info@tiaravib.com or WhatsApp +62 821-1378-3727.

Data quality is the least discussed and most decisive element of a condition monitoring programme. Tiaravib has provided condition monitoring services to Indonesian industry since 1995, and the programmes that sustain results are those where measurement discipline is treated as an engineering requirement rather than an administrative one. Relevant references include ISO 17359 for condition monitoring programme structure, ISO 18436-2 for analyst competence, and ISO 13374 for data processing and presentation.