PI Asset Framework Templates That Last

PI Asset Framework templates turn a historian's flat list of cryptic tag names into a model of the plant: pumps, mills, tanks and conveyors with named attributes. AF lasts when element templates are built first, tags resolve through substitution parameters, the hierarchy stays shallow and one named person owns changes. Skip those rules and the model has to be rebuilt within a few years.

Why do PI historian tags need an asset model?

Open the tag list on a mature processing plant and you may find tens of thousands of points with names like 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.

A historian is built this way on purpose. 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.

That works while the people who configured the tags are still on site. It stops working when 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 arrives two years later. This guide covers the difference between an AF model that ages well and one that has to be rebuilt.

What is PI Asset Framework?

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 stays where it is. 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 change is what makes everything downstream possible. A Power BI report can ask for Feed Flow across every flotation cell without a person 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 dressed up as a tree.

What are the parts of a PI AF template?

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

• Element: an asset, such as a pump, mill, conveyor, tank, area or plant. Elements nest inside each other to form the hierarchy.
• Attribute: something about that asset. It might read live from a tag, hold a static value like design capacity, or calculate from other attributes.
• Element template: 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.
• Attribute template: the definition of one attribute inside an element template, including where its value comes from. This is where the design works or fails.
• Inherited templates: one template derived 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.
• Attribute traits: characteristic information about a parent attribute. AVEVA's documentation describes traits covering limits, forecast values, geolocation, reason codes, asset health and analysis start triggers, set as fixed values or through a data reference. Traits keep a limit attached to the measurement it constrains, instead of a loose attribute called Pressure_HiHi.
• Analyses: calculations that run against elements. Defined on the template, an analysis applies to every element built from it, which AVEVA's material frames as managing calculations in a standardised and consistent manner.
• Event frames: a period of time rather than an instant, 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 or a trip all fit.

How do substitution parameters work?

Attribute templates succeed or fail on substitution parameters. Rather than hardcoding a tag name, you write a pattern. AVEVA's training material gives the example %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.

1. 1Element TemplateDefine Pump once, with its attributes
2. 2Substitution Parameters%Element% resolves the tag per asset
3. 3Elements CreatedForty pumps inherit the same shape
4. 4Analyses InheritOne calculation edit reaches all of them
5. 5Event FramesDowntime recorded with asset context attached

Why do PI AF hierarchies rot?

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

Across our consultants' careers in OSIsoft PI, AVEVA Ampla, AVEVA System Platform and Citect on Australian industrial sites, the same six failure modes 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 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 instead of 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. The element now has a private relationship with a tag the template knows nothing about. Multiply by a few thousand and the template is decorative.

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

One enormous template. A single Equipment template with fifty attributes, most empty for most assets, because it had to cover pumps, conveyors and tanks at once. Every query copes 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 self-describing model needs a glossary.

Analyses written per element. A calculation is configured 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 finds it means editing hundreds of elements one by one, with no way to confirm they all ended up the same.

	Built Element by Element	Built Template First	Impact
Adding new assets	Configure each one by hand	Create from template, tags resolve themselves	Repeatable
Changing a calculation	Edit every affected element	Edit the analysis template once	One edit
Relocating a unit	Hardcoded references break	Element moves, attributes follow	Survives change
Attribute coverage	One template, many empty fields	Base template plus derived templates	No dead fields
Finding a measurement	Three names across three areas	One attribute name everywhere	Queryable
Handover to a new engineer	Tribal knowledge required	Model describes itself	Transferable

What PI AF template design rules survive a plant change?

These rules are unglamorous and they hold up.

