PI Tag Governance: Best Practices for Naming, Managing, and Cleaning Up PI Tags

PI environments accumulate tags over time. Projects add new tags. Control-system migrations create new naming patterns. Temporary points remain after a project ends. Duplicate signals can appear across interfaces and servers.

Without governance, the PI Data Archive becomes harder to understand and maintain.

Define ownership before you define a naming standard

A naming convention does not solve governance by itself.

First define who can create, change, and retire PI Points. Also define who approves exceptions to the standard.

The process should cover:

• New tag requests

• Required metadata

• Source-system ownership

• Naming review

• Change approval

• Retirement and decommissioning

Without ownership, naming rules will drift.

Use names that are consistent and stable

A good PI Point name should be unique and consistent. It should also remain useful when equipment ownership or organizational structure changes.

Many organizations include some combination of site, unit, equipment, measurement, and signal type. The exact pattern must match the plant and control-system standards.

Do not create a new enterprise naming format only because it looks cleaner. A migration that renames thousands of tags can create more risk than value if downstream dependencies are not known.

Put context in metadata and AF, not only in the tag name

A tag name cannot contain all operational context.

Use PI Point attributes and PI Asset Framework to store information such as:

• Description

• Engineering units

• Source system

• Instrument or equipment identifier

• Area or unit

• Data owner

• Criticality

• Intended use

This makes the data easier to search and reduces dependence on complex tag-name parsing.

Detect duplicates carefully

Two tags with similar names are not always duplicates. Two tags with different names can represent the same physical signal.

A duplicate review should compare:

• Data source and source address

• Point source or interface

• Description and engineering units

• Time-series behavior

• AF mappings

• Downstream usage

Do not delete a suspected duplicate until you know what depends on it.

Track usage before cleanup

A tag can look unused at the archive level and still support a PI Vision display, an AF attribute, an analysis, or an external application.

Before retirement, identify known dependencies. Record the decision and define a rollback plan when the change has material risk.

This is especially important during server consolidation and control-system migration.

Review stale and abandoned tags

A stale tag can indicate a failed instrument, an inactive asset, a broken interface, or a retired data source.

Classify the condition before you act. A stale tag that belongs to an out-of-service asset is different from a stale tag that supports a critical running process.

Useful cleanup categories include:

• Active and healthy

• Active but unhealthy

• Temporarily inactive

• Candidate for retirement

• Retired but retained for history

Govern changes as well as creation

Tag governance must include changes to point source, location, exception settings, compression settings, engineering units, description, and security.

A change to one of these fields can affect downstream calculations and interpretation even when the tag name does not change.

Use a recurring review cycle

Tag governance is not a one-time cleanup project.

Review naming, metadata, duplicates, stale points, usage, and configuration changes on a regular schedule. Use automation for inventory and comparison where possible.

The goal is not a perfectly clean historian. The goal is a PI environment in which engineers can identify a signal, understand its source, know where it is used, and change it safely.