PI System Audit Trail: What It Captures and How to Use It
The PI System audit trail records auditable changes and activity so teams can understand what changed, when it changed, and who made the change. That history can help with troubleshooting, compliance, change management, incident investigation, and PI System governance.
Audit information can also preserve knowledge that might otherwise live only with the engineer who made a change. The challenge is that auditing in the PI System is not one universal log. Coverage depends on the PI component, version, and configuration, and some audit functions need to be enabled before a change occurs if you want the history later.
A useful PI audit strategy starts with understanding what your environment records and which changes are important enough to review.
Why PI audit history matters
PI environments change constantly. Engineers create and modify PI Points, change compression or exception settings, update Asset Framework models, edit calculations, change source mappings, and adjust other configuration that affects how operational data is collected and used.
Most of those changes are normal engineering work. Problems arise later when someone needs to explain why a value changed, why a PI Vision display started behaving differently, or why a calculation no longer produces the expected result.
Audit history gives teams a place to start the investigation. Instead of relying on memory, email, or tribal knowledge, they can determine whether configuration changed around the same time as the problem.
For organizations with formal change-control or compliance requirements, the same history can provide evidence of who made a change, when it happened, and what was modified.
What does the PI System audit trail capture?
There is no single answer for every PI environment because audit coverage depends on the component and how auditing is configured.
PI Data Archive auditing can record changes and activity associated with PI data and configuration. If teams want a historical record of PI Point metadata changes, auditing needs to be configured before those changes occur. Some Point metadata may still show the most recent changer or modification date, but that does not provide a complete history.
Asset Framework has separate audit capabilities. Depending on the version and configuration, AF audit history can record changes to AF objects and provide information about the changed resource, the action, the time, and the user responsible.
In practice, organizations may use PI audit history to investigate changes involving:
PI Point configuration
PI Point metadata
Asset Framework objects
AF Attributes
AF Templates and hierarchies
Security and administrative activity
Other auditable PI configuration
Coverage of analyses, interfaces, and other related components varies. Teams should document what is actually audited in their environment instead of assuming that every action in PI is captured in one place.
What information is available in an audit event?
The exact fields depend on the component and type of event, but useful audit records generally help answer the same basic questions: what resource changed, when did it happen, who or what made the change, and what action occurred.
Where available, the record may also show the previous and new configuration values. That detail can make the difference between knowing that someone edited a Point and knowing that they changed its source, compression settings, engineering units, or another specific attribute.
User attribution matters as well. Named accounts make later investigations much easier because a recorded identity maps to a real person. Shared or generic accounts can leave teams knowing which account made the change without knowing who was actually responsible.
How do you review PI audit history?
The appropriate tool depends on the PI component and what the team is trying to investigate.
PI Audit Viewer has traditionally been used to inspect PI Data Archive audit information. Asset Framework audit history can be reviewed through PI System Explorer when AF auditing is available and enabled.
AVEVA also offers PI Audit Reporter, which is designed to centralize audit records from PI Data Archive and PI Asset Framework servers. It provides a web-based workflow for searching, filtering, annotating, collaborating, and reporting across one or more PI environments.
Some organizations also use programmatic approaches or third-party governance and observability tools to monitor configuration changes. The right choice depends on whether the need is an occasional technical investigation, a scheduled compliance review, continuous monitoring, or enterprise governance.
Access to the records is only part of the job. Teams still need to decide which events matter and what those changes can affect.
Who changed this PI Tag?
Finding who changed a PI Tag is one of the most common reasons to review PI audit history. If the appropriate PI Data Archive auditing was enabled before the change, the historical records can help identify the user or process associated with the modification.
If complete audit history is not available, PI Point metadata such as the most recent changer and change date may still provide some information. Those fields are useful for recent investigations but should not be treated as a replacement for a full change history.
For critical PI Points, a deliberate audit and change-management process is much more reliable than trying to reconstruct what happened months later from whatever evidence remains.
When did this AF Attribute change?
Asset Framework has its own audit capabilities for AF objects. When AF auditing is enabled, teams can use the audit history to investigate changes to Attributes, templates, hierarchies, and other model configuration.
This becomes useful when an Attribute or asset model no longer looks the way an engineer expects. Knowing when the configuration changed and who changed it can narrow the investigation quickly.
The audit record becomes even more useful when teams can connect the changed AF object to the calculations, PI Vision displays, reports, or other applications that use it.
Why did a PI Analysis start behaving differently?
The cause may not be inside the analysis itself. A PI Analysis can depend on AF Attributes, which may depend on PI Points, calculations, or other data references.
A change to an upstream tag, source mapping, scaling setting, AF configuration, or input can change the result while the analysis continues to run normally. For that reason, investigations should include recent changes across the dependency path rather than focusing only on the final calculation.
This is one of the clearest cases where audit history and lineage work well together.
Were compression settings changed?
Compression settings are part of PI Point configuration, and changes can affect the historical data stored after the modification. If the appropriate auditing was enabled, audit history can help determine whether the configuration changed and who made the change.
The same approach applies to exception settings, Point source, engineering units, zero and span, or other metadata that affects how data is collected and interpreted.
Compression is a good example of why configuration history matters. A small change to one setting can influence the historical record for years after the change.
What changed before an incident?
Audit history can be particularly useful during incident investigation. Suppose a process value starts behaving abnormally at 2:15 PM. Instead of reviewing every PI configuration change from the previous month, the team can focus on recent changes to that tag and its upstream dependencies.
The audit trail may show a Point configuration change, AF modification, or related event near the start of the abnormal behavior. A data-quality monitor can then show whether the signal changed at roughly the same time.
The audit record does not prove that the configuration change caused the problem, but it gives the investigation a much better starting point. The strongest investigations connect the time of the configuration change, the change in data behavior, and the downstream systems that use the affected resource.
Where PI audit trails become difficult
Scale is usually the first challenge. Large PI environments can include multiple servers, many users and applications, and hundreds of thousands of PI Points. Service accounts and automated processes can create large volumes of audit activity alongside human changes.
The second challenge is fragmentation. PI Data Archive and Asset Framework have separate audit capabilities, so reviewers may need to work across different tools or data sources. Centralized products such as PI Audit Reporter are intended to make that review easier across multiple PI Server environments.
Context is the third challenge. An audit event may tell you that a tag changed, but it does not necessarily tell you whether that tag feeds one display or dozens of calculations, reports, and AI applications.
That missing context often determines whether a change is low risk or something that needs immediate attention.
Use audit history and lineage together
Audit history tells you what changed. Lineage shows how the changed resource is connected to the rest of the environment.
Consider this path:
PI Tag configuration change → AF Attribute → PI Analysis → PI Vision → Power BI or AI
If the Point source changes, every downstream component may continue operating normally. The PI Analysis can still calculate, the display can still render, and a report can still refresh even though the underlying source has changed.
The audit trail provides the configuration event. Lineage helps identify the calculations, displays, reports, and applications that may need to be reviewed because of that event.
This combination is useful for both troubleshooting and change management because it reduces the amount of manual dependency tracing required after a change.
How audit history helps with PI data quality
Many data-quality problems have configuration causes. Incorrect scaling, source mapping changes, compression changes, calculation inputs, engineering units, and AF data references can all change the behavior of operational data.
A data-quality monitor may show that a signal became stale, noisy, flat, or inconsistent with its normal behavior. Audit history can show whether configuration changed around the same time.
For example, suppose a flow measurement suddenly begins reporting values roughly twice its historical range. If the audit history shows that its scaling or source configuration changed shortly before the behavior changed, the team has a specific configuration to investigate.
Connecting configuration history with data behavior is useful even outside regulated environments. It can significantly reduce the time required to understand why PI data changed.
PI System audit trail best practices
Start with the resources that matter most to operations. Reviewing every audit event with the same level of attention creates unnecessary work and makes important changes harder to find.
For critical resources, define which types of changes require review. Changes to Point source, scaling, engineering units, compression, exception settings, calculation inputs, and important AF configuration are good candidates.
Use named identities where possible so audit events can be tied to a person or clearly identified service account. Retention requirements should also be defined intentionally based on operational, regulatory, validation, and legal needs.
Important changes should have a documented reason. Where practical, connect the audit event with the work order, change request, incident, or project that explains why the configuration was modified.
Finally, connect audit history with lineage and data quality. That allows teams to understand the change, see whether the data started behaving differently, and identify the downstream resources that may be affected.
PI System audit checklist
For important PI resources, teams should be able to answer:
Can we identify who or what changed the resource?
Can we see exactly what changed?
Can we determine when the change happened?
Can we compare the previous and current configuration?
Is there a documented reason for the change?
Can we identify upstream dependencies?
Can we identify downstream dependencies?
Can we assess the possible operational impact?
Can we correlate the change with a data-quality problem?
Can we distinguish expected automated activity from unexpected changes?
Can we retrieve the history when we need it?
If answering these questions requires several people, multiple tools, and a long manual investigation, the organization has audit data but still has work to do on the audit process.
How Tycho Data approaches PI auditability
Tycho Data treats auditability as part of a broader PI System governance and observability workflow. Osprey tracks PI configuration changes and adds context around the affected resources, including lineage, downstream dependencies, metadata, and data health.
If a PI Tag changes, teams can review the change alongside the AF Attributes, analyses, PI Vision displays, or other applications that depend on it. They can also compare the configuration history with data-quality information to see whether the signal started behaving differently around the same time.
This reduces the manual work required to move from finding a configuration change to understanding whether it matters and what it may affect.
Frequently asked questions
What is the PI System audit trail?
The PI System audit trail is the recorded history of auditable activity and configuration changes within PI components. It helps teams understand what changed, when the change occurred, and which user or process made the change.
The exact information available depends on the PI component, version, and audit configuration.
What does PI audit history capture?
Depending on configuration, PI audit history can include PI Data Archive data and configuration changes, PI Point metadata changes, Asset Framework object changes, and other auditable system activity.
PI Data Archive and Asset Framework have separate audit capabilities, so teams should document what is enabled in their environment instead of assuming that every component is covered automatically.
How do I find who changed a PI Tag?
If PI Data Archive auditing was enabled before the change, the audit history may identify the user or process responsible. PI Point metadata can also retain the most recent changer and change date, although that information does not provide a complete historical record.
Using named accounts makes this information much more useful during an investigation.
How do I audit Asset Framework changes?
Asset Framework has separate audit capabilities for AF objects. When AF auditing is enabled, teams can review changes to AF configuration through the available AF audit tools.
The history available depends on the AF version and how auditing has been configured.
What is PI Audit Viewer?
PI Audit Viewer is a traditional PI utility for inspecting PI Data Archive audit information. It is useful for targeted technical investigations where an administrator needs to review specific audit records.
Organizations with broader or more formal review requirements may also use PI Audit Reporter.
What is PI Audit Reporter?
AVEVA PI Audit Reporter is an add-on that centralizes PI audit information from PI Server environments, including PI Data Archive and PI Asset Framework. It provides a web-based workflow for searching, filtering, annotating, reviewing, and reporting audit information.
This makes it useful for organizations that need to review audit activity across several PI systems or formalize periodic review processes.
How do audit trails support PI System governance?
Audit trails provide evidence of how PI configuration changes over time. That supports change management, ownership, troubleshooting, compliance, and accountability.
The history becomes more useful when organizations also know who owns the resource, why the change occurred, and which systems depend on it.
How do PI audit trails help troubleshoot data-quality problems?
Configuration changes can affect the behavior of PI data. Changes to scaling, Point source, compression, exception settings, AF data references, or calculation inputs can cause signals and derived values to behave differently.
Comparing the timing of a data-quality problem with recent audit history can identify configuration changes that deserve closer investigation.
Connecting PI change history with operational context
PI audit history is most useful when teams can connect a configuration change to its reason, the behavior of the affected data, and its downstream impact.
Osprey connects PI change history with lineage, data quality, and downstream dependencies so teams can investigate important changes without manually reconstructing the entire data path.