1. Template first, always. If an element has an attribute its template does not define, treat it as a defect, even when it works today. Configuring directly on elements produces every other problem on this list. Keep the rule under deadline pressure, because that is exactly when it gets broken.
2. Use substitution parameters so elements resolve their own tags. The attribute template describes the pattern and the element supplies the identity. Done properly, creating an asset is one operation and the data reference follows. Done badly, every asset is a manual job with its own chance of a typo.
3. Keep the hierarchy shallow. Every level you add is a level that queries traverse, displays step through and people get lost in. If a level exists only because it exists on a drawing, it probably does not need to be an AF level.
4. Separate the asset model from reporting rollups. The asset model describes physical reality. Reporting structures grouped by crew, product, business unit or last quarter's finance request change far more often than the plant. Keep reporting groupings as their own structure referencing the asset model, so the volatile part can move without disturbing the stable part.
5. Name attributes for what they measure. The element already supplies location. An attribute called Cell3FeedFlow on Cell 3 says the same thing twice and breaks the moment the template is reused. Call it Feed Flow and let the path supply the rest.
6. Decide who owns the model before you build it. The owner approves changes afterwards and says no when someone wants a one-off attribute on a single element. A model without an owner accumulates exceptions until the exceptions are the model.

Why is tag naming the precondition for AF templates?

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 brings back the original problem one element at a time.

AF amplifies whatever discipline exists in the naming underneath it. Given a consistent convention, the asset model builds almost mechanically. Given inconsistency, AF copies the mess into a structure that is harder to fix. Our guide to OT tag naming and data standards covers how to set that convention.

This is why a sound AF engagement often starts with a naming audit before 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 holds the role today. The same discipline makes SCADA, historian and ERP production figures reconcile instead of diverging.

How should AF event frames work with Ampla delay accounting?

Event frames are where AF 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 designed once applies across every asset of that type.

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

Decide which system is authoritative before either is extended, instead of discovering it 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: what the feed was doing, what the power draw looked like, which upstream unit moved first. Keeping 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.

What does a good AF model make possible?

Almost everything a site wants to do with its process data depends on asset context existing somewhere.

Reporting. A Power BI report built against raw tags encodes tag names into the report, so it 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. Our guide to getting historian data into Power BI covers how to do that without building a second historian.

Analytics and AI. Assistants that answer questions about plant performance in plain English are getting attention, and the demonstrations are impressive. What decides whether one works on your site is rarely the language model. 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 what AF holds. Without it, the assistant is guessing from tag names nobody could read in the first place.

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

Who should own the PI AF model?

An AF hierarchy is never finished. Units are added, circuits rerouted, instruments replaced with different tag names, areas renamed after a restructure. Each change 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 taken out of service. People stop trusting it, go back to raw tags, and the investment is written off without anyone deciding to write it off.

Treat model maintenance as an ongoing responsibility with a named owner. That can be an internal engineer with the time and the mandate, or an outside party under a managed support arrangement covering change control, template revisions and keeping analyses honest as the plant changes. Leaving it unassigned and hoping the original builder notices does not work.

1. Weeks 1-2Audit and NamingInventory tags, assess naming consistency, agree the standard and hierarchy levels
2. Weeks 3-5Template DesignBase and derived element templates, attribute templates with substitution parameters, analyses on templates
3. Weeks 6-9Build and ValidateGenerate elements, validate resolution across areas, backfill analyses, reconcile against known figures
4. OngoingOwnership and Change ControlNamed owner, a process for plant changes, periodic review against the physical plant

Where should a PI AF project start?

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

What does your site have today?

• No AF model, inconsistent tag namingNaming standard and audit first
• AF exists but nobody owns itModel audit and ownership decision
• Templates exist, elements edited by handRe-template and rebase elements
• Model is sound, reporting is slowFix the reporting layer, not the model
• Downtime recorded in AF and AmplaSettle which system is authoritative

For a site with nothing in place, resist modelling 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 naming problems immediately, at a scale where fixing them is still cheap.

For a site with an existing model that has lost trust, first identify which of the six failure modes is present. They call for different remedies, and an audit takes far less effort than a rebuild based on the assumption that everything is wrong. Often most of the model is sound and a handful of templates are doing the damage.

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

How Solve8 can help

Our consultants and engineers design and audit PI System and Asset Framework models alongside the Ampla, System Platform and Citect environments these sites run, as part of our OT, mining and manufacturing data work. If your AF hierarchy no longer matches the plant, a short scoping conversation usually shows whether you need an audit, a re-template or a naming fix. Talk to us.

---

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).