Why BAS Tag Names Don't Scale as an Ontology

The problem with tag-based semantics

Every building automation system encodes equipment relationships in point names. A Metasys system might call a supply air temperature sensor NAE-01/AHU-1.SA-T. A Tridium system might call the equivalent point HVAC/Floor3/AHU1/SupplyAirTemp. A Siemens system might call it B3_L3_AH01_SAT.

Each name is perfectly legible to the engineer who set it up. Each name is completely different. And each name embeds structural assumptions (which NAE, which floor, which AHU) in a flat string that no software can reliably parse without per-site custom rules.

This is fine when you operate one building. It falls apart when you try to operate ten.

What breaks

Normalization. To compare AHU performance across buildings, you need a common schema. “Supply air temperature” must mean the same thing whether the point is called SA-T, SupplyAirTemp, SAT, or Temp_SA. Tag-based approaches (SkySpark’s Haystack, Brick Schema) try to solve this by adding semantic tags to points. This helps, but it’s still a string-matching problem at the bottom — and someone has to apply those tags to every point, every time.

Hierarchy. The relationship “this sensor belongs to this AHU, which belongs to this floor, which belongs to this building” is implicit in the tag name. Extract it wrong, and your fleet analytics attribute one building’s faults to another. Tag hierarchies are conventions, not schemas — there’s no validation that NAE-01/AHU-1.SA-T actually refers to a real AHU called AHU-1 on a real NAE called NAE-01.

Ports and flows. A tag name tells you nothing about how equipment is physically connected. That AHU-1 has a supply air duct going to Zone-3 and a chilled water pipe coming from Chiller-1? The tag names don’t encode that. They can’t — they’re sensor-level identifiers, not plant-level topology.

What works better

A typed asset graph with explicit ports.

Instead of tagging a point with ahu + supply + air + temp and hoping that software can reconstruct the semantic meaning, model the AHU as a typed node with defined ports:

AHU-1:
  type: ahu
  ports:
    supply_air_out: air_port
    return_air_in: air_port
    chw_in: water_port
    chw_out: water_port
  sensors:
    - point: NAE-01/AHU-1.SA-T
      port: supply_air_out
      measurement: temperature

Now the relationships are explicit. The sensor is bound to a specific port on a specific piece of equipment. The port has a type. Connections between equipment are typed edges between ports — AHU-1.supply_air_out → Zone-3.supply_air_in is a flow edge, not a string convention.

The trade-off

Building the graph takes more upfront effort than slapping tags on points. For one building, tags win on speed. For a fleet, the graph wins on everything else — consistency, queryability, validation, and the ability to run physics-based diagnostics that depend on knowing the actual plant topology.

We’ve been building these graphs for every engagement, and the tooling gets faster with each one. The naming conventions from previous customers become patterns that the next customer’s ingestion can leverage. Tags are a one-building solution. Graphs compound across the portfolio.