Home PublicationsData Innovators 5 Q’s for Omar Tabba, Chief Product Officer of BrainBox AI

5 Q’s for Omar Tabba, Chief Product Officer of BrainBox AI

by Eva Behrens
omar tabba alt headshot

The Center for Data Innovation spoke with Omar Tabba, chief product officer of BrainBox AI, a company based in Canada that uses artificial intelligence to optimize the energy usage of heating, air conditioning, and ventilation systems in commercial buildings. Tabba discussed the different data sources BrainBox AI combines to predict and control a building’s heating and ventilation systems and some challenges of providing scalable data-based solutions in a field that lacks standardization.

This interview has been edited.

Eva Behrens: What opportunity or challenge led to the founding of BrainBox AI, and how do you address this challenge?

Omar Tabba: This is a good question, and it has at its heart our climate crisis. Buildings account for nearly 40 percent of global emissions. And the largest load that accounts for operational carbon emissions within buildings is the heating, cooling, and ventilation. And what our co-founder and CTO Jean-Simon Venne realized is that a whole bunch of data is already there, inside the control systems of the heating and cooling equipment in our buildings. And this data can be things like room temperature data, the status of a fan, and so on. However, this data is often locked in proprietary databases in a computer somewhere in the building and is not utilized to its full potential. With the advent of AI, our co-founder had a light bulb moment when he got the experience of riding in one of the early demo self-driving cars. He realized that if AI can drive a car in the dynamic environment in the streets, then certainly, we can make it run an air handler, or a chiller, or a building in general, autonomously. And so that set BrainBox AI out on this journey: get the data from the building, put it in our cloud, train an AI model on how this building behaves, and then start modulating this building in near real-time. This way, we significantly reduce the energy consumption and carbon emissions of buildings. We are leveraging existing data, sensors and actuators, and control systems in the building. We’re now able to learn more about how buildings behave to optimize them.

Behrens: What differentiates your technology from older technologies, such as thermostats, which automatically adjust the building’s temperature to match a setpoint temperature, and what part does AI play in that?

Tabba: Studies from around the world show that, statistically speaking, roughly 30 percent of the energy consumed in an average commercial building is wasted. This is a giant number, and reducing it is the motivator that drives the whole team here at BrainBox AI. 

The first rule of energy efficiency is that you can only save a portion of what is wasted. And while there’s a lot of waste, the good news is that we can address that. So why is there so much energy waste in buildings, despite heating, ventilation, and air conditioning (HVAC) control systems? Multiple factors play into that. For example, older buildings tend to be less efficiently designed because of older building codes. And there is also the execution of the construction and maintenance. If a building is not maintained well, it drifts away from its commission state, and things don’t work as they used to. In aggregate, this causes significant energy inefficiency.

Control systems like thermostats, classically, are reactive. If I have a thermostat on the wall, it’s sensing the space temperature in my room right now, comparing it to a setpoint. If the setpoint is programmed to be, let’s say, 21°C, or 72°F, and it senses the space temperature is 25°C, it turns on the cooling fan, bringing me back down to 21°C. This cycle continues. But the key is that the thermostat is playing catch-up; it’s reacting to an error that has already occurred, usually because of changing weather. If the temperature has risen, you have to cool it back down and spend more energy doing so. But BrainBox AI takes the building data we discussed in the first question, marries it with weather data coming from the closest weather station, and trains the AI.

Let’s think of the AI as a junior engineer. She’s never been to this building and doesn’t know anything about it, so she needs training. This training period takes a few days to a few weeks, depending on the building’s size. After training, the AI can predict how a building will behave based on the weather outside by observing how it behaved over the training period. Kind of like a junior engineer, it would say, this zone is facing the morning sun and gets hotter more quickly, this other zone is west-facing, and so on. We have developed techniques that allow us to predict the space temperature in every building zone two hours in advance with over 95 percent accuracy. So, if we think back to the reactive control issue of the thermostat, we can predict the error. The AI knows that in two hours, given today’s weather forecast, it will be 25 degrees, and it will turn the fan on now to avoid the temperature rising later. By doing these micro-adjustments 24/7, we’re able to avoid most inefficiencies. We also often increase the comfort in the building because we’re adhering to the setpoint more closely while reducing fan runtime, pump runtime, all these devices that consume energy. We have some significant results, with reductions north of 20 percent of CO2 emissions. That closed-loop system, where the AI constantly observes, learns, and makes real-time micro-decisions, makes this all possible.

Behrens: Please explain your “whole brain approach” and the advantages of combining data internal to the building with external data.

