Building Automation Services
Haystack, Brick & UDMI Data Modelling
A BMS point called AHU3_SAT_2 means nothing to an analytics platform, a digital twin, or the engineer who inherits the building in five years. It means nothing to the next contractor either, which is exactly why so many estates are effectively unreadable. Semantic modelling fixes that. It describes what each point is, what equipment it belongs to, where that equipment sits, and how it relates to everything else — in a published schema that any tool can read without a custom mapping exercise.
Talk to us about your point listWhich Schema Is Right for You
| Schema | When it fits |
|---|---|
| Project Haystack | The most widely adopted tagging convention in building automation, and well supported by commercial analytics tools. A good default for commercial estates where you want vendor choice in the analytics layer. |
| Brick Schema | A formal ontology with a stronger relationship model. Better where you need to reason over the graph — complex plant topology, research applications, or estates feeding a genuine digital twin. |
| Google Digital Buildings | Required where the client mandates it. The ontology used across Google's own estate, with a defined entity and field structure and strict validation. |
| UDMI | Not a tagging schema but a device management interface — how devices report telemetry, state and configuration to a cloud platform. Frequently used alongside Google Digital Buildings. |
What the Work Involves
Point Inventory and Normalisation
We extract the full point list from the BMS, deduplicate it, identify orphaned and unmapped points, and establish what is actually live versus what exists in configuration only. On most existing estates this stage alone changes the client's understanding of what they own.
Naming Convention Design
A written convention covering equipment, location, point type and instance, applied consistently across the estate. This is the part everyone skips and everyone later regrets. Without it, every subsequent contractor invents their own and the model degrades within two years.
Tagging and Model Construction
Points and equipment tagged to the chosen schema, with equipment relationships, spatial hierarchy and system topology represented properly. Feeds, references and containment modelled, not just flat tags.
Validation
The model is validated against the schema's own rules, and sense-checked against the physical plant. A model that validates but describes plant that does not exist is worse than no model.
UDMI Onboarding, Where Required
Device configuration, payload construction, pointset definition and validation against the UDMI specification, including state and telemetry reporting and the site model structure.
Remediation
Where an estate has been tagged badly or partially — which is common — we assess what is salvageable, correct it in place where we can, and rebuild where we cannot. We will tell you honestly which it is.
What You Receive
- Complete point inventory with live status and source device
- Written naming convention document
- Tag dictionary defining every tag used and its meaning in your estate
- The model itself, in the schema's native format
- Validation report against the schema specification
- Governance note — how to keep the model correct as the estate changes
- All of it is yours, in open formats. A data model held in a proprietary tool you cannot export from is not a data model, it is another lock-in.
Tell us about the building.
Send us the specification, the point list, or just a description of what is not working. You will get a reply from an engineer within one working day.