What is Brick Schema and why is it used in smart buildings?

Building management systems are full of point names like "B2_AHU1_SAT". An engineer can usually guess what that one means. Software cannot, and that gap is what Brick was built to close.

Brick is an open-source ontology, meaning a formally defined vocabulary of concepts and relationships, for describing the equipment, spaces and data points in a building and how they relate to one another. It lets software understand what a data point represents and where it sits in the building, without a person interpreting cryptic names by hand.

The payoff comes from repetition. Almost every analytics, fault-detection or energy application needs the same context: which sensor belongs to which equipment, and which equipment serves which space. Captured once, in a standard form, that context lets applications be reused across buildings instead of being reconfigured for each.

How Brick describes a building

Brick's documentation describes a building model as a directed, labelled graph, represented with the W3C's RDF data model, in which the nodes are entities and the edges are relationships. Entities can be physical, such as an air-handling unit, a meter or a room; virtual, such as data points for a temperature sensor reading or a damper position command; or logical, such as an HVAC zone. Classes give entities their type and are organised in a hierarchy, so that a supply-air temperature sensor is understood to be a kind of temperature sensor.

Relationships connect the entities, and Brick groups them by perspective: composition (hasPart), topology (feeds, hasLocation) and telemetry (hasPoint, isPointOf). The documentation also describes control relationships, such as controls and isControlledBy, which it documents for the forthcoming version 1.5; the latest release listed on Brick's resources page is 1.4.4 (May 2025). Confirm which version a supplier works to.

A small fragment, written in plain language:

From these five statements, software can answer "which sensors tell me about the air delivered to room 2.17?" without knowing anyone's naming convention.

Brick borrows its idea of tags from Project Haystack, and since version 1.4.0 (April 2024) the Brick download has also contained the RealEstateCore ontology in the same file.

What owners gain

Portability is the obvious gain: an analytics rule written against Brick classes and relationships can run on any building with a correct Brick model. Less obvious is control. The model is an openly documented artefact the owner can hold, a Vendor Agnostic record of context that no single supplier's software can lock away. And when Brick is the specified deliverable, different integrators are working to the same target.

What it does not do

A Brick model does not collect data, guarantee its quality or make two products interoperate automatically. It describes context; the readings still come from the building management system (BMS) and meters through their own interfaces. Nor does applying Brick labels to a handful of points make a building's information complete.

Keeping a model useful

A Brick model is a living asset, and it stays useful only with some discipline. The first decision is the Brick version, with a policy for upgrading it. Modelling can then start with the equipment, points and relationships the agreed applications need, and extend later. Validation has two halves, against Brick's rules and against the building itself, and a model nobody updates when equipment is replaced or spaces are re-planned soon describes a building that no longer exists. Model and data stay separate but linked: the model describes a point, while the time series of its values lives elsewhere, connected by an identifier.