Every fault detection and diagnostics (FDD) platform pitch sounds the same: point it at the BMS, and it finds the faults. In practice, an Australian portfolio's BMS point database is almost never clean enough for that promise to hold on day one. The analytics only ever perform as well as the metadata underneath them, and metadata is the part nobody budgets for.
The Point-Naming Problem, Concretely
A ten-building Australian portfolio assembled over fifteen years typically has BMS points named by at least three different integrators, none of whom followed the same convention. "AHU3_SAT" on one floor might mean the same thing as "L12-AH-03-DAT" on another. A human engineer can resolve this by inspection; an analytics model trying to generalise a fault signature — say, a sticking economiser damper — across the portfolio cannot, unless every equivalent point resolves to the same semantic meaning regardless of the label a particular integrator chose a decade ago.
Haystack and Brick: Two Ways to Solve the Same Problem
Project Haystack solves this by attaching a set of descriptive tags to each point — chilled, water, valve, cmd, ahu — that together describe its function, independent of the raw point name. Brick Schema takes a more formal approach, defining a class hierarchy (Chilled_Water_Valve_Command is a subclass of Valve_Command) plus explicit relationships between equipment (a VAV "feeds" a room). Both achieve the same outcome: point meaning becomes machine-readable rather than locked inside a human-readable label a contractor invented on-site. Which one to specify usually comes down to what the chosen analytics platform natively ingests — checking this before the point-naming convention is written into the ELV specification saves a costly re-mapping exercise later.
- Mandate a tagging schema (Haystack or Brick) in the ELV/BMS specification, not left to the integrator's discretion at commissioning.
- Set trend intervals per point class — 5-15 minutes for slow zone temperature points, 1-minute or change-of-value for fast points like valve position or fan run status that fault models actually need to see transients on.
- Require a validation step at handover where sample points are queried back through the tagging schema to confirm they resolve correctly, not just that tags exist.
- Specify a historian architecture (time-series database, not just BMS internal trend logs) if the portfolio intends to run multi-year degradation analysis for capital planning.
Design takeaway: Budget the data audit and tagging remediation as a distinct line item before selecting an analytics platform. On almost every Australian retrofit we've reviewed, this — not the software licence — is what determines whether the platform delivers real findings in month one or spends its first year fighting bad metadata.
From Fault Alerts to Capital Planning
Once the metadata layer is trustworthy, the same trend data that flags a sticking valve can feed longer-horizon asset decisions: chiller efficiency degradation curves that inform replacement timing, comparative benchmarking of like-for-like plant across a portfolio to prioritise capital spend, and evidence-based negotiation with facilities contractors over maintenance response times. This is the genuine payoff of building analytics — not just fewer nuisance alarms, but a portfolio owner able to argue a capital replacement business case from measured degradation rather than an equipment age assumption.
Frequently Asked Questions
What's the difference between Project Haystack and Brick Schema?
Haystack applies a flat set of descriptive tags to each point (e.g. chilled, water, valve, cmd); Brick uses a formal class hierarchy and relationship model (e.g. a VAV 'feeds' a Zone). Both solve the same underlying problem — making point meaning machine-readable — and the right choice usually comes down to what the analytics platform being procured natively supports.
What trend interval should Australian BMS points be logged at?
It should vary by point class, not be a single blanket setting. Slow-moving points like zone temperature can trend at 5-15 minute intervals; fast-moving points feeding fault detection, like valve position or fan status, need 1-minute or change-of-value trending or the analytics platform will miss the transient behaviour that signals an early-stage fault.
Can analytics be added to an existing BMS without re-tagging every point?
Yes, but expect the first phase of any analytics engagement to be a data audit and remediation exercise. Most existing Australian BMS databases have inconsistent naming left over from multiple contractors, and cleaning that up is nearly always the largest line item in getting an analytics platform to actually deliver findings, not the software licence itself.