AVEVA PI System Data Quality Guide
AVEVA PI System Data Quality: 8 Common Issues and How to Fix Them
Stale tags, bad values, broken AF references, and failing calculations can undermine dashboards, reports, analytics, and AI long before the wider organization notices. This practical guide explains what to check, why it matters, and how to make PI System health monitoring repeatable.
A PI System can be online, collecting millions of events, and still contain data that should not be trusted. The difficult problems are often not complete outages. They are values that stopped updating quietly, AF Attributes that point to the wrong source, calculations that continue with stale inputs, or PI Vision displays that show a plausible number without revealing the issue underneath.
Data quality therefore needs to be treated as an operational discipline, not an occasional cleanup project. Teams need a consistent way to detect problems, understand where each value is used, prioritize by impact, document accepted exceptions, and confirm that fixes have improved the system.
What does data quality mean in the AVEVA PI System?
PI System data quality is broader than whether a snapshot value is marked Good. A measurement must also be fresh enough for its use case, plausible for the process, complete across the required time range, correctly described, connected to the right AF context, and available to the calculations and displays that depend on it.
Does the value have acceptable quality and fall within a plausible operating range?
Has the value updated within the interval expected for this signal and process?
Are the events required for trends, reports, calculations, and models present?
Are units, naming, limits, point types, and metadata applied consistently?
Is the signal linked to the correct asset, template, analysis, and business meaning?
Can an administrator see the source, transformations, and downstream dependencies?
A value can pass one dimension and fail another. A temperature tag may report Good quality but remain unchanged for two days. A calculation can run successfully while using the wrong engineering units. A PI Vision display can load without errors yet depend on an AF Attribute whose data reference no longer resolves. That is why a useful PI System health check must examine the full path from PI Point to operational use.
Why PI System data quality matters for AI
Industrial AI, machine learning, predictive maintenance, and generative AI assistants all depend on the operational data supplied to them. AVEVA describes the PI System as a foundation for predictive analytics and states that successful models depend on curated data with the required quality, integration, accessibility, and security. In practice, an AI initiative cannot repair an unreliable source layer simply by applying a more advanced model.
Drift, outages, frozen signals, and timing problems enter the data path.
Quality, compression, metadata, references, and calculations shape the dataset.
Dashboards, reports, data platforms, and feature pipelines inherit the result.
Predictions and recommendations are only as dependable as the data path beneath them.
Poor-quality operational data can teach a model that a frozen sensor is normal operation, hide the precursor to an equipment event, create false anomalies, or produce recommendations based on the wrong asset context. The same risk applies to retrieval-augmented AI: if the retrieved PI data is stale or mapped incorrectly, a fluent answer can still be wrong.
Before connecting PI data to an AI model, define freshness expectations, valid ranges, ownership, lineage, accepted exceptions, and the downstream impact of each critical signal.
Eight common PI System data quality issues
The table below provides a fast triage view. The detailed sections that follow explain the symptoms, likely causes, and first checks for each issue.
| Issue | Typical symptom | Operational risk | First check |
|---|---|---|---|
| Stale or frozen values | Timestamp is old or the trend remains flat unexpectedly | Operators and models act on outdated conditions | Compare latest timestamp with the signal's expected update interval |
| Bad or missing data | System digital states, gaps, I/O timeout, or no data | Reports fail, calculations stop, or totals become incomplete | Check interface status, buffering, point source, and data source health |
| Out-of-range values | Spikes, impossible readings, or gradual sensor drift | False alarms, distorted KPIs, and unreliable model features | Compare values with engineering and dynamic process limits |
| Metadata inconsistency | Wrong units, span, point type, naming, or descriptions | Misinterpretation and incorrect calculations | Validate metadata against point classes, templates, and standards |
| Broken AF references | AF Attributes cannot resolve or point to unhealthy tags | Asset context and downstream analytics become unreliable | Inspect data references, config strings, linked tags, and template inheritance |
| Unhealthy AF Analyses | Stopped, failed, late, or calculation-error states | Derived values and event logic are missing or wrong | Review service health, inputs, outputs, trigger behavior, and errors |
| Broken PI Vision dependencies | Symbols show no data, stale values, or unresolved sources | Users lose trust in operational dashboards | Trace every display source to its PI Point or AF Attribute |
| Poor compression settings | Too many archived events or loss of meaningful trend detail | Excess storage or reduced historical fidelity | Compare raw behavior, archived events, and required fidelity |
Stale or frozen PI Point values
A stale value is older than the freshness threshold appropriate for the signal. A frozen value may still receive timestamps while the measurement remains unchanged. Both can look believable on a dashboard, especially when the process is normally stable.
- Common causes
- Stopped interfaces, disconnected instruments, incorrect scan settings, source-system outages, points that are no longer written, or thresholds that do not match the signal.
- What to check
- Latest event time, expected scan frequency, interface health points, neighboring signals, source status, and whether the point is still operationally required.
- How to improve
- Use freshness rules by point class or process context. A four-hour threshold may be reasonable for one signal and unacceptable for another.
Bad values, system digital states, and missing data
PI digital states such as I/O Timeout, No Data, or Calc Failed make an error visible, but their effect is rarely confined to one tag. A bad input may interrupt an AF Analysis, create gaps in a report, or leave a PI Vision display without a usable value.
- Common causes
- Interface or connector failures, device communication problems, buffering gaps, incorrect point configuration, source rejection, or failed calculations.
- What to check
- Value status and timestamp, interface and buffer health, point source and location settings, archive gaps, and downstream calculations that consume the tag.
- How to improve
- Track both the current bad state and historical percent-good behavior. One good snapshot should not hide a repeated quality problem.
Out-of-range values, spikes, and sensor drift
A value can be technically Good while being physically impossible or operationally implausible. Simple limits find obvious errors, while dynamic or contextual limits are often needed for assets whose normal range changes with operating mode, grade, season, or load.
- Common causes
- Sensor failure or drift, scaling errors, swapped units, manual entry mistakes, wiring problems, and changes in the upstream control system.
- What to check
- Zero and span, engineering units, instrument calibration, rate of change, related signals, operating state, and configured AF limits.
- How to improve
- Combine hard engineering limits with rule-based checks that reflect actual asset behavior.
Incorrect or inconsistent PI Point metadata
Point names, descriptors, engineering units, point types, zero and span, source attributes, and compression settings determine how people and systems interpret a signal. Inconsistent metadata makes search harder and can silently change the meaning of downstream calculations.
- Common causes
- Legacy naming conventions, bulk point creation, copied configurations, migrations, incomplete commissioning, and standards that changed over time.
- What to check
- Required attributes, allowed values, naming patterns, unit consistency, point-source rules, and differences among otherwise similar tags.
- How to improve
- Define rule sets by tag family or template instead of expecting one universal standard to fit every PI Point.
Broken or misleading AF Attribute references
AF gives PI data its asset context, but an Attribute can contain a bad value, an invalid data reference, an incorrect config string, or a link to an unhealthy PI Point. Template inheritance can multiply one configuration error across many Elements.
- Common causes
- Renamed or deleted tags, malformed config strings, template changes, inconsistent substitutions, security restrictions, and manual overrides.
- What to check
- Attribute value quality, data reference type, config string, linked point, template source, limits, and repeated issues across related Elements.
- How to improve
- Review affected objects as a group. Fixing the governing template may be safer and faster than correcting individual Attributes.
Stopped, failing, or unhealthy AF Analyses
AF Analyses transform source data into KPIs, conditions, totals, forecasts, and Event Frames. When an analysis is stopped, delayed, misconfigured, or receiving bad inputs, the derived value may be missing, stale, or misleading even when the original tags are healthy.
- Common causes
- Bad inputs, syntax or configuration errors, service problems, excessive calculation load, trigger issues, output conflicts, and template changes.
- What to check
- Analysis status and errors, service load, latency, trigger configuration, input quality, output targets, owning Element, and template relationship.
- How to improve
- Prioritize analyses by what they feed. A failed calculation used by one test display is different from one driving a production KPI or AI feature pipeline.
PI Vision displays with missing or unhealthy data sources
PI Vision is where many users encounter PI data. A display may contain missing tags, unresolved AF paths, stale values, or sources whose upstream calculations have failed. Without dependency context, administrators often discover these problems only after a user reports them.
- Common causes
- Deleted or renamed data sources, broken AF references, unhealthy tags, access changes, copied displays, and retired assets.
- What to check
- Every symbol's source, display ownership and usage context, related AF objects, unresolved references, and the health of upstream points and analyses.
- How to improve
- Use impact-based prioritization. Fix issues on widely used operational displays before low-value or obsolete content.
Compression settings that reduce fidelity or waste storage
Compression is also a data-quality decision. Overcompression can remove meaningful variation from the archived trend; undercompression can retain unnecessary noise and increase storage and data movement. Static defaults rarely fit every process signal.
- Common causes
- Copied point settings, rule-of-thumb configuration, changed process behavior, incomplete commissioning, and no measurement of retained signal fidelity.
- What to check
- Raw snapshot behavior, archived events, exception and compression settings, intended use, and the level of historical detail required.
- How to improve
- Set an explicit fidelity target and compare the current and recommended trends before applying a change. See our PI System compression tuning guide for a detailed workflow.
A practical PI System data-quality process
Individual checks are useful, but the larger challenge is repeatability. A sustainable process needs to cover the full PI landscape and produce a prioritized worklist rather than a collection of disconnected spreadsheets.
Inventory what exists
Build a current inventory of PI Points, AF Elements and Attributes, AF Analyses, templates, and PI Vision displays across the systems in scope.
Define health rules in context
Set freshness, validity, range, metadata, reference, and analysis rules by asset or signal class. Record legitimate exceptions instead of letting them obscure new problems.
Scan and classify findings
Identify stale, bad, missing, out-of-range, rule-based, reference, analysis, and display issues. Group repeated problems to find common causes.
Prioritize by dependency and impact
Determine where each object is used, what depends on it, which displays and calculations are affected, and how critical those consumers are.
Remediate, document, and repeat
Fix the source or configuration, document accepted exceptions and ownership, rescan to verify the result, and run the process regularly enough to detect drift.
This approach works manually for a small environment. At enterprise scale, however, inventories become outdated quickly, checks require repeated data extraction, and dependency analysis consumes more time than the repair itself. That is the point where automation changes the operating model.
How PI Nexus+ automates PI System data-quality monitoring
PI Nexus+ gives PI administrators one place to scan health across PI Data Archive, Asset Framework, AF Analyses, and PI Vision. It turns a fragmented health check into a connected workflow: find an issue, inspect the affected object, trace upstream and downstream dependencies, prioritize the impact, document known exceptions, and verify the environment again on the next scan.
| Manual activity | PI Nexus+ workflow | Practical result |
|---|---|---|
| Export and reconcile separate inventories | Scans PI Points, AF objects, analyses, templates, and PI Vision displays | A connected, searchable view of the PI landscape |
| Build one-off checks and spreadsheets | Applies health rules for stale, bad, missing, out-of-range, and configuration issues | Repeatable findings and health KPIs |
| Open multiple tools to investigate context | Links object details, issues, AF context, inputs, outputs, and usage | Faster triage with less manual cross-checking |
| Search displays and analyses for references | Traces dependencies across PI Points, AF, AF Analyses, templates, and PI Vision | Impact is visible before cleanup or change |
| Remove known exceptions repeatedly | Supports filtering, exports, issue suppression, and documented reasons | Teams can focus on actionable findings without losing governance context |
| Guess at compression values tag by tag | Analyzes signal behavior, recommends settings, compares trends, and supports controlled application | Measured fidelity and storage decisions instead of static defaults |
PI Nexus+ automates the repetitive parts of the process—inventory, scanning, classification, health KPIs, filtering, exports, and dependency discovery—while keeping engineering judgment where it belongs. The software can show that a tag is stale and identify the displays or analyses that depend on it; the administrator still decides whether the source should be repaired, retired, reconfigured, or documented as an accepted exception.
The goal is not merely to find more issues. It is to shorten the path from an unhealthy value to the right corrective action—and to make that process repeatable.
For organizations preparing PI data for analytics or AI, that repeatability matters. A one-time cleanup produces a clean snapshot. A monitored health and dependency process creates a data foundation that can stay explainable as tags, assets, calculations, displays, and models change.
See the health of your PI System clearly
Evaluate PI Nexus+ in your own AVEVA PI System environment and see how automated health scanning and dependency analysis can replace fragmented manual checks.
Frequently asked questions
What are the most common data-quality problems in the PI System?
Common problems include stale or frozen PI Points, bad digital states, missing events, out-of-range values, inconsistent metadata, broken AF Attribute references, unhealthy AF Analyses, unresolved PI Vision sources, and compression settings that do not match the signal's required fidelity.
How do you find stale tags in the PI System?
Compare each PI Point's latest event time with a freshness threshold appropriate for that signal. Use different thresholds for fast process measurements, daily values, manually entered data, and intentionally inactive equipment. Then confirm the source and downstream usage before deciding whether to repair or retire the point.
Why is PI System data quality important for AI?
AI and machine-learning systems learn patterns and produce results from the data supplied to them. Stale values, gaps, incorrect units, bad asset mappings, or failed calculations can create false patterns and unreliable predictions. Data quality, context, and lineage should therefore be validated before PI data is used for AI.
Can PI Nexus+ automatically fix every data-quality issue?
PI Nexus+ automates inventory, health scanning, issue classification, filtering, exports, dependency discovery, and compression analysis. Many source and configuration problems still require an administrator or engineer to choose the correct remediation. This keeps operational decisions controlled while removing much of the repetitive investigation.
How often should a PI System health check run?
The right frequency depends on operational criticality and rate of change. Critical environments benefit from regular scans and clear ownership, while major migrations, interface changes, AF template updates, and AI projects should trigger additional reviews. The essential point is to make checks repeatable rather than relying on an annual cleanup.
