Bandora

Commercial buildings are responsible for 40% of total energy consumption worldwide, and almost 30% of CO2 emissions. Heating Ventilation and Air Conditioning (HVAC) systems and water heating systems represent approximately 70% of the energy consumption of commercial buildings where about 75% of the primary energy supply is based on fossil fuels.

Energy efficiency of buildings has been a widely discussed topic with the aim of reducing energy costs, improving thermal comfort and lowering the consumption of fossil fuels. One way to assess if a building is energy efficient is through Building Energy Modeling (BEM), which is typically defined as a physics-based software simulation of a building energy use.

A detailed whole building energy simulation usually starts with a 3D drawing of a building geometry where all thermal zones are defined, being also required as input a vast amount of information:

The possibility to aggregate and standardize the management of different BMS’s, regardless their manufacturer, in a simple and intuitive platform is the main goal of bandoraOM solution.

To achieve this goal, Bandora developed a three-step paradigm that manages the uniqueness of each BMS, and thus successfully created a system that allows Bandora to collect data from each BMS, whatever is its format. These steps are:

– BMS mapping / Data Source creation

– Data ingestion,

– Information storage

Data Source

The uniqueness of each BMS presents a challenge for Bandora since it makes it necessary for each building to be seen in a unique way, and it is not possible to acquire information in an equivalent way to all BMS’s.

So, the Data Source concept was designed to allow information from the BMS to be mapped in standardized Bandora format. And therefore, for each BMS that Bandora integrates, a correspondent Data Source is created.

In a single Data Source is defined the set of variables and devices that are present in its corresponding BMS.

Now it is possible to understand that, regarding the integration process, everything goes around the Data Sources.

Also, it is evident that for each new BMS to integrate, a unique process must be developed to allow the creation of its specific Data Source. The good news is that Bandora already developed the patterns that allow the process to define the Data Source for some BMS manufactures.

Data ingestion

After the creation of a BMS Data Source, bandoraOM is able to start pulling data from it. Data arrives at bandoraOM in diverse ways and formats. At this point, a simple ETL is to ensure that all data is stored in a standardized way and thus ready for normalization purposes, as described by David Carrilho.

So, to ensure stability in the data ingest process, each BMS has its own Data Ingest agent. Sometimes, one BMS may even have multiple Data Ingest agent, this is if different BMS data is used, like data stored in trend logs or real time data.

Data ingestion is done by using a pull architecture. But sometimes, Bandora finds the need to install middleware in buildings that allow the pull of data to be done on premises with the BMS.

This is where bandoraDE gateway enters the scene. This gateway must be connected to the same network as the BMS. Its main function is to be able to securely route information to the Bandora servers using different security and encryption paradigms.

Information storage

Ingested data is then stored in a small data lake in a standardized format, yet normalized. This means that there is still may information that is stored in a raw format. After normalization, the data lake is drained and thus allowing bandoraOM Data Ingest to be lightweighted.

Conclusion

In conclusion, the described BMS data ingestion paradigm allows the Bandora solution to be able to integrate a range of buildings and BMS’s in an efficient and fast way, to achieve the what called Building Management Made Easy, simplifying the implementation of the solution. Each pull request made to a BMS is like a little ant carrying a small pace of a leaf to its ant hole. In the end, a gigantic ant colony is formed.

To address the issues and achieve correct data normalization, we assume that the data ingested from the BMS follows certain rules (after a first step transformation that translate the information needed):

1. each record has a timestamp;
2. each devices have a unique identifier;
3. we have access to a reference table that can relate device/variable/BMS;
4. we know the current units of any value.

The first step when loading the raw data that comes from the BMS is to standardize the time unit (timestamp). At Bandora we can deal with any kind of timestamp know to computers as we will always translate them as UTC timestamp, to overcome issues like time zones and saving daylight periods.

To be able to manage any BMS system in a single dashboard, we need to ensure variable uniformity. We decided to transform them into the same units for all data-sources (we can, however, re-transform them into the user preferred unit when the data is being “uploaded” to the dashboard). The units Bandora use as default are:

1. Active Energy: kWh
2. Apparent Energy: VAh
3. Reactive Energy: VArh
4. Active Power: kW
5. Apparent Power: VA
6. Reactive Power: VAr
7. Temperature: ºC
8. etc.

Most dashboards use the business intelligence approach and, at some point, Bandora’s solutions do as well. The problem appears when it is needed to act, i.e., send commands to the Building Management System, using a channel that “flows” against what is common on a Business Intelligence system. Another difference is time aggregation tables: most Business Intelligence frameworks create daily/weekly aggregation via queries. This leads to heavy calculations every time a user accesses those aggregations. At Bandora, we believe that by knowing which calculations will be needed they can be done directly in the database by creating actual table with time aggregates. This allows for a better performance of the dashboard as it reduce the CPU consumption at the time but brings to light other issues:

1. How are the values aggregated? We solve this issue via variable mapping: we must classified each variable according by the operation need (sum, average, max, min, etc.);
2. Are all the values aggregated? No! Not all variables can be aggregated as it would not be useful (alarms and state values are not aggregated on our solution).

This is a running process. As vendors launch new products or software upgrades, we must update our normalization engine to maintain data quality without compromising performance. Bandora is addressing BMS Customization and Data Normalization processes, that will continue to be easy to integrate, automatic and with no need for user intervention.