BMS Point Naming, Haystack and Brick: The Data Layer Behind FDD

Every fault detection rule assumes it knows what it is looking at. A chilled water valve leak rule needs to know which BACnet object is the valve command, which is the supply air temperature, which is the air on coil, and that all three belong to the same air handling unit. Get that mapping wrong and the rule does not fail loudly. It fails quietly, firing constantly or never firing at all.

On one building you can fix this by hand. An engineer reads the BMS point list, works out what everything is, and maps it in an afternoon. On sixty buildings that approach strains. On six hundred it was never viable.

This is the data layer, and it is the least discussed part of building analytics. Most of the industry conversation is about algorithms. In practice the algorithms are the easy part. What decides whether fault detection and diagnostics works across a portfolio is whether the underlying data has been named, tagged, related and normalised well enough that one rule template runs unmodified on a thousand pieces of equipment.

Key takeaways

• Point naming and normalisation, not algorithms, are the limiting factor on whether FDD scales across a portfolio.
• Project Haystack tags describe points. Brick Schema describes relationships. Most rollouts need both, and tagging alone will not give you an equipment hierarchy.
• Missing equipment relationships create permanent false faults. A VAV with no parent AHU configured will report an airflow fault every night and never clear.
• The integration path sets a ceiling on data quality before normalisation begins. Native BACnet/IP is best; scheduled CSV export is a last resort.
• CIM's PEAK Platform normalises this automatically across a monitored portfolio of 600+ commercial buildings, using metadata prediction, equipment cloning and a structured commissioning workflow.

What raw BMS data actually looks like

Here is the problem in its natural state. A BACnet object name from a live site:

Readable once you know the convention. The equipment is ACU_L14_04, an air conditioning unit on level 14, unit 4. The metadata is fan flow. The delimiter is the full stop. The convention holds until some units carry a suffix and others do not, or level numbers lose their leading zero, or an equipment name contains a full stop of its own.

Other point naming conventions are worse. On one Johnson Controls Metasys site, device names carried no equipment reference at all, so there was nothing in the BACnet object name to parse. Equipment identity lived in a separate global search export and had to be joined back in. On another, power sub-meters began with any of TDB, MDB, MSSB or simply the name of the plant they served, the only consistent thread being a navigation path segment of EM.

None of this is anyone's fault. BMS point naming was designed for an engineer standing in front of a graphic, not for an analytics engine parsing ten thousand points across a portfolio. But it means the raw data arriving from a building management system is not a dataset. It is an archaeology problem.

Project Haystack vs Brick Schema: what each standard solves

Three efforts exist to fix semantic tagging in buildings. They are not competitors in the way vendors sometimes imply. They solve overlapping but different problems.

If you are a BMS contractor or RCx firm deciding what to ask for at handover, the practical answer today is Haystack tagging where the platform supports it, because you will actually get it, plus an explicit equipment relationship map, because tagging alone will not produce one.

Why equipment relationships decide whether rules work

Semantic tagging tells you a point is a supply air temperature sensor. It does not tell you that the AHU it belongs to serves forty VAV boxes on levels 9 to 12, or that the chiller upstream depends on a particular condenser water pump.

That relationship layer is where multi-system fault detection lives, and it is where most portfolio rollouts quietly break.

The clearest example is a VAV airflow fault. A VAV box showing zero airflow looks like a fault. It is only a fault if the air handling unit upstream is running. If the AHU is off, zero airflow at the terminal unit is correct behaviour.

So the rule template carries a precondition: check the parent AHU's supply fan status before evaluating the VAV. If the parent-child relationship has not been configured during commissioning, the rules engine has nothing to check. The rule then fires every night, through every unoccupied period, and cannot clear until the AHU restarts. One missing relationship produces a fault that is permanently true and permanently wrong.

Multiply that across a few hundred terminal units and you have manufactured exactly the BMS alarm fatigue the analytics platform was bought to eliminate. The team stops trusting alerts, stops reading them, and real faults go unactioned alongside the false ones.

Two things surprise people. The direction on pumps runs the way you might not expect: a chiller is the parent of its primary chilled water pump, because the fault you are trying to detect is a pump running without the plant it serves. And a single unit routinely has more than one parent. An AHU on a four-pipe system has both a chilled water and a hot water parent, and needs both configured.

What points does FDD actually need?

Normalisation is usually described in the abstract. In practice it resolves to a question a contractor can answer on site: for this equipment, which BMS points must be exposed and trended before analytics can run?

