Is the quality of data same that quality of produced parts?

This article is about the quality of the data your monitoring system collects — not the quality of the parts your machines produce. It's an important distinction, since "quality" on a manufacturing blog usually means inspection and defects. Here it means something upstream of that: whether the numbers your monitoring system reports actually reflect what happened on the shop floor. Bad data quality quietly undermines every metric built on top of it, often without anyone noticing until a number looks obviously wrong.

Contents:

1. Why data quality matters
2. Missing and incomplete data
3. Misconfigured thresholds and mappings
4. Timestamp and clock sync issues
5. Inconsistent definitions across machines
6. Manual entry errors
7. How to detect data quality issues
8. How to prevent them
9. Frequently asked questions
10. Conclusion

Why data quality matters

Every metric covered elsewhere on this blog — OEE, uptime, cycle time trends — is only as trustworthy as the data feeding it. A perfectly correct formula applied to bad data still produces a wrong answer, and the failure mode is often worse than an obviously broken system: a plausible-looking but inaccurate number is far more dangerous than an obviously broken one, because it gets trusted and acted on. Data quality issues are rarely dramatic; they tend to be small, silent, and cumulative.

Missing and incomplete data

A sensor going offline, a network interruption, or a machine being powered down for maintenance all create gaps in a data stream. The problem isn't the gap itself — it's how the gap gets treated. A system that silently interprets "no data" as "machine stopped" (or worse, as "machine running") will produce metrics that look complete but are quietly wrong for that period. The correct handling is to explicitly flag missing data as missing, distinct from any legitimate machine state, so it can be excluded or handled deliberately rather than blended invisibly into a report.

Misconfigured thresholds and mappings

As covered in more depth in our piece on turning raw signals into metrics, a lot of what a monitoring system reports depends on configuration choices — what spindle load counts as "cutting," which alarm codes map to which downtime category. A threshold set incorrectly during setup, or one that was correct for the original machine but never updated after a controller upgrade, can produce data that looks reasonable at a glance but is systematically off. These errors are particularly dangerous because they don't look like errors; they just look like slightly different numbers than expected.

Timestamp and clock sync issues

Machine monitoring depends on accurate, consistent timestamps to make sense of anything — durations, sequencing, correlation between machines. A few specific problems show up repeatedly:

• Clock drift between different machines or edge devices, where each device's internal clock has slowly diverged from actual time.
• Timezone inconsistency, where some data is stored in local time and other data in UTC without clear, consistent conversion.
• Delayed data arrival being mistaken for the actual event time, particularly in systems with buffering or retry logic that can deliver a value well after it was originally recorded.

We cover the underlying structure of timestamped data in more detail in our time-series data primer; the practical takeaway here is that timestamp problems are often invisible until you try to correlate events across machines or reconcile a shift report against what actually happened.

Inconsistent definitions across machines

On a mixed fleet, it's common for different machines — especially ones added to a monitoring system at different times, by different people — to end up with subtly different definitions for the same nominal state. One machine's "running" threshold might be more permissive than another's; one might count a specific alarm as downtime while a similar machine doesn't. Individually these are defensible configuration choices, but collectively they make cross-machine comparisons unreliable, since a difference in reported performance might reflect configuration differences rather than actual operational differences.

Manual entry errors

Wherever a human is part of the data pipeline — logging a downtime reason, entering a scrap count, confirming a job number on a terminal — error and inconsistency naturally creep in: wrong reason code selected out of habit, a count entered late and estimated rather than counted, a field left blank when it's inconvenient to fill in. This isn't a criticism of operators; it's an inherent property of manual data entry that any process depending on it needs to account for, typically through simpler input methods, sanity-check validation, or cross-referencing against automated data where possible.

How to detect data quality issues

• Sanity-check ranges. Flagging values outside a plausible range (a spindle speed reading that's physically impossible for that machine) catches obvious sensor or connection faults quickly.
• Cross-referencing sources. Comparing machine-reported part counts against a separate counting method, where available, can reveal systematic discrepancies that neither source alone would show.
• Watching for suspicious uniformity. A metric that's suspiciously perfect (100% Quality, exactly identical cycle times every time) is often a sign of missing data rather than genuinely flawless performance.
• Periodic manual spot checks. Occasionally comparing a dashboard's reported state against what's actually happening on the floor catches configuration drift that automated checks might miss.

How to prevent them

• Document configuration decisions. Recording why a specific threshold or mapping was set the way it was makes it far easier to catch when it's no longer correct after a machine change.
• Validate new connections before trusting them. When a machine is newly connected, compare its reported data against known ground truth for a period before relying on it for reporting.
• Standardize definitions where machines are genuinely comparable. Where cross-machine comparison matters, align configuration deliberately rather than leaving it to whoever set up each connection.
• Make manual entry as low-friction as possible. Simpler, faster logging tends to produce more consistent data than lengthy forms operators are tempted to skip or rush.
• Monitor the monitoring system. Alerts for unexpected data gaps or a machine that's stopped reporting entirely catch problems before months of bad or missing data accumulate unnoticed.

Frequently asked questions

How is "data quality" here different from product or part quality?

Product quality is about whether the parts a machine produces meet specification. Data quality, as covered here, is about whether the data a monitoring system collects accurately reflects what actually happened on the machine — a separate concern, though poor data quality can make it harder to detect real product quality issues too.

What's the fastest way to spot a data quality problem on an existing system?

Look for suspiciously perfect or suspiciously flat metrics, unexplained gaps in historical data, or numbers that don't match what people on the floor would intuitively expect. These are usually faster to spot than working backward from a formula.

Does adding more sensors or connections automatically improve data quality?

Not necessarily. More data sources without corresponding validation and configuration discipline can just mean more places for quality issues to originate. Quality depends more on how carefully each source is configured and checked than on the raw number of sources.

Who should be responsible for catching data quality issues?

In practice, it's often a shared responsibility: whoever configures machine connections should validate them at setup, and whoever regularly reviews reports is well positioned to notice when a number looks implausible, even without technical knowledge of why.

Conclusion

Data quality problems rarely announce themselves — they show up as numbers that are subtly, persistently wrong rather than obviously broken, which is exactly what makes them dangerous to trust. Missing data treated as a real state, misconfigured thresholds, timestamp misalignment, inconsistent definitions across machines, and manual entry errors are the most common sources, and all of them are far cheaper to catch through deliberate validation than to discover after a report has already misled a decision.

Related articles:

• From Raw Signals to Useful Metrics
• Time-Series Data from Machines: A Primer
• What Machine Signals Matter for OEE
• Data Collection for Beginners
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.