Skip to content
Software AthleteSoftware Athlete
How to Trace PI Vision Display Dependencies Before Changing PI Points or AF

PI System administration guide

How to Trace PI Vision Display Dependencies Before Changing PI Points or AF

Before you repoint an AF Attribute or retire a PI Point, find the displays that use it. Follow the references in PI Nexus+ from the source, through any analyses, to the PI Vision views operators rely on.

By Software Athlete · Based on the PI Nexus+ v1.5 user guide

Before you begin

You need access to PI Nexus+ with inventory covering the relevant PI Data Archive, Asset Framework (AF) database, and PI Vision instance. Have the tag name and server, or the full AF Attribute path, ready.

Use inventory collected after the latest structural changes. A health refresh checks known objects; it does not discover new references or rebuild the dependency map. If coverage is incomplete, ask the administrator to reconcile the relevant inventory first. Controls and object-detail access depend on your role and license.

1. Open the source you plan to change

For a tag, open PI Points, filter by its PI Data Archive, and search by tag name or path. For an attribute, open AF Attributes and search by name or path, using the AF server filter to narrow the results. Click the matching row.

In Basic Information, check the full identity. Similar names on different servers or assets are not interchangeable. For an AF Attribute, inspect its parent element, data reference, configuration string, and linked PI Point.

For example, suppose Boiler 2|Steam Flow is being changed to read a replacement tag. Start with that attribute. If the old tag itself is being retired, start with the PI Point as well: other attributes or displays may still use it.

2. Find its direct consumers

Open Usage for a PI Point or Datasources for an AF Attribute. Inspect the PI Vision display references and the analysis input/output lists. Include healthy objects in the view; a display that works today can still depend on the source you are about to change.

Separate references that consume the source from references that produce it. An analysis using the attribute as an input is a downstream branch to follow. An analysis writing to it explains where its value comes from. Open related objects to inspect their roles, then use Back to return.

Do not add the header counts together as a unique impact total. They describe relationship sets, and the same object may be reachable by more than one path.

PI Nexus+ sample object detail showing usage relationships and related-object counts
The sample point BP.1 has two PI Vision display consumers and no listed AF Attribute or analysis references. The point itself is healthy, while both displays show errors. Select the image to inspect it at full size.

3. Follow each branch to a display

Open Dependency Graph in the source object's detail. Expand downstream connections with the node controls. Where available, pin the source node, choose Downstream, and select Full path to highlight the route beyond its direct neighbors.

  • Follow a PI Point to the AF Attributes and displays that reference it.
  • For an attribute used by an AF Analysis, open the analysis and inspect its output attributes in Usage. Continue from those outputs toward PI Vision.
  • Expand grouped stacks. Use Find a node or type to locate objects in a large graph and Open fullscreen when you need more room.

In the boiler example, Steam Flow might feed both an operating display and an analysis calculating shift totals. The shift report display may use the analysis output without referencing Steam Flow directly. Following only the first display list could overlook that second route.

If branches appear absent, use Reset to clear the graph's type and health filters. Dashed edges can represent paths through hidden nodes. If the graph is truncated, open related objects from Usage or Datasources and continue the trace from there. A limited graph is not proof that no further consumers exist.

PI Nexus+ graph showing the BP.1 PI Point connected directly to two PI Vision displays, with type and health filters
This simple graph shows BP.1 feeding two displays directly. Use the node controls to explore branches in your own environment. Health labels describe the scanned state; they do not predict whether a planned change is safe. The boiler example has an additional analysis branch.

4. Inspect the affected display references

Click a PI Vision display node or open the display from a relationship list. In its Usage tab, inspect the referenced PI Points, AF Attributes, and calculations. Check the display ID and PI Vision instance in Basic Information, then use Open in PI Vision to see what operators actually view.

For a display with asset-context projection, the graph's Detail view shows the datasource and analysis chain; Assets groups it by AF Element. Test the relevant selectable assets in PI Vision. A display working on one asset does not establish that another asset uses the intended replacement source.

Note the dependency path and what the planned change would affect. Treat these as investigation decisions, not automatic edits performed by PI Nexus+:

Reference found What it tells you What to inspect next
Display uses the PI Point directly The display still consumes that tag, independently of the AF Attribute you are changing. Inspect the display's datasource before retiring the old point.
Display uses the AF Attribute The display consumes the attribute whose data reference you plan to change. Check the replacement source, units, and relevant asset context.
Display uses an analysis output The effect may travel through a calculated result. Follow the analysis input and output attributes; inspect the result shown on the display.

5. Finish the impact list

Keep one entry per display ID and PI Vision instance, with each relevant dependency path and asset context beneath it. This avoids counting the same display several times while preserving the different references that need attention. Copy link to this item gives you a direct link back to an object's details.

You are finished when every branch you identified has a known destination or an explicit unresolved limit. In the boiler example, the list should distinguish the operating display from the shift-total display and show how each depends on Steam Flow.

Make the actual source or display changes in the responsible PI System tools. Afterwards, reconcile inventory for the changed structure, repeat the affected trace, and open the relevant PI Vision views to check the result. For a wider check of stale values or broken sources, use the PI System health guide.

If a known dependency is missing

The object is absent: check the server, database, and instance scope. Use Show missing for previously discovered objects. Ask the administrator to inspect the relevant inventory scan and enabled targets.

You opened an AF Element: use Attributes & Analyses to open the relevant child attribute or analysis. An AF Element's own detail dialog does not have a Dependency Graph tab.

The display list looks incomplete: clear relationship health filters, expand graph stacks, and inspect related objects directly. Some display details show only a subset of effective attribute instances; a partial view should not be treated as a complete impact list.

The result is bounded by the scanned inventory and supported relationships. Check separately for consumers outside that scope. An empty list is not, by itself, a reason to delete a tag.

Leave a comment

Your email address will not be published..

Cart 0

Your cart is currently empty.

Start Shopping