All sizes fits one

What about these little working ants

Is mandatory that large buildings must have its own Building Management Systems (BMS), which can be from the most diverse suppliers.

And, 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 handles the uniqueness of each BMS, and thus succesfully created a system that allow bandora to collect data from each BMS, whatever is its format. These steps are:

- BMS mapping / DataSource creation

- Data ingestion,

- Information storage

DataSource

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 a similar way to all BMS's.

So the DataSource 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 DataSource is created.

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

Now it's possible to understand that, regarding the integration process, everything goes around the DataSources.

Also, it is evident that for each new BMS to integrate, a unique process must be developed to allow the creation it’s specific DataSource. The good news is that bandora already developed the patterns that allow the process to define the DataSource for some BMS manufactures.

Data ingestion

After the creation of a BMS DataSource, bandoraOM is able to start pulling data from it. Data arrives at bandoraOM in different ways and formats. At this point, a simple ETL is in order 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 DataIngest agent. Some times, one BMS may even have multiple DataIngest agent, this is if different BMS data is to be used, like data stored in trend logs or real time data.

Data ingestion is always done using a pull architecture. But sometimes, bandora finds the need to install middleware in some 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, but yet normalized. This means that there are still may information that is stored in a raw format. After normalization, the data lake is drained and thus allowing bandoraOM DataIngest to be ligthwhited.

Conclusion

In conclusion, the described BMS data ingestion paradigm allows the bandora solution to be able to integrate a very different range of buildings and BMS's in an efficient and fast way, 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.