A historian value can be syntactically valid and still be unsuitable for a KPI. A frozen sensor, a unit mismatch or a stale reading can pass a simple “not null” check. The analytical pipeline needs to describe why a value is usable, not merely whether it exists.
This note proposes vendor-neutral rules for industrial time series. Its fields and example policy are synthetic; it publishes no internal tag names, sensor thresholds or employer configuration. Historian-specific status codes must be interpreted using the actual source contract rather than assumed to be equivalent across products.
Separate four questions
Evaluate source quality, plausibility, freshness and analytical coverage independently. One boolean named valid often collapses distinctions that matter to operations.
| Dimension | Example question | Consequence to define |
|---|---|---|
| Source status | Did the source flag an acquisition or communication problem? | Retain the status and mark the observation unusable for the affected calculation. |
| Plausibility | Does the value fit its unit, process state and physical limits? | Flag for review; do not automatically call it a sensor fault. |
| Freshness | Is a recent observation available within the agreed tolerance? | Show stale status, even if the last number looks reasonable. |
| Coverage | How much of the requested window supports this aggregate? | Withhold or qualify the KPI under the approved policy. |
A high value during startup may be plausible while the same value during shutdown is suspicious. Thresholds should follow engineering context and documented operating states. A single global range is easy to maintain but can reject legitimate behavior or accept impossible combinations.
Preserve raw values and explain transformations
Keep original value, unit, event timestamp, source status and arrival timestamp where available. Store normalized values separately, with the rule version and reason codes. A consumer should be able to distinguish “received as zero,” “missing” and “replaced by an estimate.”
An illustrative prepared record could use this contract:
{
"asset_id": "example-pump",
"variable": "example-flow",
"event_time_utc": "2026-10-01T06:00:00Z",
"raw_value": null,
"normalized_value": null,
"unit": "m3/h",
"quality_reasons": ["source_bad"],
"rule_version": "example-v1"
}This is a conceptual record, not a PI tag or API response. Retain source identity and raw status in the surrounding lineage record as well. If a rule is later corrected, that lineage makes a controlled recalculation possible.
Detect suspicious patterns without erasing events
A flat-line rule can flag repeated values over a defined period, but steady operation can also produce a stable signal. Combine duration, expected process state and corroborating measurements before classifying the condition. Similarly, a sudden change can represent a real trip rather than a bad observation.
Statistical outlier rules help identify candidates for investigation. They should not silently replace all unusual values with a median. That replacement can suppress the very incidents the analysis aims to detect. Retain a flag and make the treatment explicit for each use case.
Aggregate according to time semantics
For irregular observations, a simple sample mean gives more weight to periods with more samples. Decide whether the variable needs a sample-weighted or time-weighted treatment. State signals and event intervals may require duration accounting instead of averaging numbers.
Define the maximum gap across which interpolation or holding a value is allowed. Do not bridge a long communication outage merely because observations exist on both sides. A quality coverage percentage should represent supported duration when the metric is time-based, rather than just the fraction of non-null rows.
An illustrative acceptance policy might require 90% supported duration. That number is a teaching example, not a recommended operational threshold. Its real value must be approved for the specific decision and risk. If only 80% is supported, publish insufficient coverage under that policy; do not fill the missing duration with zero to produce a complete-looking result.
Operate the rules as a maintained product
Assign an owner to each rule and a route for investigating exceptions. Track quality by asset and variable so recurring acquisition problems remain visible. Separate engineering changes, source corrections and analytical rule changes in the history.
Before releasing a KPI, test missing input, bad source status, stale observations, unit changes, genuine process extremes and late corrections. Record how each affects the result. The IOC KPI catalog should reference the approved policy and the PI AF structure can organize asset context.
The practical outcome is a result with an explanation: what was observed, which duration was usable and which rules were applied. That explanation is more useful than a dashboard that always displays a number.