PI Asset Framework Templates That Last

The Tag That Only One Person Understands

Open the tag list on a mature processing plant and you will find something like 40,000 points with names along the lines of CV301_MTR_I_PV and FIC_2201.PV. Every one is a real measurement logged every few seconds. Most are unreadable to anyone who was not in the room when they were configured.

That is not a naming failure. It is what a historian is. PI Data Archive keeps tags in one flat namespace, with no folders, no parent and child, and no record that CV301_MTR_I_PV is drive current on a crushing area conveyor while FIC_2201.PV is a flow controller three circuits away. The historian knows each tag's name, data type, compression settings and values. It does not know what the tag is bolted to.

This works while the people who configured the tags are still on site. It stops working the moment you want a report spanning forty pieces of equipment, a comparison of this year's mill throughput against last year's, or an assistant that can answer a question about a pump without being handed the tag name first.

Asset Framework is the part of the AVEVA PI System that fixes this. It is also the part most often built badly, because building it badly is faster and the bill does not arrive for two years. This article is about the difference between an AF model that ages well and one that has to be rebuilt.

What Asset Framework Actually Is

AF puts an asset model over the tags. Instead of a list of point names, you get elements: a pump is an element, with attributes like Discharge Pressure, Suction Pressure, Motor Current and Running State. Each attribute points at something underneath, usually a PI tag, sometimes a table lookup, sometimes a calculation.

The tag FIC_2201.PV does not disappear. It becomes the thing sitting behind Flotation\Cell 3\Feed Flow. Someone who has never seen the tag list can now find the feed flow on cell 3, because it is named after what it measures and lives where the asset lives.

That reframing is what makes everything downstream possible. A Power BI report can ask for Feed Flow across every flotation cell without a human first translating that into twenty tag names. A calculation can be written once against Discharge Pressure and applied to every pump on site. An engineer transferred from another operation can find their way around the plant without an interpreter.

The model is only worth what its structure is worth. An AF database built without design is a second flat namespace wearing a tree costume.

The Pieces, In Plain Terms

If you know plants but have not built AF, these are the parts worth understanding before anyone opens PI System Explorer.

An element is an asset: a pump, a mill, a conveyor, a tank, an area, a plant. Elements nest inside each other to form the hierarchy.

An attribute is something about that asset. It might read live from a tag, hold a static value like design capacity, or calculate from other attributes.

An element template is the definition of a type of asset. You define Pump once, with its attributes, and every pump on site is created from it. Change the template and every element built from it changes.

An attribute template is the definition of one attribute inside that element template, including where its value comes from. This is where the design either works or fails, and the reason is substitution parameters. Rather than hardcoding a tag name, you write a pattern. AVEVA's own training material gives the example of a naming pattern %Element%LI.PV, where %Element% resolves to the name of whichever element is using the template. Create Tank01 from that template and the attribute resolves to Tank01LI.PV on its own. Create forty tanks and you have configured forty level measurements without typing forty tag names.

Inherited templates let one template derive from another. A base Pump template holds what every pump has, and a Slurry Pump template extends it with gland water pressure and wear data. The base template stays clean, and the derived ones carry only what applies to them.

Attribute traits hold characteristic information about a parent attribute. AVEVA's documentation describes these as covering limits, forecast values, geolocation, reason codes, asset health and analysis start triggers, defined either as fixed values or through a data reference. Traits are how a limit belongs to the measurement it constrains instead of floating beside it as a loose attribute called Pressure_HiHi.

Analyses are calculations that run against elements. Defined on the template, an analysis applies to every element built from it, which is how AVEVA's material frames the point of analysis templates: managing calculations in a standardised and consistent manner.

Event frames capture a period of time rather than an instant. An event frame is defined by a name, a start and end time, and context in the form of event attributes and related assets. Downtime, a batch, a grade excursion, a trip: anything with a beginning and an end.

Why Hierarchies Rot

Most AF problems are not bugs. The model was built to match the plant on the day it was built, and the plant moved.

Having spent 18 years working in OSIsoft PI, AVEVA Ampla, AVEVA System Platform and Citect on Australian industrial sites, the failure modes repeat with unusual consistency. Six of them account for nearly everything.

Templates shaped around the current physical layout. The template assumes a pump sits under a specific circuit under a specific area, and the attribute paths reach up through that structure. Reorganise the plant, move a unit between areas, or commission a parallel circuit, and references break in places nobody predicted. The template encoded the arrangement rather than the asset.

Attributes hardcoded to specific tags. Somebody opened an element, typed a tag name into an attribute, and moved on. It works immediately, which is the trap. Now the element has a private relationship with a tag that the template knows nothing about. Multiply by a few thousand and the template is decorative.

