Consider a tag called PLANT2.U3.BRG.VIB.01.

To the engineer who configured it, this is perfectly readable: Plant 2, Unit 3, bearing vibration, first sensor. To everyone else in the organisation it is an opaque string. To a reporting tool it is a column header. To a machine-learning model it is a feature with no meaning at all.

Multiply that by forty thousand tags and you have described the central problem of most industrial data estates. The information needed to interpret the data exists, but it lives in people rather than in the system.

What breaks as a result

• Onboarding takes months. A new engineer cannot answer simple questions without someone to translate the tag list for them.
• Fleet comparison is impossible. If each site named its tags independently, asking the same question of twelve stations means twelve different queries.
• Dashboards do not travel. A display built for one unit has to be rebuilt for the next, because the references are hard-coded.
• Analytics generalise badly. A model trained on one unit’s tags learns that unit’s quirks and fails silently on the next.
• Everything depends on one person. The translation layer is a human being, and they take holidays.

What Asset Framework is actually for

The AVEVA PI Asset Framework is frequently described as an organisational layer, which undersells it. It is the mechanism by which tacit knowledge becomes explicit structure.

In a properly built AF model, PLANT2.U3.BRG.VIB.01 is not what anyone interacts with. Instead there is an element called Unit 3, built from a template that every generating unit shares, with an attribute called Bearing Vibration that resolves to the right tag for that unit. Ask for bearing vibration across all units and you get twelve answers that mean the same thing.

Templates are where the leverage is

The single highest-return decision in AF design is committing to templates rather than building elements individually.

With a template, a new compressor is onboarded by instantiating it and mapping its points — minutes of work. Every analysis defined on the template applies immediately. Every display built against the template works without modification. Without templates, each addition is a small bespoke project, and the model fragments until it is as inconsistent as the tag list it replaced.

Units of measure, defined once

An underrated benefit: enforcing engineering units in the model ends an entire category of argument. When one site records pressure in bar and another in psi, fleet comparison silently produces nonsense. Defining the unit at template level means the conversion happens once, in one place, correctly.

The test

A useful way to assess an AF model: can an engineer who has never seen your plant ask for a meaningful quantity across a class of assets, and get a correct answer, without knowing a single tag name?

If yes, the model is doing its job. If no, you have a hierarchy rather than a model — and everything you build on top of it will carry the gap. How we approach AF design.