Handling Nonexistent Tags in PI Vision: The Good, The Bad, and The Bullshit

Introduction

With over 11 years of programming experience, I have worked extensively on systems like the PI System. Not only do I use these kinds of software, but I also understand how they might have been built, which helps me identify and resolve issues effectively. Leveraging this expertise, I have analyzed the issue at hand and proposed three solutions to address it. Special credit goes to Paul Brown, who first highlighted this issue on PI Square in 2021. Check out Paul Brown’s profile for more insights.

When working with PI Vision and PI System Explorer, you might encounter a peculiar issue where a nonexistent PI tag behaves inconsistently across these platforms. This blog post dives into the problem, its root cause, and proposed solutions—ranging from practical workarounds to humorous frustrations.

---

The Problem

Imagine you have an analysis expression configured in PI System Explorer with attributes like TheTag and Analysis Expression Result. When TheTag does not exist:

1. Expected Behavior (PI System Explorer):

   When TheTag is nonexistent, the expr expression evaluates properly in PI System Explorer, showing the appropriate value based on the logic (e.g., 3 when avgtest is BadVal).

2. Unexpected Behavior (PI Vision):

   In PI Vision, when TheTag is nonexistent, the Analysis Expression Result attribute displays No Data instead of the evaluated value (3).

3. Observations:

   • PI System Explorer correctly applies the expr logic to handle nonexistent tags and returns a valid result.
   • PI Vision seems to fail to recognize or display the value for Analysis Expression Result when TheTag is nonexistent, instead showing No Data.This inconsistency can lead to frustration, especially when your PI Vision screen fails to reflect the expected behavior.

Example Scenarios

We have two attributes in our analysis:

1. Tag1: A tag that exists and holds historical data.
2. Tag2: A tag that does not exist in the PI system.

Figure 1: Comparison of Tag Behavior

The analysis expression for both attributes is as follows:

• If BadVal is true (indicating a nonexistent or bad tag), return 0.
• Otherwise, return the actual value of the tag.

Figure 2: Analysis Expression Logic

When this analysis is run:

• In PI System Explorer: Both Tag1 and Tag2 are processed correctly. The logic handles Tag2 gracefully and returns the expected default value (0). Figure 3: Analysis Results in PI System Explorer

• In PI Vision: Tag1 is processed correctly, but Tag2 results in “No Data” instead of the expected value (0). Figure 4: Analysis Results in PI Vision

---

Root Cause

Through my observations, the crux of the issue lies in the differing roles and backend processes of the two systems:

1. PI System Explorer: Relies on the PI Analysis Service, which executes each step of the analysis dynamically. It checks for the existence of tags during runtime, allowing it to handle nonexistent tags gracefully.

2. PI Vision: Operates on the PI Vision Server, which eagerly loads data for display purposes. Its primary goal is to showcase data rather than perform complex on-the-fly calculations. As a result, when a tag does not exist, the server fails at the data-loading stage and cannot proceed with the analysis.

[Add Root Cause Diagram/Image]

---

Proposed Solutions

Solution 1: The "Bullshit" Workaround

For cases where a PI tag attribute does not exist, a workaround can be implemented using supplementary attributes. Here's how it works:

1. Create a Child Attribute:

   For every PI tag attribute that might not exist, create a child attribute to hold the actual PI tag. Figure 5: Child Attribute Creation

2. Parent Attribute Logic:

   The parent attribute uses a Formula Data Reference to evaluate the existence of the tag. The logic would involve an If condition:

   • If BadVal is true (indicating the tag doesn't exist), return a default value like 0 or No Data.
   • If BadVal is false, return the actual PI tag value (from the child attribute).

   Figure 6: Pivision fix

3. Downsides of this Workaround:

   • Scalability Issues: For large AF hierarchies, managing these supplementary attributes can become a nightmare, especially if there are many such attributes.
   • Performance Impact: Adding these extra checks and logic layers increases computational overhead, which can slow down analysis execution.

In short, while this workaround might resolve the issue, it introduces significant complexity and performance trade-offs, making it less ideal for large systems.

---

Solution 2: The "Bigger Bullshit" Workaround

This approach involves forcefully creating PI Points for all attributes where a PI tag is missing. Here's how it works:

1. Enable Auto-Creation of PI Points:

   Configure the system to automatically create PI Points for attributes that don't have an associated PI tag. Figure 7: Auto-Creation of PI Points

2. Trigger the "Create Config" Option:

   Once auto-creation is enabled, run the "Create Config" process to generate PI Points for all relevant attributes. Figure 8: Create Config Process

3. Result:

   With these PI Points created, the PI Vision Server no longer encounters issues with missing tags. Since all attributes now have an associated PI Point, the server can seamlessly calculate the analysis and return results.

4. Why This is a "Bigger Bullshit" Workaround:

   • Unnecessary PI Point Creation: Many of these PI Points are redundant and not truly system-created, leading to potential misuse of storage and naming conventions.
   • Scalability Concerns: For systems with hundreds or thousands of such attributes, this approach significantly increases the number of PI Points, adding administrative overhead and storage demands.
   • Maintenance Complexity: Managing these "dummy" PI Points over time can become chaotic, especially if their usage is temporary or unclear.
   • Cost Implications: If you don’t have an enterprise license, creating additional PI Points increases your licensing costs. Each PI Point adds to your billing, making this workaround financially burdensome for systems with many such attributes.

---

Solution 3: "AVEVA, Get Your Act Together!"

This solution is the simplest yet the most effective (and what we all want): AVEVA should fix this longstanding issue.

The root cause of this problem has been around for years, and it was already pointed out three years ago by Paul Brown (credit where credit's due!). Despite the community raising awareness, the bug remains unresolved, leaving users to resort to "Bullshit" and "Bigger Bullshit" workarounds.

To put it bluntly: AVEVA, stop the madness! It’s time to prioritize this fix and save your users from unnecessary headaches, scalability issues, performance hits, and extra costs.

---

Conclusion

While there are workarounds to address the issue of nonexistent tags in PI Vision, each comes with its own trade-offs. Ultimately, the responsibility lies with AVEVA to fix this long-standing problem and provide a seamless experience across PI Vision and PI System Explorer.

Got similar issues or better solutions? Share your thoughts in the comments below!