What Is AVEVA PI Audit Reporter and How Does It Work?

AVEVA PI Audit Reporter is an add-on for the PI System that centralizes audit records from PI Server environments into a web-based interface for search, review, annotation, and reporting.

It is designed for organizations that need to review PI System audit history more efficiently, particularly when audit information spans multiple PI Data Archive and PI Asset Framework servers. AVEVA positions the product for quality and compliance teams, IT and OT administrators, and site managers who need a more consistent way to review and report on PI audit activity.

For organizations in regulated industries, this can address a practical problem. The PI System may already record the underlying audit information, but reviewing that information across multiple servers and tools can become a manual process.

What problem does PI Audit Reporter solve?

PI System auditing can capture useful information about changes to operational data and configuration. The challenge grows when an organization has multiple PI Servers, large amounts of audit history, or formal review requirements.

Historically, teams have used tools such as PI Audit Viewer and component-specific audit views to examine records. That can work for focused investigations, but periodic enterprise reviews can become difficult when records are spread across systems or need to be reviewed by people outside the PI administration team.

AVEVA built PI Audit Reporter around that problem. According to its product documentation, the system can ingest audit records from one or more PI Server installations, including PI Data Archive and PI Asset Framework servers, and bring those records into a centralized web interface.

This is especially relevant for regulated environments where teams need repeatable audit reviews, annotations, documented findings, and reports that can be provided to quality or compliance groups.

How does AVEVA PI Audit Reporter work?

At a high level, PI Audit Reporter collects PI audit records and makes them available through a centralized application.

AVEVA describes an architecture that uses remote agents to ingest records from PI Server installations. Those records can include data from PI Data Archive and PI Asset Framework servers. Reviewers then work with the consolidated information through a web-based interface.

Once the information is centralized, users can filter and search audit activity, annotate records, collaborate during reviews, and generate reports. AVEVA also supports retaining or excluding records through filters and exporting reports in PDF and CSV formats.

For organizations with multiple PI environments, the centralization is important. It gives reviewers one place to work instead of requiring them to repeat the same process against individual PI Servers.

What types of audit information can PI Audit Reporter review?

PI Audit Reporter's scope depends on the audit information produced by the underlying PI environment. AVEVA specifically states that the product can ingest audit records from PI Data Archive and PI Asset Framework servers.

Depending on which PI auditing features are enabled, that can include changes to data or configuration, user attribution, and other auditable PI activity. PI Data Archive auditing and AF auditing have their own behaviors and configuration, so organizations should not assume that every possible action in the PI System automatically appears in an audit report.

That distinction matters. PI Audit Reporter improves how audit records are aggregated and reviewed, but it cannot report an event that the underlying system did not capture.

Organizations should therefore understand both sides of the process: what their PI components are configured to audit and how PI Audit Reporter will present those records for review.

What are the main PI Audit Reporter features?

AVEVA's current product material describes several capabilities aimed at formal audit review.

The first is centralized audit trail aggregation. Remote agents can collect records from multiple PI Server installations and make them available through one web interface.

The product also includes features aimed at regulated and validated environments. These include preservation of electronic signatures, user attribution and comment history, as well as the ability to track change-control numbers that can be associated with external change-management or ITSM processes.

Reviewers can use filters to narrow the records they need to evaluate, annotate records, share comments, and produce PDF or CSV reports. Role-based access control, Active Directory integration, single sign-on, and on-premises deployment are also part of the current offering.

Taken together, these features position PI Audit Reporter as a review and reporting layer on top of PI System audit information.

Common use cases for PI Audit Reporter

One obvious use case is periodic audit review. In a regulated environment, a quality or automation team may need to review PI System changes over a defined period, document findings, and provide evidence that the review occurred.

Another use case is investigation. If a process value or PI configuration changed unexpectedly, audit history can help determine whether a user or system modified the underlying configuration.

Compliance teams may also use the system to review records, add comments, associate findings with change-control processes, and generate reports for internal or external audits.

For PI administrators, centralized access can also reduce the effort required to respond to requests from quality, IT, security, or operations teams. AVEVA specifically positions the product around reducing the manual effort involved in finding, annotating, reviewing, and reporting PI audit records.

PI Audit Reporter vs. PI Audit Viewer

PI Audit Viewer and PI Audit Reporter are related to the same underlying need, but they represent different approaches to audit review.

PI Audit Viewer is the older application used to read PI Data Archive audit records. AVEVA Community documentation describes it as a separate application used to work with the PI audit logs and inspect records such as historical value changes.

PI Audit Reporter is designed for a broader centralized workflow. It can aggregate records across PI Server installations, including PI Data Archive and PI Asset Framework, and provide a web interface for filtering, annotations, collaboration, and reporting.

In practical terms, PI Audit Viewer is useful when an administrator needs to inspect PI Data Archive audit information directly. PI Audit Reporter is aimed more at repeatable organizational review, particularly when multiple systems, reviewers, reporting requirements, or compliance workflows are involved.

