Tag Naming: The OT Decision AI Depends On
The Cheapest Decision You Never Made
Walk into most Australian processing plants and ask what FIC_1023_PV measures. Someone will know. Ask what FT101.PV, Mill2_FeedRate and AI_4417 measure, and you will get three different people, two shrugs and a spreadsheet that has not been updated since the last upgrade. The plant runs fine. Operators read the screens, the historian records the trends, and the month closes. Nothing is broken, so nothing gets fixed.
Then someone asks the question that every board in the country is now asking: can we put AI over our operational data? And the answer, almost always, is not yet. Not because the models are not good enough. Because the data has no names a machine can reason about. The single decision that determines whether analytics, reporting and AI ever work on a plant is the one almost nobody makes deliberately: what you call things, and how consistently you call them that.
This article is written for control systems engineers, plant data leads, reliability engineers and the operations managers who are being asked to deliver an AI outcome on top of an estate that grew one project at a time. Having worked on PI System, AVEVA and Citect deployments for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms, across 18 years in industrial data, the finding is consistent: the biggest barrier to analytics is rarely the historian or the model. It is the taxonomy nobody owns.
What a Tag Name Is Actually Doing
A tag name is a contract. Every time an engineer writes a report, builds a dashboard, configures an alarm or trains a model, they are relying on the name to mean the same thing it meant last week and on the panel next door. When that contract holds, a query that says "sum the feed to all three mills" is a one line expression. When it does not, the same query becomes a research project: find every feed tag, confirm each one is mass flow and not volumetric, check the engineering units, exclude the two that were decommissioned, and hope the naming on Mill 3 followed the same logic as Mills 1 and 2, which it did not, because a different contractor commissioned it in a different year.
The cost of a weak convention is invisible until you try to do something at scale. One dashboard built by hand is fine. Forty dashboards, a Power BI model, an alarm rationalisation and a condition monitoring project all reading the same estate is where the absence of a standard turns into permanent, recurring engineering labour. Every new piece of work re-solves the same problem of what is called what.
What a Naming Standard Changes
| Metric | Ad hoc tags | Governed convention | Improvement |
|---|---|---|---|
| Find every mill feed tag | Manual search + tribal knowledge | One structured query | Repeatable |
| Add a new asset | Name it however the contractor likes | Follows the pattern by rule | Consistent |
| Build a Power BI model | Re-map tags by hand each time | Maps once, inherits structure | Reusable |
| Onboard an engineer | Months of learning local quirks | Reads the convention and works | Faster |
| Apply AI or analytics | Data prep dominates the project | Context already present | Lower risk |
The Standards That Already Exist
You do not have to invent a convention from nothing. Several international standards describe how to structure plant data, and the right move is to adopt and adapt one rather than argue about it in a workshop for six weeks.
ISA-95, published internationally as IEC 62264, defines the levels of a manufacturing enterprise from the sensor on the floor up to the business system, and it gives you a shared vocabulary for where a measurement lives and what it belongs to. It is the model that lets you say "this is a Level 2 process value on this equipment, rolling up to this production area" in a way another engineer and a reporting system both understand. We covered the practical side of this in our guide to mapping a plant to ISA-95 when there is no MES.
IEC 81346-1, updated in 2022, sets out structuring principles and reference designations: a formal method for giving every object in a system an unambiguous identifier that ties back to where it sits in the plant hierarchy. In power generation the same idea has a long history as KKS, the Kraftwerk-Kennzeichensystem, now carried forward as RDS-PP. The detail differs by sector, but the principle is the same: a name should encode what the thing is and where it belongs, by rule, so that the name alone tells you most of what you need to know.
For the instrument side, ISA-5.1 governs identification and symbols, so that an F is a flow measurement, a T is temperature and the function letters mean the same thing on every drawing. These are not academic. They are the accumulated agreement of the industries that have been doing this longest, and adopting one costs far less than the recurring tax of having none.
Anatomy of a Governed Tag
The Convention Is the Easy Part
Choosing a structure takes a fortnight. Making it stick takes governance, and that is where most efforts die. A standard that lives in a PDF on a shared drive is not a standard. It is a suggestion that the next capital project will ignore under schedule pressure, because the contractor has their own template and nobody with authority is checking.
A convention holds only when three things are true. The rule is written down and owned by a named person, not a committee. New work is checked against it before commissioning, as a gate, not a cleanup afterwards. And the existing estate is mapped to it over time rather than left as a permanent exception. The third point matters because a brownfield site will never be renamed wholesale. The PLCs, the loops and the operator habits are too entrenched to touch. What you can do is build a structured layer above the raw tags that carries the standard, which is exactly what an asset framework is for.
This is the real value of the asset model in a modern historian. Rather than renaming 40,000 points, you build a hierarchy that references them, applies consistent attribute names, and inherits structure from templates so that adding the fourth identical pump takes minutes and arrives correctly named. We wrote about building PI Asset Framework templates that survive a plant change because the template is what turns a one off naming effort into a standard that propagates itself.
Introducing a Standard Without Stopping the Plant
Why This Decides the AI Question
There is a popular idea that AI will sort out messy data for you, that a capable enough model can read any tag soup and work out what is going on. On operational data this is close to backwards. A language model can guess that Mill2_FeedRate is a feed rate. It cannot know that the number is in wet tonnes rather than dry, that it is measured after the scalping screen and not before, that it double counts recirculating load, or that the tag was repurposed in 2023 and the old meaning still appears in three reports. That context is not in the signal. It lives in people's heads, and a model has no access to it.
Analytics professionals across every sector report the same pattern: the preparation and cleaning of data is the single largest call on their time, well ahead of the modelling itself. Anaconda's State of Data Science surveys have found data preparation to be the dominant activity year after year. On a plant, that preparation is almost entirely the work of reconstructing context that a proper naming standard would have carried for free. Fix the names and the structure, and you are not just tidying up. You are removing the largest cost item from every future analytics and AI project at once.
This is why we argue that a resilient data foundation comes before model choice, not after. An AI agent reading operational data needs the tag context and a read-only boundary far more than it needs a particular model. The same discipline that makes a Power BI report trustworthy is what makes an AI answer trustworthy, because they are drinking from the same well. If that well is governed, both work. If it is not, neither does, no matter how good the tooling on top.
Where to Start on Your Site
The Cost of Carrying On
The reason this decision gets deferred is that the status quo has no line item. Nobody invoices the plant for a weak taxonomy. The cost shows up spread across every engineer who spends a day working out what a tag means, every dashboard that breaks when an asset is renamed, every analytics project that overruns because the first two months went on data prep, and every AI initiative that stalls at proof of concept because the data could not be trusted at scale.
Consider the shape of it for a single mid-sized processing plant. The figures below are illustrative, framing the recurring tax rather than claiming a measured result, but the pattern is real on any site without a governed standard.
The Recurring Tax of No Standard (illustrative)
None of this is a technology purchase. It is a governance decision wearing a technical hat, which is why it so often falls between the control systems team, who own the tags, and the business, who own the reporting, with nobody owning the standard that would connect them. On the boards we work with, this surfaces as a question about AI readiness, and we address it directly in our note on what Australian boards should ask before approving AI: the honest first answer is usually about data governance, not about models.
How to Actually Start
The mistake is to treat this as a rename project, scope the whole estate, cost it at a number nobody will approve, and shelve it. The better path is narrow and compounding. Pick one production area that matters for reporting. Model it properly in the historian asset framework using an adopted standard. Prove that a report or an analytics query over that area is now trivial where it used to be laborious. Then make the standard a commissioning gate so that no new work undoes the progress, and let the legacy estate come into the model area by area as projects touch it.
This is the same sequencing we use whether the end goal is production reconciliation, where SCADA, the historian and the ERP need to agree on tonnes, or alarm management, where rationalisation depends on historian evidence. In every case the naming and structure come first, because everything downstream inherits from them. If you are weighing a reporting or AI programme over operational data and are not sure the foundation will hold, that is the conversation worth having before the tooling decision, and it is the kind of scoping work an Australian AI consultancy exists to do.
Common Questions
What is the best tag naming standard for an Australian plant?
There is no single best standard, but the strongest starting point is ISA-95 (IEC 62264) for the equipment and area hierarchy, combined with a reference designation scheme such as IEC 81346 and ISA-5.1 for instrument identification. Adopt and adapt an established standard rather than inventing one, because the value is in consistency and the accumulated industry agreement, not in novelty.
Do we have to rename all our existing tags?
No, and on a brownfield site you almost never should. Renaming live PLC and SCADA points carries real operational risk and disrupts operator habits. The practical approach is to build a structured layer above the raw tags in the historian asset framework, which references the existing points, applies consistent attribute names, and carries the standard without touching the control system.
Can AI just work out what our tags mean?
Not reliably. A model can guess a tag's purpose from its name, but it cannot know the measurement context that is not in the signal: the engineering units, where in the process it sits, whether it double counts, or whether the tag was repurposed years ago. That context has to be supplied by a governed data structure, which is why naming and the asset model come before any AI project rather than after.
Who should own the tag naming standard?
A named individual with authority over both new capital work and the historian, not a committee. The standard holds only when someone can gate a commissioning handover against it and is accountable for the existing estate being mapped over time. Ownership falling between the control systems team and the reporting function is the most common reason a standard exists on paper but not in practice.
How long before a naming standard pays off?
The first payoff comes as soon as one production area is modelled properly, usually within weeks, when a report or query over that area becomes trivial. The compounding benefit builds over months as new projects commission against the standard and the legacy estate is referenced into the model, removing data preparation effort from every future analytics and AI initiative.
Related Reading
- ISA-95 on a plant with no MES: what Level 3 is actually holding
- PI Asset Framework templates that survive a plant change
- When SCADA and your ERP disagree on tonnes
- Getting historian data into Power BI without a second historian
- What Australian boards should ask before approving AI
- AI for Australian manufacturers and industrial operations