EMAIL INTERVIEW –  Ken Sinclair, Gabe Fierro and Jason Koh

Gabe Fierro is a Ph.D. candidate in the Computer Science department at the University of California, Berkeley and one of the lead maintainers of the Brick project. He has been working in smart buildings and IoT for over 6 years with research spanning database design and implementation, semantic web and ontologies, large scale data management, and secure distributed monitoring and control systems.

Jason Koh is a Ph.D. candidate in Computer Science and Engineering at the University of California, San Diego. His work ranges from data mining and modeling to system design for data management for IoT, Smart Buildings, and sustainable society. He is now one of the lead maintainers of BRICK schema (brickschema.org), which is being actively adopted into the industry. He is also a recipient of CNI fellowship and several awards at BuildSys.

Sinclair:  What is Brick and why was it created?

Fierro & Koh:  Brick is an open-source effort to standardize metadata for the built environment, with an emphasis on buildings and the Internet of Things. Brick enables integrated, cross-vendor digital representations of equipment, points and assets in buildings and the relationships between them. Brick reduces the cost of deploying data-driven applications over many different buildings by giving applications the ability to automatically discover the data they need to operate.

The Brick effort began in 2016 when a group of computer science and building science researchers from UC Berkeley, UC San Diego, UC Los Angeles, Carnegie Mellon University, the University of Southern Denmark and IBM realized how much effort was being spent in adapting code to run on different buildings. Evaluating new analytics, models and control sequences on buildings required a lengthy, manual process of determining what data was available and how each data source was related to the assets and processes within a building.

For example, we might pull data from a building management system (BMS) for a point labeled "SODA1R410_ART," but this label has no structured information on what the point is, where it is located, and how it is connected to other pieces of equipment in some subsystem. After speaking to the building manager, we might learn how to break the name down:

• "SOD": an abbreviation of the building name
• "A1":  the name of an air handling unit
• "ART": indicates that the point is an air temperature sensor
• "R410": indicates that the sensor is located in Room 410.
  

We wanted a programmatically accessible and standardized data model that would enable the mass customization of data-driven analytics and control sequences in buildings. That effort became Brick.

Sinclair:  How does Brick compare to other building metadata efforts like IFC, Project Haystack and Linked Building Data?

Fierro & Koh:  There are a number of existing building metadata efforts for modeling different aspects of buildings at different phases of their lifecycle.

Building Information Models like IFC represent data for the design and construction phases of a building: this includes which spatial elements (rooms and storeys), physical elements (walls, beams and doors) and mechanical and electrical equipment are included in a building, as well as how these components should be assembled. The Brick data model is designed for use after construction: it contains many of the same assets, but models how the assets function together and why they are connected instead of precise construction-related parameters.

The Building Topology Ontology (BOT) developed by the Linked Building Data community group focuses on modeling 3D topological aspects of buildings such as zones, storeys and spaces. BOT and Brick are complementary to each other: because they are each built upon Semantic Web technology, it is easy to translate concepts between the two data models.

Project Haystack is a popular building metadata model that focuses on describing data and properties of points and equipment in buildings. In a Haystack model, things are classified by sets of associated tags. While this approach is easy to use and very flexible, it is difficult to standardize the use of tags across many buildings.

The Brick community has been collaborating with the Project Haystack community on establishing a translation between the two data models. This will allow users to take advantage of the simple tagging model provided by Haystack while being able to leverage the relationships and standard definitions provided by Brick.

Brick is designed to be complementary to other building metadata schemes, but with a focus on modeling the operational and functional aspects of buildings that are helpful for building data-driven applications. We hope to make Brick a "lingua franca" for helping to integrate the family of building metadata technologies.

Sinclair:  What are the design principles of Brick?

Fierro & Koh:  We have developed a set of metadata design principles that have influenced the development of Brick.

1. An effective metadata standard should represent the "things" in a building. Physical things like equipment and rooms, virtual things like points (sensors and setpoints), and logical things like zones.
2. An effective metadata standard should represent the “relationships” between things. It is important to know not just that two things are related, but also how they are related.
3. An effective metadata standard should provide an extensible classification scheme. Assets and resources in the data model should have explicit types with clear definitions.
4. An effective metadata standard should have rules encouraging portability and enforcing consistency. By "portability" we mean that the concepts and relationships in the metadata standard should be generalizable to different buildings, subsystems, processes and use cases. By "consistency" we mean that similar concepts are modeled in a similar way from building to building. Consistent use is crucial to the utility of a standard.
   

Sinclair:  How does Brick work?

Fierro & Koh: 

• A “Brick model” for a building is a digital representation of all of the resources, assets and relationships in a building. Brick can model five broad types of resources:
• equipment (including HVAC, lighting, electrical)
• points (including sensors, setpoints, commands and alarms)
• locations (including floors, rooms, zones)
• substances (including different kinds of liquids, solids and gases)
• quantities (including temperature and flow rate)
  

