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 are developing 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, 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:
Active Energy: kWh
Apparent Energy: VAh
Reactive Energy: VArh
Active Power: kW
Apparent Power: VA
Reactive Power: VAr
Temperature: ºC
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:
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.);
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.