Technology · Semantic modelling with Brick Schema
Semantic modelling with Brick Schema
A building management system can have thousands of points with names like JK057_02_019A_J90_HF03_BPA004. The name makes sense to someone who knows the system. To everyone else, and to any piece of software, it is a string.
The semantic model is the layer that translates. It describes what each point measures, where it sits and what it belongs to, in a way both people and machines can work with.
Without the model a database is just a thousand numbers. With it, what the numbers mean is explained.
01What Brick Schema is
Brick Schema is an open ontology for building data. An ontology is an agreed vocabulary: a list of what kinds of things exist in a building, and how they can be connected.
It is expressed in RDF, the same technology used to describe knowledge on the web, so a Brick model is a file that software can read and query.
Brick came out of a research collaboration and was first described in a paper in 2016. The University of Southern Denmark was among the original institutions. Today it is maintained by the Brick Consortium, a non-profit whose members include both universities and major vendors in the industry, among them Carrier, Johnson Controls, Schneider Electric and Siemens.
Brick is published under a BSD licence and is free to use. The most recent stable version is 1.4.4 from May 2025, and version 1.5 exists as a release candidate.
02The building as things and relations
The model consists of two kinds of statement. One is what a thing is. The other is how two things are connected.
Every statement has three parts: what it is about, which connection is meant, and what it points to. That is called a triple, and it is the only building block in the model. A complete model contains many of them.
Tap for full size
The things fall into three main groups: equipment, meaning air handling units, pumps, valves and meters, points, meaning the places where a value can be read or set, and locations, meaning buildings, storeys, rooms and zones.
The relations are few and recurring. The most important are:
- hasPoint, which ties a point to the equipment or the place it belongs to
- feeds, which says that something serves something else, for example that an air handling unit serves a zone
- hasPart, which says that something is part of something larger
- hasLocation, which places equipment and points in the building
Every relation has an inverse, so the model can be read from either end. That is what makes it possible to ask both what serves a room, and which rooms a unit serves.
The result is not a drawing and not a table, but a network. How it works shows the same thing as an illustration.
03The point is the centre of it
The point is where the model meets reality. Brick divides points into six types, and the difference between them matters more than it looks:
- Sensor, a measured value: the room temperature is 21.4 degrees
- Setpoint, a desired value: the room should be 21 degrees
- Command, an order to the system: open the valve to 40 per cent
- Status, a state: the pump is running
- Alarm, a message that something is wrong
- Parameter, a setting that rarely changes
The distinction means an analysis can compare what was measured with what was wanted, without guessing at what a name means. Without the type, a temperature and a setpoint are just two numbers that look alike.
Every point also carries its unit. Brick uses QUDT, an established dictionary of units of measurement, so a degree Celsius means the same thing in every model.
A number without a unit cannot be compared to anything. The unit is not a detail.
04References out of the model
The model describes the building but holds no data. Instead it points out to the places where data and geometry live. Brick calls these external references, and three of them matter in operation.
A BACnet reference says where the point sits in the building management system: the object's identifier, name and type. It is the bridge from the description to what is actually read.
A time-series reference says where the history for the point is stored, with an id and an indication of the database. Brick deliberately does not dictate which database that should be.
An IFC reference says which room in the building model the zone corresponds to, using the room's globally unique id. That is the link that lets a measurement be shown in the place in the building where it belongs.
Tap for full size
The references came into Brick with version 1.3 in 2022 and are the reason the model can be a layer in its own right rather than yet another copy of the data. IFC and building models covers the other end of that line.
A reference says the point ought to have data. It does not guarantee that the data exists.
05The model can be queried and checked
The advantage of describing the building in RDF is that the model can be queried. With SPARQL, the query language for RDF, you can ask questions such as: find every room served by an air handling unit, and give me their temperature sensors and setpoints.
The question is written in the concepts of the model, not in the building's point names. That is the whole point.
When two buildings are described the same way, the same analysis can run on both.
The model can also be checked. With version 1.3 Brick moved to SHACL, a language for describing rules for a graph, and rule sets ship with the ontology itself. A model can therefore be validated automatically, so errors are found before the analyses are built on top.
Open tools exist for both, among them a Python library from the Brick project itself and BuildingMOTIF from the American laboratory NREL, which works with templates to make model building less hand-held.
06Brick, RealEstateCore, Haystack and ASHRAE
Brick does not stand alone, and the three neighbours are worth knowing, because they are often mentioned in the same sentence.
RealEstateCore
RealEstateCore comes from the property industry and describes buildings, areas, tenancies and use. Brick and RealEstateCore were harmonised from 2022 with a clear division of labour: equipment and points from Brick, places and business concepts from RealEstateCore. From Brick 1.4 Brick's own location classes are deprecated in favour of RealEstateCore's, and the two ship in the same file. So they are not competitors to choose between.
Project Haystack
Haystack comes from the building automation world and rests on tags placed on points in the system itself rather than on a class hierarchy in a separate model. Haystack 5, announced in 2025, introduces a proper schema language and export to RDF, which brings the two worlds closer together.
ASHRAE 223P
ASHRAE 223P is a proposed standard for a semantic data model for building automation, describing physics and topology in more detail than Brick. It has been developed alongside Brick and Haystack, but it has not been published yet, and no date has been set.
07What you meet in practice
A Brick model rarely appears by itself. It is built from the building management system's point list, from spreadsheets or from an existing Haystack model, and that work is heavier than it sounds.
The reason is familiar to anyone who has seen a point list: the naming follows a convention that is rarely written down, and a point name often carries information about the system, the location and the function all at once. It has to be read, not looked up.
AI can help suggest what type a point is, and the research in the field shows promising accuracy. But a suggested model is not a finished model. What we see go wrong recurs:
- points typed wrongly because the name contains something that looks like a type, for example a binary contact that becomes a CO2 sensor
- missing units, so the numbers cannot be compared or converted
- references that promise data which is not in the database
- missing relations between point and equipment, so a point hangs loose in the model
Quality assurance is therefore not an extra step in a setup. It is part of it. The model is validated, and what cannot be validated is reported as a finding instead of being quietly corrected.
08Why CX2 uses Brick
The choice of Brick rests on three things.
It is open and independent of any vendor. The model is a file the building owner owns, in a format with an open licence and a consortium behind it. It can be read without CX2.
It makes analyses portable. When buildings are described the same way, an analysis written in one place can run in another. That is the precondition for a library of operational analyses to make any sense at all.
It can be checked. A model that can be validated by machine can also be handed over and received with a report instead of a declaration of trust.
Brick is no longer unknown to the vendors. Several building management systems can now put Brick tags on points, among them Niagara since version 4.14 and Schneider's EcoStruxure Building Operation. The difference lies in what comes out: the support is mostly tagging inside the vendor's own system, and a documented export of a complete model as RDF is not widespread.
Do you have a technical question?
Book a 45-minute meeting, or write to us.