Tabba: I’ve already mentioned two data sources, the building data, so sensory data and equipment status, and the weather data. But we also look at the utility grid mix and its emissions factors. Solar-generated electricity has a different GHG emissions profile than coal-fired power plants. We also bring in utility tariff structures, the cost of the energy. And in some cases, we’re bringing in occupancy data, so when are people in this building, when does it open or close? All this data is piped live into our platform and used to enrich the AI model, adding control parameters we can modulate. For example, we are piloting a brand-new algorithm in the US, where we are using the 24-hour prediction of the grid emissions factor to minimize the emissions, knowing the grid’s energy mix. If I know that I have solar electricity coming in the morning and coal-fired electricity in the afternoon, I can pre-cool the building in the morning down to a lower limit chosen by the owner, let’s say 18°C. And when the grid switches to a coal-fired source, let’s say at noon, I can turn my equipment off and let the building temperature drift upward to a pre-specified maximum, say 25°C, and minimize the amount of energy I consume in that coal window. This automated emissions reduction is a powerful example of how data can be used to drive material outcomes for society.

What’s beautiful about energy efficiency is that it’s the lowest-hanging fruit. And the other outcome after you reduce your emissions is that you’ve also lowered your utility bill costs. And lower operating costs make you a healthier and more profitable organization.

Behrens: How do you ensure that your BrainBox infrastructure, both the hardware and the algorithms, are compatible with different buildings’ existing HVAC systems?

Tabba: This question points to one of the unsung heroes of our tech stack. There are many existing HVAC and building automation control systems and communication protocols. And we need to be able to speak to all of them if we want to address this inefficiency problem at scale.

We leverage a mix of approaches to integrate with existing building automation systems. We try to integrate using only data, only the communication protocols available in the market, like the BACnet protocol. These are open standards that are used by building automation manufacturers to communicate. We use languages like this to ingest data at the building level, and then we take it up to the cloud. 

There’s another challenge, which is data normalization. It’s one thing to ingest the string and the value. It’s another thing to relate that data to the real world. In buildings, you might find a data point from, let’s say, a temperature sensor that is labeled “supply_temp_C” or “supply_air_temp.” There’s no common nomenclature used in this industry. Slowly, some standards are emerging. But for now, a key part of what we do is getting the data from the building into the cloud and then normalizing it to an open industry standard called Haystack, where we tag all the data points with standard tags. And then, we can treat the data and use it to train the AI. 

Now, not every building has a sophisticated automation system; many small buildings only have a thermostat. We had a customer called Sleep Country that has 250 stores across Canada. They have relatively small stores, 5,000-6,000 sqft, or 500-600 sqm, with two rooftop units each and one thermostat controlling each rooftop. And this thermostat doesn’t have any communication capabilities. The individual stores are small, but in aggregate, they have a large energy footprint nationally. We replaced their thermostats with programmable Wi-Fi ones and programmed them to point to our cloud using standard Wi-Fi technology. That allows us to connect the stores to the cloud and modulate that HVAC equipment. We just completed the rollout of this portfolio with Sleep Country, and they’re experiencing significant energy savings.

 Behrens: What steps do you take to make data recorded by a building’s existing HVAC system usable for the AI systems that are part of BrainBox AI?

Tabba: As I said, data normalization and enrichment are key for us to do advanced control applications. First, we need to understand what the data point is. Is this a space temperature point or a fan status? Then, we need to understand the value, meaning the units in degrees Celsius, degrees Fahrenheit, pressure, humidity, etc. We also need to understand the energy impact of HVAC equipment beyond what is available in building automation systems. For various reasons, in building automation systems, people categorize equipment in big buckets. An air handler is an air handler, whether it’s big or small. But a 10-horsepower motor impacts the grid differently than a one-horsepower motor. We do what we call power tagging of the major HVAC equipment in the building. We record that this is a one-horsepower motor and that’s a 10-horsepower motor, and we take that into consideration when we’re modulating the building to minimize emissions. We generate significant value by acquiring this data, standardizing it, and enriching the existing building automation data with it.

I think the industry would benefit from standardization. It took a lot of herding cats and pulling teeth to standardize a couple of communication protocols, mainly the BACnet protocol, for building automation system interoperability at the field level. The industry has recently made some advances toward data point, nomenclature, and tagging normalization using the Haystack standard. But it’s still short of a standard like USB. When I buy a USB mouse, I don’t care who made it, I just look for the USB plug. And in HVAC, we’re still far from that interoperability at the field device and cloud application levels. I think companies and building owners often get blindsided by reality. They think they’re buying a state-of-the-art, expensive building automation system. They believe that, like with their computer, they can change the service provider and plug in different equipment. But manufacturers use significant proprietary lock-in to ensure recurring revenue and ongoing high margins, excluding competitors from driving down costs. Standardization and interoperability at the field device level and of data, tagging, and nomenclature schemas would allow market forces to drive down costs and give building owners the best of all worlds.

You may also like

Show Buttons
Hide Buttons