The building operating system is an attractive concept: like an iOS or an Android, it involves having a operating systemto articulate all the building systems or equipment. A system to govern them in short. However, when we look beyond our borders, the concept only exists very timidly and no product stands out. The concept of BOS can be compared in the Anglo-Saxon world to that of “integration platform”
[1]
. Wikipedia ignores the concept of BOS.
However, in France, Sensinov, SpinalCom or even Vayandata have a certain visibility. Should we believe in BOS?
1. BOS: a French concept to describe “middleware” type software
The main function of an OS (operating system or operating system) is that of < strong>intermediary, between on the one hand software and on the other hand computer hardware (smartphone, PC, etc.), to manage the >resource requests for this software (storage, calculation, etc.). However, the main function of a BOS is to make software communicate with each other. The BOS is an analogy to the concept of OS but it does not correspond, stricto sensu, to a system logic of exploitation:
- On the other hand, the BOS links different systems.
The BOS is therefore not an OS but a middleware, that is to say software which creates a information exchange network between different IT systems. It allows systems often installed locally to be decompartmentalized (BMS system, access control, etc.) to bring them closer to applications, often Cloud. strong> (CMMS, IWMS, reservation system, …).
2. Still a lot of uncertainty about the future model…
The BOS aims for interoperability by allowing different systems to communicate. But interoperability is not enough if each system has its own repository. To cross a BMS alarm with an intervention request managed in the maintenance tool, both systems must name the equipment and premises affected by the alarm in the same way. Likewise, the naming of a room in the Outlook calendar, in the maintenance tool and in the BMS must be the same.
The choice made by an actor like SpinalCom is to rely on the BIM model to create the ontology (i.e. the model data with its naming rules and its relationships between all the elements that make up a building).
But the ontology based on BIM presents certain limits. Others have thus developed independently of BIM. The main ones are Project Haystack and Brick Schema, but RealEstateCore which is used by Microsoft Azure Digital Twins (platform of design of digital twins used by ProptechOS and Willow) could gain ground while Google's Digital Buildings Project seems more isolated.
Today, buildings benefiting from a BIM model are a tiny minority in the existing stock and the Project Haystack ontologies and Brickare naturally much more represented in the smart building (several tens of thousands of sites for Project Haystack). An alignment between the IFC standard (used for BIM) and the ontologies above would obviously be desirable but it has not yet been achieved for all. On the other hand, these different ontologies are for some compatible with each other.
3. Be careful not to give in to the sirens of the all-in-one BOS
Certain BOS integrate, in addition to their integration functionalities (i.e. “middleware”), functionalities corresponding to other market software categories (CMMS, Digital twin, IWMS…) which contributes to create confusion about the positioning of these BOS.
But this approach is contradictory with the very principle of middleware which allows you to choose the best software in each category strong> without worrying about their integration because the BOS will take care of it. Choosing software “included in the package” amounts to depriving yourself of a “best of breed” approach
[2]
which nevertheless constitutes a strong interest of an architecture based on a BOS type middleware. It would be a shame to disappoint users with software “included in the package” but which is below market standards.
[2]
Choose the best IT solutions in their categoryrather than turning to a general software package.
4. Hypercentralization in a BOS is not necessarily the IT architecture offering the best ROI
Considering the BOS for what it really is from an IT point of view (a middleware) is fundamental to properly designing the architecture: an OS imposes a centralization of the architecture (all the applications on an iPhone run on iOS) while a "middleware" is a tool rationalization of the architecture which does not presuppose the architecture to be put in place.
Good IT architecture practices must therefore guide the thinking and it is not necessary to make the BOS the sole interoperability node between systems. Thus, when 2 systems communicate natively, it is not necessary to position the BOS as an intermediary. The sharing of data via the BOS should only be planned when uses of this data in other systems are identified. Providing for the sharing of all data "just in case" is a very expensive solution which too often eludes the real debate: what are the uses that the BOS should be used for ? And so ultimately, what will be its value?
For optimal strategy and organization in a hybrid work environment, explore our Project Management Assistance (AMO) services. We help you choose and implement the best solutions for your business
5. The BOS only has value through the uses that result from the combination of systems
Using a solution to distribute a single real estate repository on which each of the systems can rely is an important asset. However, there are ways to share a real estate repository without using a BOS. Furthermore, as we saw above, there are some uncertainties about the future data model for managing this real estate reference in a BOS. The difference that the BOS can create will therefore rather result from its ability to make different systems interact.
Interoperability can provide comfort and energy performance thanks to building automation [3]
. However, open Technical Building Management (BMS) systems like Distech Controls already cover this need. On the other hand, in a context where the BMS system is less open, the BOS will make it possible to achieve interoperability. But be careful of the costs that will be imposed by the historical players in GTB to open their API.
The true uses of BOS result rather from its ability to bring two worlds together. On the one hand that of building systems (BMS, IOT, GTC, etc.) which has its own integrators and which is closely linked to physical equipment. And, on the other hand, that of information systems (CMMS, IWMS, building application, reservation system, etc.). It is therefore appropriate to imagine the uses resulting from a combination of these systems by taking the angle of view of each building stakeholder: the occupants, the real estate management, the work environment management, the building service providers,…
Once these uses involving combining several systems have been identified, it will be necessary to qualify the appropriateness of their implementation. For example, ensure that certain alarms trigger a curative maintenance process in a CMMS or IWMS (ticket automation) Is usefull. However, this will only lighten the task of the maintainer and it seems difficult to justify the investment in a BOS by reducing some of the tasks that fall to a multi-technical service provider…
```
BOS is a subject requiring in-depth consideration at the risk of spending a lot of money on an architecture that provides little value. The wow effect will not be enough to justify the bill: the BOS must provide real added value! To make the right choices, the AREMIS teams are there to guide you.
WRITTEN BY
After over 15 years of experience working with some of the biggest players in the real estate market, I have understood one thing about my clients.
More than anything, they need someone who will listen to their needs and help them make the right decisions
