ISA-5.1 Tag Naming vs. Explicit OPC UA Modelling

Companion to TL;DR — OPC UA Part 17: Alias Names. Part 17 Aliases are the technical bridge between the two worlds described here.

Sections 1 and 2 are neutral background. Sections 3 to 6 are an engineering opinion — Sterfive's position, not a specification summary.

What ISA-5.1 Actually Is

ISA-5.1 is the roughly fifty-year-old convention that produced every TI101, FIT-101A, and PIC-301 painted on a P&ID in the process industries. A tag is a compressed record, not a name:

FIT - 101 A
│││   │││ │
│││   │││ └── Redundancy suffix   (A/B/C = parallel instruments; -1/-2 = sub-elements)
│││   └────── Loop number         (area-encoded: 101 = loop 1 in area 1; 2034 = loop 34 in area 20)
││└────────── Function: Transmitter
│└─────────── Function: Indicating
└──────────── Measured variable: Flow

Worked examples:

The genius of ISA-5.1: a trained engineer reads LSH-201 and instantly knows it is a high-level trip in area 2, with no database lookup. The whole plant speaks one dense language, and it has worked across vendors, decades, and continents.

What "Explicit Modelling" Means in OPC UA

OPC UA best practice — and every serious companion specification (Machinery, Machine Vision, PA-DIM) — pushes the opposite philosophy: put the semantics in the model, not in the string. The same flow transmitter becomes:

Objects/
  Reactor1/
    FeedFlow            ← BrowseName: human-readable, no cryptic code needed
      Value             ← DataType: Float
      EngineeringUnits  ← EUInformation: "m³/h"        (Part 8 / Part 5)
      EURange           ← 0 … 250
      HasTypeDefinition → AnalogSensorType             (companion-spec type)
      HasComponent      → Sensor, Transmitter …        (explicit structure via References)

Everything ISA-5.1 packs into FIT-101 is here too — but each fact lives in its own attribute, type, or reference, machine-readable without parsing:

The Dilemma

The issue is real and it is not "legacy versus modern". It is a genuine trade-off between two correct but opposing design principles:

An ISA-5.1 tag is a semantic descriptor masquerading as an identifier.

That single sentence is the whole problem. Good identifiers should be opaque and stable. ISA-5.1 tags are neither:

• They are overloaded. FIT-101A encodes five independent facts (variable, two functions, location, redundancy) in one string. That is a database row with no schema — parseable only by a human who knows the convention, and the convention drifts plant to plant.
• They are unstable by construction. Swap a transmitter for a controller and the "name" must change (FIT → FIC) — because the name is the function. An identifier that changes when the thing's role changes is, by definition, a bad identifier. Part 17 even bakes this in: a rename is delete plus re-add, which mints a new NodeId.
• They do not survive machines. A historian, an MES, or an AI agent cannot reliably parse LSH-201 into {level, switch, high, area 2} without an out-of-band decoder ring — and the moment two sites disagree on the convention, the parse silently produces garbage. That is exactly the class of problem OPC UA was invented to kill.

flowchart LR
    subgraph isa["🏷️ ISA-5.1 tag — 'LSH-201'"]
        direction TB
        P1["✅ Compact and universal"]
        P2["✅ Human-instant to decode"]
        P3["✅ 50 years of tooling and P&IDs"]
        N1["❌ Semantics locked in a string"]
        N2["❌ Name changes when function changes"]
        N3["❌ Not machine-parseable across sites"]
        P1 ~~~ P2 ~~~ P3 ~~~ N1 ~~~ N2 ~~~ N3
    end

    subgraph ua["🧩 Explicit OPC UA model"]
        direction TB
        Q1["✅ Machine-readable, no parsing"]
        Q2["✅ Typed and self-describing"]
        Q3["✅ Stable opaque NodeId"]
        M1["❌ Verbose — not radio-friendly"]
        M2["❌ Millions of ISA tags in brownfield"]
        M3["❌ Operators think in tags, not paths"]
        Q1 ~~~ Q2 ~~~ Q3 ~~~ M1 ~~~ M2 ~~~ M3
    end

    isa <-. "the tension" .-> ua

    style isa fill:#6a040f,color:#fff
    style ua fill:#2d6a4f,color:#fff