A hierarchy that mirrors the P&ID instead of how people ask questions. Piping and instrumentation drawings are organised for engineering and construction. Nobody walks up to a historian and asks a question shaped like a P&ID. They ask about throughput by circuit, availability by crew, energy per tonne by area. A hierarchy that mirrors the drawing makes those questions require traversal that the model was never arranged to support.

One enormous template. A single Equipment template with fifty attributes, of which most are empty for most assets, because it had to cover pumps and conveyors and tanks at once. Every query now has to cope with nulls, every display shows blank fields, and nobody can tell whether an empty attribute means missing data or a measurement that never existed.

No naming standard. The same measurement is Feed Flow in one area, Flow_In in another and FeedRate in a third. Cross-plant comparison becomes manual reconciliation, and the model that was supposed to be self-describing needs a glossary.

Analyses written per element. A calculation is configured directly on one element, copied to the next, then adjusted slightly on the third. Two years later the site wants to change how availability is computed and discovers the change means editing hundreds of elements individually, with no way to confirm they all ended up the same.

Design Rules That Survive a Plant Change

The rules below are unglamorous and they hold up.

Template first, always, and never element by element. If an element has an attribute its template does not define, that is a defect, even when it works today. Configuring directly on elements is the single habit that produces every other problem on this list. Make it a rule that survives deadline pressure, because deadline pressure is exactly when it gets broken.

Use substitution parameters so elements resolve their own tags. The attribute template should describe the pattern, and the element should supply the identity. When this is done properly, creating an asset is one operation and the data reference follows. When it is not, every asset is a manual configuration job with its own opportunity for a typo.

Keep the hierarchy shallow. Every level you add is a level that queries traverse, displays step through and people get lost in. Deep hierarchies feel thorough during design and become tedious in daily use. If a level exists only because it exists on a drawing, it probably does not need to be an AF level.

Separate the asset model from the reporting rollups. The asset model should describe physical reality. Reporting structures, which group by crew, product, business unit or whatever the finance team asked for last quarter, change far more often than the plant does. Mixing them means a reporting change forces an asset model change. Keep reporting groupings as their own structure referencing the asset model, so the volatile part can move without disturbing the stable part.

Name attributes for what they measure, not where they live. The element already supplies location. An attribute called Cell3FeedFlow on Cell 3 is saying the same thing twice and breaks the moment the element is reused. Call it Feed Flow. The path supplies the rest.

Decide who owns the model before you build it. Not who builds it. Who owns it afterwards, approves changes, and says no when someone wants to add a one-off attribute to a single element. A model without an owner accumulates exceptions until the exceptions are the model.

Tag Naming Is the Precondition

None of the above rescues a site whose tag naming is inconsistent, and this is the part most AF projects underestimate.

Substitution parameters work because tag names follow a predictable pattern. %Element%LI.PV resolves correctly when every level indicator on site is named the same way. Where three vendors commissioned three areas across fifteen years using three conventions, the pattern resolves for one area and fails for the others. The usual response is to hardcode the exceptions, which reintroduces the original problem one element at a time.

AF amplifies whatever discipline exists in the tag naming underneath it. Given a consistent convention, it turns that consistency into an asset model that builds almost mechanically. Given inconsistency, it spreads the inconsistency into a structure that is now harder to fix, because the mess has been copied rather than resolved.

This is why an honest AF engagement often starts with a naming audit rather than template design, and why ISA-95 equipment hierarchy concepts are worth borrowing even if you never formally adopt the standard. Its enterprise, site, area, work centre and equipment levels give a vocabulary that works across sites and outlasts whoever is in the role today. Getting the naming and structural standards settled before the model is built is the same discipline that makes SCADA, historian and ERP production figures reconcile rather than diverge, and it tends to be the work that determines whether the rest succeeds.

Event Frames, Downtime and Delay Accounting

Event frames are where AF stops being a naming exercise and starts carrying operational meaning. A downtime event becomes a record with a start, an end, the asset it belongs to and whatever context attributes you attach, including a reason code. Because event frames are generated by analyses running on templates, downtime capture that is designed once applies across every asset of that type.

There is a complication worth naming early, because it catches sites repeatedly. Many Australian operations already record downtime somewhere else. If the site runs AVEVA Ampla, delay accounting is already capturing downtime events with reason codes, usually with operator input and an established reason code tree behind it. Stand up event frames in AF without accounting for this and the site ends up with two downtime records that disagree, because the two systems started their clocks differently, rounded differently, or applied reason codes from different trees.

