PI Tag Naming Conventions: Why They Matter and How to Do Them Right

A PI Point naming convention helps users identify signals consistently. It also supports search, automation, migration, and governance.

The best convention is not the longest or most descriptive. It is the one that is stable, documented, and aligned with the source and asset model.

Define the purpose of the name

Decide what users must learn from the PI Point name and what should live in metadata or AF.

A name can include elements such as:

• Site or area

• Equipment identifier

• Instrument identifier

• Measurement type

• Signal type

Do not force every business attribute into the tag name. Long encoded names become difficult to maintain.

Use stable identifiers

Avoid components that change frequently, such as department ownership or temporary project names.

Equipment and instrument identifiers are usually more stable.

Keep separators and abbreviations consistent

Choose a limited set of separators and approved abbreviations. Apply the same rules across new projects.

For example, do not use PRESS, PRES, and P for the same measurement type unless the variation is intentional and documented.

Preserve source-system meaning where useful

Many PI environments receive tag names from PLC, DCS, or SCADA systems. Renaming every tag in PI can create unnecessary mapping and migration work.

Use AF to normalize business meaning when source-system naming must remain different across sites.

Use metadata for context

Require clear descriptions, engineering units, source information, and ownership.

Metadata often provides more value than adding another encoded segment to the tag name.

Manage legacy tags carefully

Do not rename large numbers of existing tags only to improve aesthetics.

First identify dependencies in AF, analyses, PI Vision, and external systems. If the business value of renaming is low, enforce the new standard on future tags and normalize legacy content through AF or metadata.

Validate names automatically

Use automated checks for:

• Required pattern

• Approved abbreviations

• Duplicate names

• Missing descriptions

• Missing units

• Invalid or discouraged characters

Flag exceptions for review rather than silently changing production tags.

Document examples

A naming standard should include valid and invalid examples. Explain each segment and the reason for the rule.

The objective

A naming convention should help engineers identify and search for data without creating a fragile code system.

Combine stable names with strong metadata, AF context, and controlled change management.