A Brick model contains the names and types of all of the assets and resources in a building: these are called entities. In Brick, well-defined types (also called “classes”) have full names and definitions: for example, the Brick class name for supply air temperature sensors is brick:Supply_Air_Temperature_Sensor. In order to include a supply air temperature sensor called “SODA1R410_ART” in a Brick model, we would insert a record stating that “SODA1R410_ART” has the type brick:Supply_Air_Temperature_Sensor. In this way, Brick enables the consistent classification of entities across different building models.

A Brick model doesn’t just contain the set of entities in a building, but also the relationships between them. Relationships are important because they describe how entities behave and relate to one another. Examples of relationships are:

• Sequence: which entities are upstream or downstream of other entities. These relationships model flows of air, water and electricity.
• Composition: which entities are made up of other entities. These relationships model complex equipment like air handling units and subsystems like chilled water loops as well as what spatial elements make up an HVAC or fire zone.
• Location: which entities are located in other entities.
• Function: why and how entities behave. These relationships model how equipment affects different substances, such as modulating water flow or regulating air temperature, but also the role of different points like sensors and setpoints.
  

This is far from a comprehensive introduction to Brick. We recommend exploring examples and reading documentation on the Brick website.

Sinclair:   How would I use Brick in the context of day-to-day building operations and management?

Fierro & Koh:  There are several levels of engagement with Brick in the context of building operations and management.

At minimum, Brick can offer a more structured naming scheme for assets and resources. Rather than encoding all of the information about a point in a single name (e.g. “SODA1R410_ART”), Brick lets each aspect of the behavior, function and location of a point or equipment get modeled separately. This can be done in tandem with whatever naming scheme currently exists in a building; it does not require replacing any technology.

At the next level of engagement, Brick can be used to model the relationships between the assets and resources in the building. This allows a Brick model to answer questions such as:

• What sensors and setpoints exist on the hot water loop for a given air handling unit?
• Which VAVs are responsible for conditioning the air for a given set of rooms?
• Which submeters correspond to which floors or subsystems?
• More generally, what are all the flows of air or water in the building?

A Brick model coupled with live and/or historical telemetry from a building is a powerful tool for implementing or executing data-driven analytics on a building. In our experience with Brick, we have developed analytics applications providing fault-detection and diagnosis, thermal and occupancy modeling, energy disaggregation, and energy consumption baselines. Because Brick gives applications the power to discover the data they need, existing applications can run on new buildings with little or no reconfiguration.

At higher levels of engagement, a Brick model can be incorporated into intelligent control sequences. Instead of hard-coding the point names of inputs and outputs in each control loop, a developer could create “generic” control loops that ask a Brick model what specific inputs and outputs are available or relevant before executing. This is not science fiction! Over the past two years, we have deployed and maintained an automated demand response platform that monitors and controls over 20 buildings using the same code base.

[an error occurred while processing this directive] Sinclair:  What does it mean that Brick is an open-source project?

Fierro & Koh:  At its core, Brick is a community-driven project. Brick is designed to be extensible to meet the needs of its users so that it can improve over time. We believe that releasing Brick under a permissive open-source license is the best way to gather and grow that community. The Brick forum and issue tracker are open to the public. We have also defined a contribution procedure for how to propose and implement changes to Brick (for example, to add vocabulary to Brick or to improve existing definitions ). All proposed changes are discussed before being merged into future versions; turnaround time is usually only a couple weeks. Since its inception in 2016, Brick has already been expanded through community efforts to add or expand the modeling capabilities for lighting systems and furniture.

In addition to developing the Brick data model, we want to encourage a software ecosystem for building applications: from components to interface with existing BMS over protocols like BACnet to big data platforms for analysis and machine learning and applications for fault detection or intelligent control. We’d like to see more open-source building software out there, and we’re committed to making our software open-source as well (see our GitHub at https://github.com/BrickSchema/).

Sinclair:  How can I start learning how to use Brick for my buildings?

Fierro & Koh:  There are plenty of resources already online! We have published various articles, presentations, example code, and tools on the Brick website. Learn basic concepts, play with tutorials, experiment with various tools, run a simple data server, execute Brick queries for data analysis and create your Brick models with machine learning.

The community is always open to collaborations and contributions. Stop by the developer forum or leave a question on the issue tracker. We are always interested in new use cases and questions about Brick.

Sinclair:  What's the future of Brick?

Fierro & Koh:  We believe Brick has a rich future. Because we have designed extensibility into the Brick data model, the vocabulary and scope of Brick will be able to scale with the needs of the community. We want to continue to integrate Brick with existing data models and building technologies and provide a seamless programming experience over them.

We will continue to improve Brick and its related tools and software, and hope to grow an active user community; you can get involved and track the progress online at our GitHub site.