Deciding which system is authoritative for downtime is a design decision, and it should be made before either system is extended rather than discovered during a reporting dispute. Where Ampla holds the reason codes and operator context, the sensible pattern is usually to treat the Ampla delay accounting model as the source of truth for why the plant stopped, and use AF event frames for the process context around the stoppage: what the feed was doing, what the power draw looked like, which upstream unit moved first. The two then complement each other instead of competing. Getting that boundary right is also a large part of what an Ampla support arrangement should cover, since the reason code tree drifts as the plant changes and someone has to keep the two models aligned.

What the Model Makes Possible Downstream

The commercial argument for AF is that almost everything a site wants to do with its process data depends on asset context existing somewhere.

Reporting is the obvious case. A Power BI report built against raw tags encodes tag names into the report, so the report breaks whenever the plant changes and cannot be reused across areas. Built against AF, it asks for an attribute across a set of elements and keeps working as assets are added. The mechanics of doing that without accidentally building a second historian are covered in detail in our guide to getting historian data into Power BI, which is worth reading alongside this one because the model and the reporting layer are separate problems that get solved together.

The same holds for analytics and for AI. There is enthusiasm at the moment for assistants that answer questions about plant performance in plain language, and the demonstrations are genuinely impressive. What determines whether one works on your site is rarely the model behind it. An assistant asked about a pump has to know which tags are that pump, what the measurements mean, what units they are in and what normal looks like. That knowledge is precisely what AF holds. Without it, the assistant is guessing from tag names, and tag names are the thing nobody could read in the first place.

For operations running this on site data, tag naming, a sound asset framework and a read-only boundary between the AI layer and the control system matter considerably more than which model is doing the reasoning. Keeping plant data within your own environment is a realistic requirement in Australian resources and utilities, which is the territory our private AI infrastructure work covers, and the connection back into business systems is ordinary system integration work.

Somebody Has to Own the Model

An AF hierarchy is not a project deliverable that stays finished. Plants change constantly: units are added, circuits are rerouted, instruments are replaced with different tag names, areas are renamed after a restructure. Each of those changes has a correct response in the model, and if nobody makes it, the model and the plant drift apart.

The drift is slow enough to ignore and fast enough to matter. Within a couple of years an unowned hierarchy contains elements for equipment that no longer exists, attributes pointing at decommissioned tags, and analyses still producing numbers for assets that were taken out of service. People stop trusting it, go back to the raw tags, and the investment is written off without anyone deciding to write it off.

This is the argument for treating model maintenance as an ongoing responsibility with a named owner rather than an occasional cleanup. That can sit with an internal engineer who has the time and the mandate, or it can sit with an outside party under a managed support arrangement that covers change control, template revisions and keeping analyses honest as the plant evolves. What does not work is leaving it unassigned and assuming the person who built it will notice.

Where to Start

The right first move depends on what already exists, and the most expensive mistake is starting template design on a site whose tag naming will not support it.

For a site with nothing in place, resist the temptation to model the whole plant. Take one asset type that exists in quantity, build the template properly with substitution parameters and analyses, generate every element of that type, and confirm it resolves across all areas. That exercise surfaces the naming problems immediately, at a scale where fixing them is still cheap.

For a site with an existing model that has stopped being trusted, the first question is which of the six failure modes above is actually present. They call for different remedies, and an audit that identifies them takes far less effort than a rebuild undertaken on the assumption that everything is wrong. Often a large fraction of the model is sound and a small number of templates are doing the damage.

Getting a Second Opinion

PI Asset Framework work is specialised enough that most Australian sites do not have a resident expert, and general IT integrators are usually meeting AF for the first time on your project. The skills involved sit across process engineering and data modelling, which is an unusual combination and not one that hiring reliably solves.

Our operational technology and plant data capability covers PI System and Asset Framework design alongside the AVEVA Ampla, System Platform and Citect environments these sites tend to run, delivered from Brisbane to resources and industrial operations across Queensland and nationally.

If your AF hierarchy no longer matches the plant, or nobody is quite sure who owns it, that is worth an hour of someone's attention before it becomes a rebuild. A short scoping conversation is usually enough to tell whether you are looking at an audit, a re-template, or a naming problem wearing an AF costume. Get in touch and we can work out which one it is.

Related Reading:

• Getting Historian Data Into Power BI - How to report on PI and SCADA historian data without building a slow second historian
• When SCADA, Historian and ERP Disagree - Why production figures diverge across systems and how a reconciliation layer fixes it
• Ampla Delay Accounting: A Practical Guide - Reason code trees, downtime capture and loss models in AVEVA Ampla
• What Ampla Support Should Actually Cover - Scoping ongoing support, maintenance and improvement for Ampla sites

Sources: Technical detail on element templates, attribute templates, substitution parameters, attribute traits, analysis templates and event frames from AVEVA PI System documentation and the OSIsoft "Building PI System Assets and Analytics with PI AF" course material. Equipment hierarchy concepts from the ISA-95 standard (International Society of Automation).