Updated: Nov 8, 2021
One of the main challenges when dealing with Building Management Systems (BMS) is how to address the customization made in each model by the manufacturers. At Bandora, we develop a solution that fully integrates with most vendors (such as Siemens, Schneider Electric, Honeywell, and others), and we must assure we can work with any building. Ensuring normalized results from any kind of BMS forces to a complexity on several levels (communication, units, labels, deltas, etc.).
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):
each record has a timestamp;
each devices have a unique identifier;
we have access to a reference table that can relate device/variable/BMS;
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, in order to overcome issues like timezones 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 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:
Active Energy: kWh;
Apparent Energy: VAh;
Reactive Energy: VArh;
Active Power: kW;
Apparent Power: VA;
Reactive Power: VAr;
Most dashboards use the business intelligence approach and, to some point, Bandora’s solutions does is 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 creates daily/weekly aggregation via queries. This leads to heavy calculations every time a user access those aggregation. 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:
How are the value aggregated? We solve this issue via variable mapping: we must classified each variable according by the operation need (sum, average, max, min, etc.);
Are all the value 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’s Data Ingest and Data Normalization processes will continue to be easy to integrate, automatic and with no need for user intervention.