It is mandatory that large buildings must have their own Building Management Systems (BMS), which can be from the most diverse suppliers. On many occasions, different buildings that belong to the same company, have different BMS. This results in a complex management scenario for the facility manager.
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.