The specific list varies by equipment type, but it follows the same pattern every time. If you can answer these six categories for a piece of plant, most fault detection templates will run against it.

Note what is on the list and what is not. There is no exotic instrumentation. Nearly all of it is data the BMS already holds. The gap is almost always exposure and naming, not sensing.

Agree the point schedule with the BMS contractor before the project starts rather than after. The most expensive discovery in any analytics deployment is finding at commissioning that a critical point was never trended, never exposed, or does not physically exist. Retrofitting a sensor after the fact costs several times what specifying it up front would have. CIM issues a per-equipment point schedule to technical partners during onboarding, so the requirement is explicit before anyone mobilises to site.

BMS integration options: BACnet, API and CSV

How data physically reaches the platform sets a ceiling on everything downstream. There are four common integration paths and they are not equivalent.

Three qualification questions save more project time than anything else, and all three belong before hardware is committed.

Which flavour of BACnet is actually running? A system described as BACnet compatible is frequently MS/TP only. BACnet over IP can be read directly. BACnet MS/TP over RS-485 cannot, and must be routed to IP first, commonly through a Tridium JACE, a Johnson Controls SBH, a Contemporary Controls BASrouter or a Delta eBMGR. That is a BMS contractor change and usually a purchase order, which is exactly the kind of item that adds a month if it surfaces late.

Are BACnet device instance IDs and network numbers unique? Duplicates break device discovery. This bites hardest on sites extended by different contractors over the years, where two subnets can each carry a device 40100.

Does the BMS network span multiple IP subnets or VLANs? If so, BACnet broadcasts will not cross between them unaided. Either a BBMD is already configured, or the collector registers as a foreign device in an existing BBMD broadcast distribution table, or it sits on the same subnet as the devices it reads. Discovering this on install day is a wasted mobilisation.

Sites that run into genuine trouble share a profile: LON networks with no BACnet layer, MS/TP-only sites with no router and no appetite to add one, multi-subnet networks with no BBMD and no plan for one, and older controller generations never designed to expose data outward. None are fatal. All are far cheaper to handle at qualification than at installation. CIM's BMS integrations page lists the vendor platforms currently supported, including Trend, Tridium Niagara, Schneider Electric, Honeywell, Siemens, Johnson Controls, Distech Controls, Delta Controls, Alerton and Automated Logic.

How the PEAK Platform handles the data layer

Everything above is the general problem. This is how PEAK solves it, and why CIM's technical partners can commission sites themselves rather than waiting on the vendor.

Ingestion without a fixed dependency on one protocol. PEAK reads a site either through an on-site data collector on the BMS network, or by ingesting scheduled file exports where no live connection is possible. The same normalised model sits behind both, so the analytics do not change based on how the data arrived.

Metadata prediction rather than manual mapping. PEAK runs a model across the raw point list that proposes the correct normalised metadata from the combination of point name, identifier, device name and units. On a large site this removes most of the manual mapping effort. It is a first pass that a commissioning engineer reviews, not a black box, and the review step is what keeps it trustworthy.

Cloning for templated equipment. Terminal units are identical by design. Where every VAV on a floor shares the same identifier-to-point layout, PEAK copies the mapping from one unit to all the others in a single action. The judgement a person still has to apply is whether any units carry extra points the source lacks, duct heaters being the classic example.

Relationships as first-class configuration. Parent-child links are set on the equipment table, and every deployed rule that references upstream plant picks them up automatically. No rule-level configuration is required once the link exists, which is what stops the permanent false faults described earlier.

Rule templates that deploy against the normalised model, not the site. Because the metadata is standardised at commissioning, a template written once runs unmodified across the portfolio. That is the entire return on the data layer work, and it is why CIM can operate a shared template library across 600+ buildings rather than maintaining bespoke rules per site.

If you are a BMS contractor, RCx firm or building services consultancy looking at this as a service line rather than a tool, our guide to how engineering firms run RCx and MBCx on FDD covers the commercial model, and CIM's technical partner programme covers the training and platform access behind it.

Commissioning points at portfolio speed

Whatever platform you use, three habits change the order of magnitude on a large site.

Work the patterns, not the points. Most sites are internally consistent even when externally strange. If equipment names always precede a delimiter, one substring formula extracts every equipment name on the sheet. If equipment identity is missing from device names entirely but a device-to-equipment map can be exported from the BMS, an index match joins it back across thousands of rows. The skill is pattern recognition and spreadsheet work rather than building services engineering, which is worth knowing when you decide who to staff on it.

