Leslie Shields, Lead Systems Engineer at ITI Group, discusses the challenges of involving your users in PI AF development, and how to overcome them. 

 

Anyone who has worked with AVEVA’s PI AF for any length of time knows it’s a powerful tool.  However, due to this power, care is required when building in PI AF to ensure that only robust, performant solutions are deployed.

The traditional solution to this is to have dedicated PI Developers who work with users to solve issues and create AF solutions.  For larger scale or complex AF builds this solution is still usually the best option, but this can involve significant back and forth between the developer and the user, and can add unnecessary cost to small scale projects. Often therefore, businesses investigate the possibility of user-led development.  On the surface, this sounds fantastic, empowering users to quickly build solutions to solve their problems, speeding up innovation, and lessening the load on central teams. What could go wrong?

Spoiler alert: a lot.

 

Can Everyone Be a Developer Now?

PI AF is deceptively easy to use: a user can quickly create attributes, set up templates, and create analysis calculations without writing a single line of custom code. That’s both a strength and a potential minefield.

Once users get a taste, left to their own devices they tend to go rogue – creating calculations with little to no error handling, creating multiple templates, building analytics that although they work are not very performant and, occasionally, detrimental to the analysis service performance. They will often end up building solutions that are difficult to support.  These unsupported, undocumented solutions then end up being critical without anyone realizing it… until they break… or the user leaves the company… and suddenly nobody has any idea of the history and design decisions made when building the solution.

 

The Perils of Unsupported AF Builds

Here’s the problem with letting users run wild in AF without robust management:

• No documentation: The original builder leaves the company, and no one knows how or why that element template was built.
• Performance nightmares: One user’s clever calculations can become the reason your analysis service is required to be restarted every week.
• Data trust issues: When every user has their own version of the truth, trust in the data erodes. Different values from different solutions don’t match, and nobody knows which value is “correct”.
• Security and access risks: With open access, some users are tempted to do far more than they should – deleting attributes, overwriting others’ work, or pushing half-finished untested builds to production.
• Support chaos: PI support teams get flooded with support calls for something they didn’t build, don’t understand, and aren’t sure they should even be supporting.

 

So, What Can You Do About It?

The aim is not to lock users out of PI AF – you just want to help them build solutions that don’t come back to haunt the support teams six months down the line.  The aim is to strike the right balance between user empowerment and system stability.

 

1. Create a Suitable Development Environment

Without a structured development pathway, users often make changes directly in production or deploy untested / unreviewed solutions.

What can you do about this?

• Set up separate environments: A development system and production system is a minimum standard. Sometimes there may be multiple large-scale PI AF developments concurrently running, and thus it may also be worth setting up a sandbox environment where users can develop without affecting these projects.
• Create a deployment pipeline (manual or automated) to move builds from dev to prod with defined review procedures in place to minimize any risks.
• Consider creating custom tools using PowerShell scripts or AF SDK-based utilities to automate migrations and version tracking. We’ve done lots of this for customers and know all the tricks of the trade.

Bonus tip: Lock down production write access to a small group. Let users submit changes for review rather than editing directly.

 

2. Train, Certify, Empower

Whilst building in AF can appear straight forward, training and ongoing support is essential to ensure that good practice is followed when constructing AF solutions:

• Train your users to build good solutions. Our PI AF Developer training is popular for this sort of thing, but also consider leveraging AVEVA’s learning materials or building internal training programs.
• Track user certification to ensure competency. This can be as simple as a register of trained users.
• Maintain a knowledge base with guides, templates, and troubleshooting tips.
• Support your users by providing routine coaching or a medium for engaging other PI AF users within your business.

 

3. Enforce Naming Conventions & Templates

Inconsistent names and poor templatization make it nearly impossible to maintain AF over time:

• Create a naming convention for database objects e.g. categories, so that maintenance can be consistently applied across all AF databases.
• Tag elements and templates with metadata like owner, creation date and version number so that the support team knows who to direct queries to if anything goes wrong.

Bonus tip: Build a searchable catalog of built AF solutions, so users can browse existing databases before duplicating effort. It should be clear what exactly belongs in each database.

4. Secure the Unit of Measure Database

Most objects within PI AF are unique to each database, however, the Unit of Measure database is common across all AF databases on the server.  This can lead to a jumbled mess of duplicate units in various classes, often with diverging conversion factors:

• Lock write access to the UoM database. This should only be editable by support teams.
• Create a workflow and review process for users to request new units of measure.

Bonus tip: As your system grows, create tools to validate UoM databases across different AF Servers to ensure there is one single UoM database that matches across all AF instances.

5. Implement Change Control

Unreviewed changes can have a detrimental effect on the performance of the analysis server or PI Data Archive.

• Set up a well-documented change management process.
• Require a peer review by an expert PI AF Developer (such as your PI support team) before anything is ready for deployment to production.
• Implement some sort of versioning to track who changed what, when, and why.

 

6. Assign Ownership

When an AF solution has no owner, or the owner is unknown, it is difficult to know the history of the solution, and no one knows who to approach with queries.

• Assign an owner or custodian to every AF database.
• Build a process to reassign ownership if someone changes roles.
• Embed owner info in the database description or metadata.

Bonus tip: Schedule regular reviews of critical assets to verify ownership and usage.

7. Monitor Usage and Performance

Innocent user mistakes or poorly defined analytics can degrade server performance significantly.

• Create a health monitoring solution to monitor calculations and usage. Capture performance points using PI PerfMon to identify issues before they affect performance significantly.
• Identify analytics in error and either disable them or get them working again.

Bonus tip: Build a review of the system performance into any regular support checks (daily/weekly/monthly) to help find and flag issues.

 

The Bottom Line

Letting users build in AF isn’t the problem – it’s letting them build without any governance, training, or support. With the right guardrails in place, user-led development becomes a force multiplier, not a support nightmare. Users create the magic Proof of Concepts that a skilled PI AF Developer can scale out to all of your assets.

So go ahead, open the gates but don’t forget to install a few speed bumps, some signposts, and maybe a guardrail or two along the way!

And as always, if you need any help with anything PI System related, our expert engineers are only a phonecall or a message away…