Neither side is wrong — which is what makes it a dilemma rather than a mistake. You cannot tell a plant with 200,000 ISA tags in its DCS, historian, work orders, and operators' heads to "just model it explicitly". And you cannot tell a fleet-scale analytics platform to parse cryptic strings it cannot trust.

The Resolution — This Is Exactly What Part 17 Is For

Here is the punchline: you do not have to choose. Part 17 dissolves the dilemma instead of resolving it.

• Model explicitly — the address space is typed, self-describing, machine-readable. The NodeId is opaque and stable. This is what the machines consume.
• Expose the ISA tag as an Alias — publish LSH-201 under TagVariables, with AliasFor pointing at the explicit node. This is what the humans and legacy tools consume.
• A client calls FindAlias("LSH-201") and gets back the ExpandedNodeId of a fully modelled, self-describing node — the human name resolves to the machine truth.

flowchart LR
    H["👷 Human / legacy DCS<br/>knows 'LSH-201'"] -->|FindAlias| AL["🏷️ Alias 'LSH-201'"]
    AL -->|AliasFor| M["🌡️ Reactor2/HighLevelTrip<br/>typed · units · range · references"]
    AI["🤖 Analytics / AI agent"] -->|Browse types & attributes| M
    style AL fill:#6a040f,color:#fff
    style M fill:#2d6a4f,color:#fff

The alias becomes the stable human contract; the model carries the machine semantics. When you swap the transmitter and the ISA tag "should" change, you add a new alias and retire the old one — the model node and its NodeId never move. The instability of ISA naming is quarantined at the alias layer, where it belongs.

Our Take — Where the Industry Should Head

Push the semantics out of the identifier and into the model — but keep the identifier as an alias, forever.

Concretely, for anyone building or modernising an OPC UA system:

1. Never make the ISA tag the BrowseName or NodeId of the real node. The moment you do, you have re-imported the overloading problem into OPC UA and gained nothing. Model the node properly; the ISA tag is metadata, not identity.
2. Always publish the ISA tags as Part 17 aliases — TagVariables for points, Topics for PubSub datasets. This is the cheapest possible bridge to fifty years of brownfield reality, operators, and P&IDs. It costs a folder of alias objects and buys universal backward compatibility.
3. Let the GDS aggregate them (Annex C) so FindAlias("FIT-101") works plant-wide from one endpoint, with redundancy and failover for free — the exact thing ISA-5.1's A/B suffix was hand-rolling.
4. Treat the identifier as opaque going forward. New systems should stop encoding meaning into strings at all. A NodeId should mean nothing; the model should mean everything. ISA-5.1 becomes a human-facing view, not the source of truth.

The 20th-century constraint — a tag had to be short enough to paint on a pipe and decode in your head, because there was no machine to ask — is gone. We now have a machine to ask. So:

• Short term (brownfield): explicit model underneath, ISA aliases on top. Coexistence, not migration. Achievable today with Part 17.
• Long term (greenfield, digital twin, AI-native): semantics live entirely in typed, companion-spec-conformant models; identifiers are opaque and stable; human-readable names (ISA or otherwise) are aliases and display metadata layered on top, swappable per site or per language without touching the truth.

The dilemma only exists if you insist a tag be both the name a human shouts over a radio and the schema a machine reasons over. Part 17's quiet contribution is letting you stop insisting on that.

One-Line Summary

ISA-5.1 crammed a database into a string because it had to. OPC UA gives every field its own home so machines can read it. The right architecture keeps both — the explicit model as the source of truth, the ISA tag as a Part 17 alias — so nobody has to choose between the operator's muscle memory and the machine's need for meaning.

Background on ISA-5.1 instrument identification per ANSI/ISA-5.1, Instrumentation Symbols and Identification. For the specification mechanics, see TL;DR — OPC UA Part 17: Alias Names.