Check counts before you check content. Filtering for one VAV's damper position naming convention and confirming every other VAV has the equivalent takes minutes and catches omissions that would otherwise appear as silent analytics gaps months later.

Confirm the structure exists before you apply the mapping. Most failed commissioning submissions come down to two things: an equipment name used in the sheet that was never created on the platform, or a level and zone combination that does not exist. Both are trivial to check in advance and tedious to unpick afterwards.

How to tell whether your data layer is right

A data model is not correct because someone declares it complete. It is correct when it behaves correctly, and there are four observable tests.

Rules deploy without per-site modification. If templates need hand-tuning per building, normalisation is not done. That is the entire point of the exercise.

Faults clear as well as fire. A rule that is permanently true detects nothing. Stuck-in-fault conditions almost always trace to a missing relationship rather than a bad threshold.

Out-of-hours behaviour is quiet. A portfolio generating a wall of alerts every night at 6pm has a modelling problem, not an operational one.

Equipment counts reconcile. If the platform holds 180 VAVs and the mechanical schedule says 194, that is not a rounding error. It is fourteen zones nobody is monitoring.

This is where the data layer meets the thing that generates value. Detection is only worth something if the fault is real, and a fault is only real if the model underneath correctly describes the building. Every false positive traced to a missing relationship costs an engineer a trip to a plant room and costs the platform a little more of the team's trust. Getting the data layer right is not overhead before the interesting work starts. It is the difference between analytics a team acts on and analytics a team learns to ignore.

For what comes next once the data layer is sound: our analysis of the most common HVAC faults across 600+ monitored buildings covers what the rules actually find and what it costs, costing remedial works from FDD covers turning findings into scoped chargeable work. For sites adopting standardised sequences, ASHRAE Guideline 36 makes both point naming and expected behaviour considerably easier to normalise, and monitoring-based commissioning is where a well-modelled portfolio pays back.

Frequently asked questions

What is the difference between Project Haystack and Brick Schema?
Project Haystack is a tagging convention describing what individual data points are, using tag combinations such as discharge, air, temp and sensor. Brick Schema is an ontology describing classes of equipment and points and the relationships between them as a queryable graph. Haystack is faster to apply and more commonly found already implemented in the field; Brick is stronger at expressing how equipment connects to other equipment. They are complementary rather than mutually exclusive.

Do I need Haystack tagging for fault detection to work?
No. Haystack tags make commissioning faster and more reliable, but analytics platforms map raw BMS points to their own normalised metadata model regardless. Tagging reduces manual effort; it is not a prerequisite.

What is ASHRAE 223P and can I specify it?
ASHRAE 223P, Semantic Data Model for Analytics and Automation Applications in Buildings, is a proposed standard developed through the ASHRAE BACnet committee with input from Project Haystack and Brick. It remains in development and is not yet published, so it cannot be specified as a compliance requirement on a live project today, though it is the likely long-term direction for the industry.

Why do BMS point naming conventions matter if the platform normalises everything anyway?
Because normalisation is a mapping exercise, and consistent point naming is what allows thousands of points to be mapped by pattern rather than one at a time. A site with a consistent BACnet object naming convention commissions in a fraction of the time of one without, and is far less prone to silent omissions.

What BMS points does a contractor need to expose for FDD?
At minimum, for each unit: run state (status and enable), the controlled variable and its setpoint, actuator positions such as valve and damper, and where relevant flow or pressure, fault status and energy. The exact schedule varies by equipment type and should be agreed before the project starts.

What is the fastest way to integrate a BMS with an analytics platform?
Native BACnet/IP, where BACnet/IP traffic is visible from the collection point. BACnet MS/TP routed to IP is equivalent in quality once a BACnet router is in place, but adds procurement and contractor time. Vendor REST APIs are viable where BACnet cannot be exposed. Scheduled CSV export works but carries lower fidelity and greater lag, and should be a last resort.

Why does a VAV box show a permanent airflow fault?
Most often because the parent-child relationship between the VAV and its upstream air handling unit was never configured during commissioning. The rule cannot check whether the AHU is running, so zero airflow during unoccupied hours reads as a fault. The rule fires every night and cannot clear. Configuring the parent relationship resolves it.

What is a BBMD and when do I need one?
A BACnet Broadcast Management Device forwards BACnet broadcasts between IP subnets. You need one, or foreign device registration into an existing one, whenever the BMS network spans multiple subnets or VLANs and the data collector cannot sit on the same subnet as the devices it reads.