A historian's job is to capture the story of a process over time, but that story has holes whenever a communication link drops or a buffer overflows and samples are simply never recorded. Data completeness is the metric that measures how much of the story actually made it in - the share of the samples you should have captured that you did. This guide defines completeness precisely, separates it from the neighboring qualities of accuracy and timeliness, explains what causes gaps, and describes why regulators and analytics insist on a completeness threshold before a dataset can be trusted.
Data Completeness in one line: Data completeness in a SCADA historian is the percentage of expected samples that were actually captured over a period - if a tag should have recorded a value every ten seconds and a tenth of those are missing, its completeness is ninety percent. It is a headline data-quality metric distinct from accuracy (whether the recorded values are correct) and timeliness (whether they arrived on time), and it is measured per tag and rolled up across a system to gauge whether a dataset is trustworthy.
Completeness is a ratio, and it starts from an expectation. For a given tag over a given period you can calculate how many samples should exist - if the tag is meant to be recorded every ten seconds, then over an hour you expect three hundred and sixty samples. Completeness compares that expected count against how many were actually captured. If all three hundred and sixty are present, completeness is one hundred percent; if thirty-six are missing, it is ninety percent. The metric is only as meaningful as the expectation behind it, so knowing each tag's intended sampling behavior is a prerequisite.
The subtlety is that not every tag is expected to produce a value on a fixed clock. Many historians record on change, or by exception, meaning a tag only logs when its value moves by more than a deadband, so a steady tag legitimately produces few samples. For such tags a naive expected-count based on a fixed interval would wrongly report low completeness for a perfectly healthy, stable signal. Sound completeness measurement accounts for the collection method, distinguishing a tag that is quiet because nothing changed from one that is quiet because collection failed - the first is complete, the second is not.
Because it is defined per tag, completeness can be computed for a single point and then aggregated. A per-tag completeness score tells you the coverage of one measurement; rolling those up gives a system-level or site-level completeness that summarizes how well the whole historian captured its data over the period. Both views are useful: the aggregate tells you the overall health of the dataset, while the per-tag breakdown tells you which specific measurements have gaps, so a headline number of, say, ninety-eight percent can be traced to the handful of tags dragging it down.
Completeness is one dimension of data quality and is often confused with its neighbors, but they measure different things. Completeness asks whether the data is there at all - how much of what should have been recorded was recorded. It says nothing about whether the values that are present are correct. A tag could be one hundred percent complete and still be wrong if the transmitter behind it is miscalibrated; completeness would happily report full coverage of bad numbers.
Accuracy is the separate question of whether the recorded values reflect reality - whether the pressure the historian shows is the pressure that actually existed. A dataset can be complete but inaccurate, or accurate but incomplete, and the two problems have entirely different causes and fixes. Timeliness is a third dimension: whether the data arrived and was recorded on time, or with delay. Data can be complete and accurate yet stale, arriving too late to be useful for real-time decisions. Keeping these distinct matters because chasing the wrong metric wastes effort - a completeness problem is a collection or communication issue, whereas an accuracy problem is an instrumentation or calibration issue.
Completeness earns its status as a headline metric because it is often the first thing to check and the easiest to reason about. If the data is not there, no amount of accuracy or timeliness helps - you cannot analyze what was never captured. So completeness acts as a gate: it tells you how much of the record exists before you even ask whether that record is correct and timely. This is why it is frequently the top-line data-quality number reported for a historian, with accuracy and timeliness assessed on the portion of data that is actually present.
Gaps that reduce completeness come from breakdowns in the path between the measurement and the historian. Communication loss is the classic cause: when the link to a remote site drops, no samples arrive during the outage, leaving a hole in every tag from that site for the duration. Buffer overflow is another: many systems buffer data locally during a communication outage and forward it when the link returns, but if the outage outlasts the buffer's capacity, the oldest buffered samples are lost and never recovered. Historian downtime, collection service failures, and misconfigured collection all punch their own holes.
Analyzing those gaps is how completeness becomes actionable rather than just a number. Gap analysis identifies when the missing periods occurred, how long they lasted, and which tags they affected, so a repeated daily gap points to a scheduled communication problem while a one-off multi-hour gap points to a specific outage. Understanding the pattern of the gaps often diagnoses the cause - a whole site going dark together implicates the link to that site, whereas scattered single-tag gaps implicate those individual points. Completeness measurement without gap analysis tells you there is a problem; gap analysis tells you where and why.
Thresholds are what make completeness consequential, and this is where it intersects with regulation, analytics, and cloud monitoring. Regulatory reporting and emissions accounting often require a minimum completeness before a period's data can be used - a dataset with too many missing samples cannot be certified as representative, so a completeness threshold is a gate on whether the record is admissible. Analytics has the same need: a model or a calculation built on a dataset riddled with gaps produces unreliable results, so completeness is checked before the data is trusted. A cloud SCADA platform such as Merobix supports this directly by continuously tracking each tag's expected versus actual samples, computing completeness per tag and across sites, surfacing the gaps and their timing for analysis, and letting an operator confirm that a period cleared its required completeness threshold before the data is used for a report or a decision - turning completeness from an afterthought into a monitored, defensible property of the historian.
Completeness is the number of samples actually captured divided by the number that should have been captured over a period, expressed as a percentage. If a tag is meant to record every ten seconds, an hour should yield three hundred and sixty samples, and capturing three hundred and twenty-four of them gives ninety percent completeness. The calculation depends on knowing each tag's expected sampling behavior, and it must account for on-change collection so a stable, quiet tag is not wrongly counted as incomplete.
Completeness measures whether the data is there - how much of what should have been recorded was recorded - while accuracy measures whether the values that are present are correct. A dataset can be fully complete but inaccurate if the instrument is miscalibrated, or accurate but incomplete if communication gaps left holes. They are separate data-quality dimensions with different causes: completeness problems are collection or communication issues, and accuracy problems are instrumentation issues.
A dataset with too many missing samples cannot be considered representative, so a period's data may fail to be certifiable for regulatory reporting or emissions accounting until it clears a minimum completeness. Analytics has the same requirement, because a model or calculation built on gap-riddled data produces unreliable results. The threshold acts as a gate: it confirms enough of the record actually exists before anyone trusts the conclusions drawn from it.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.