For a company with a single PI Server and occasional technical investigations, the simpler workflow may be enough. An enterprise with several PI environments and formal audit procedures has a different problem.

Where does PI Audit Reporter fit into PI System governance?

Audit reporting is one part of PI System governance.

A mature governance program also needs to address ownership, configuration standards, data quality, change management, lineage, and the lifecycle of PI resources.

PI Audit Reporter supports the change-management and auditability side of that picture. It helps organizations review captured activity, understand who made changes, document findings, and maintain a review process.

It can also help connect PI activity with external change-control processes. AVEVA specifically includes support for tracking change-control numbers, which gives teams a way to associate audit records with broader organizational processes.

That can be particularly useful in pharmaceutical and other validated environments where explaining why a change occurred can be as important as knowing that the change occurred.

What does audit reporting not answer by itself?

Audit data is very good at answering questions about change. It can tell you that a resource changed, when the change occurred, and often who or what made the change.

Other questions require additional context.

For example:

• Which PI Vision displays use the changed tag?

• Which PI Analyses depend on it?

• Which AF Attributes reference it?

• Does the tag feed a Power BI report or AI application?

• Did the behavior of the data change after the configuration change?

• Is the affected measurement currently stale or flatlined?

These are dependency, lineage, and data-quality questions rather than audit-reporting questions.

This distinction becomes important during an incident. Knowing that a tag changed is useful. Knowing that the same tag feeds three calculations, fifteen displays, and an AI workflow tells the team much more about the potential impact.

PI audit reporting vs. PI System observability

Audit reporting and observability overlap, but they focus on different information.

Audit reporting focuses on recorded activity and configuration change. It helps answer questions such as who changed something, when they changed it, and what was modified.

Operational data observability looks at the broader condition of the data and its dependencies. It can include whether a signal is healthy, how resources are related, which downstream applications depend on them, and whether a configuration change coincides with a data-quality problem.

A PI administrator investigating a bad value may need both.

The audit history could show that a configuration changed at 2:15 PM. Data-quality monitoring could show that the signal began behaving abnormally at 2:16 PM. Lineage could then show which calculations and displays rely on that signal.

Those pieces answer different parts of the same investigation.

How Tycho Data complements PI audit reporting

Tycho Data approaches PI auditability as part of a wider operational data observability and governance problem.

Osprey adds context around PI resources, including lineage, downstream dependencies, data quality, and configuration monitoring. That can help teams understand the operational impact of a change after they identify it in the audit history.

For example, if a critical PI Tag changes, Osprey can help show which AF Attributes, analyses, PI Vision displays, and other applications depend on the tag. Data-health information can also help determine whether the signal's behavior changed around the same time.

This is complementary to audit reporting. PI Audit Reporter is designed to centralize and support review of PI audit records. Osprey focuses on adding operational context around the resources and data affected by those changes.

Frequently asked questions

What is AVEVA PI Audit Reporter?

AVEVA PI Audit Reporter is an add-on for the PI System that centralizes audit records from PI Server environments and provides a web-based interface for searching, reviewing, annotating, and reporting that information. It can ingest records from PI Data Archive and PI Asset Framework servers.

What is the difference between PI Audit Reporter and PI Audit Viewer?

PI Audit Viewer is an older application used to inspect PI Data Archive audit records. PI Audit Reporter provides a centralized web-based workflow that can aggregate audit records from multiple PI Server installations and support filtering, annotations, collaboration, and reporting.

Does PI Audit Reporter show who changed a PI Tag?

PI Audit Reporter preserves user attribution from the underlying audit records, so where the PI audit data captures the responsible user or actor, that information can be included in the review workflow. The exact information available still depends on what the underlying PI System audit configuration recorded.

Can PI Audit Reporter review Asset Framework changes?

AVEVA states that PI Audit Reporter can ingest audit records from PI Asset Framework servers as well as PI Data Archive servers. The available records depend on the AF auditing configuration and the changes captured by the underlying system.

Is PI Audit Reporter used for compliance?

Yes. AVEVA explicitly positions PI Audit Reporter for regulated and validated environments and includes features such as electronic signatures, user attribution, comment history, change-control tracking, annotations, and report generation.

Does PI Audit Reporter show downstream impact?

PI Audit Reporter focuses on aggregation, review, annotation, and reporting of audit records. AVEVA's current published feature set does not position dependency or downstream lineage analysis as its primary function. Tools that provide lineage can add context by showing which calculations, AF Attributes, displays, reports, or AI applications depend on a changed PI resource.

Where PI audit reporting fits

PI Audit Reporter addresses a real gap for organizations that already have PI audit data but need a better way to review it across systems and teams. Its strongest use cases are centralized audit review, compliance workflows, collaboration, and reporting.

For organizations that also need to understand data health and downstream impact, audit reporting can be combined with lineage and observability. That gives teams both the history of what changed and the operational context around the affected data.

Already reviewing PI audit history? Osprey adds lineage, data health, and downstream impact to help teams understand what a PI change can affect.