De 5 dingen die je moet weten voordat je een BOS kiest!

De belangrijkste functie van een OS (besturingssysteem of besturingssysteem) is die van tussenpersoon, tussen enerzijds software en anderzijds computerhardware (smartphone, pc, enz.), om de bronverzoeken voor deze software (opslag, berekening, enz.). De belangrijkste functie van een BOS is echter om software met elkaar te laten communiceren. De BOS is een analogie met het concept van OS, maar komt strikt genomen niet overeen met een systeemlogica van exploitatie:

• De BOS koppelt geen systemen aan een gebouw...

• Aan de andere kant koppelt de BOS verschillende systemen.

De BOS is daarom geen besturingssysteem maar een middleware, dat wil zeggen software die een netwerk voor informatie-uitwisseling creëert tussen verschillende IT-systemen. Het maakt het mogelijk om systemen die vaak lokaal geïnstalleerd zijn, te decompartimenteren (BMS-systeem, toegangscontrole, etc.) om ze dichter bij applicaties, vaak Cloud te brengen. strong> (CMMS, IWMS, reserveringssysteem, …).

De BOS streeft naar interoperabiliteit door verschillende systemen te laten communiceren. Maar interoperabiliteit is niet voldoende als elk systeem zijn eigen repository heeft. Om een ​​BMS-alarm te kruisen met een interventieverzoek dat wordt beheerd in de onderhouds tool, moeten beide systemen de apparatuur en gebouwen die door het alarm zijn getroffen een naam geven in de zelfde manier. Op dezelfde manier moet de naamgeving van een kamer in de Outlook-kalender, in de onderhoudstool en in het GBS hetzelfde zijn.

De keuze die een actor als SpinalCom maakt, is vertrouwen op het BIM-model om de ontologie te creëren (d.w.z. de modelgegevens met zijn naamgevingsregels en de relaties tussen alle elementen waaruit een gebouw bestaat).

Maar de ontologie gebaseerd op BIM kent bepaalde beperkingen. Anderen hebben zich dus onafhankelijk van BIM ontwikkeld. De belangrijkste zijn Project Haystack en Brick Schema, maar RealEstateCore dat wordt gebruikt door Microsoft Azure Digital Twins (platform van het ontwerp van digitale tweelingen gebruikt door ProptechOS en Willow) terrein zou kunnen winnen, terwijl het Digital Buildings Project van Google meer geïsoleerd lijkt .

Tegenwoordig vormen gebouwen die profiteren van een BIM-model een kleine minderheid in de bestaande voorraad en de Project Haystack-ontologieën en baksteen strong>zijn van nature  veel meer vertegenwoordigd in het slimme gebouw (enkele tienduizenden locaties voor Project Haystack). Een afstemming tussen de IFC-standaard (gebruikt voor BIM) en de bovenstaande ontologieën zou uiteraard wenselijk zijn, maar is nog niet voor iedereen bereikt. Aan de andere kant zijn deze verschillende ontologieën voor sommigen compatibel met elkaar.

Bepaalde BOS integreren, naast hun integratiefunctionaliteiten (d.w.z. “middleware”), functionaliteiten die overeenkomen met andere marktsoftwarecategorieën (CMMS, Digital twin, IWMS…) wat bijdraagt ​​aan het creëren van verwarring over de positionering hiervan BOS.

Maar deze aanpak is in tegenspraak met het principe van middleware waarmee je de beste software in elke categorie kunt kiezen. Zonder zich zorgen te hoeven maken over hun integratie, omdat de BOS daarvoor zorgt. Het kiezen van software “inbegrepen in het pakket” komt neer op het onthouden van een “best of breed”-benadering [2] wat niettemin een sterk belang vormt van een architectuur gebaseerd op een BOS-type middleware. Het zou zonde zijn om gebruikers teleur te stellen met software die “inbegrepen is in het pakket”, maar die onder de marktnormen ligt.

Het beschouwen van de BOS voor wat het werkelijk is vanuit IT-oogpunt (een middleware) is van fundamenteel belang voor het goed ontwerpen van de architectuur: een OS legt een centralisatie van de architectuur op (alle applicaties op een iPhone draaien op iOS), terwijl een "middleware" een tool rationalisatie van de architectuur is  wat niet veronderstelt dat de architectuur moet worden ingevoerd.

Goede IT-architectuurpraktijken moeten daarom het denken sturen en het is niet nodig om van de BOS het enige interoperabiliteitsknooppunt tussen systemen te maken. Wanneer twee systemen native communiceren, is het dus niet nodig om de BOS als tussenpersoon te positioneren. Het delen van gegevens via de BOS mag alleen worden gepland wanneer gebruik van deze gegevens in andere systemen wordt vastgesteld. Het voorzien in het delen van alle gegevens "voor het geval dat" is een erg dure oplossing die maar al te vaak aan het echte debat ontsnapt: waarvoor zou de BOS gebruikt moeten worden ?

En dus uiteindelijk: wat zal de waarde ervan zijn?

```html

Het gebruik van een oplossing om één enkele vastgoedopslagplaats te distribueren waarop elk van de systemen kan vertrouwen, is een belangrijke troef. Er zijn echter manieren om een ​​vastgoedrepository te delen zonder gebruik te maken van een BOS. Bovendien zijn er, zoals we hierboven zagen, enkele onzekerheden over het toekomstige datamodel voor het beheer van deze vastgoedreferentie in een BOS. Het verschil dat de BOS kan creëren zal daarom eerder voortvloeien uit zijn vermogen om verschillende systemen met elkaar te laten samenwerken.

Interoperabiliteit kan comfort en energieprestaties bieden dankzij gebouwautomatisering [3]. 

Open Technisch Gebouwbeheer (BMS)-systemen zoals Distech Controls voorzien echter al in deze behoefte. Aan de andere kant zal de BOS, in een context waarin het BMS-systeem minder open is, het mogelijk maken om interoperabiliteit te bereiken. Maar wees voorzichtig met de kosten die de historische spelers in GTB zullen opleggen om hun API te openen.

Het echte gebruik van BOS komt eerder voort uit het vermogen om twee werelden samen te brengen. Enerzijds die van bouwsystemen (BMS, IOT, GTC, etc.) die zijn eigen integrators heeft en die nauw verbonden is met fysieke apparatuur. En anderzijds die van informatiesystemen (CMMS, IWMS, gebouwapplicatie, reserveringssysteem, etc.). Het is daarom gepast om ons het gebruik voor te stellen dat voortkomt uit een combinatie van deze systemen, door de invalshoek van elke stakeholder van het gebouw te nemen: de bewoners, de sterke echte vastgoedbeheer, het werkomgevingbeheer, de leveranciers van bouwdiensten,…

Zodra dit gebruik waarbij verschillende systemen worden gecombineerd, is geïdentificeerd, zal het nodig zijn om de geschiktheid van de implementatie ervan te kwalificeren. Zorg er bijvoorbeeld voor dat bepaalde alarmen een curatief onderhoudsproces activeren in een CMMS of IWMS (ticketautomatisering). Is nuttig. Dit zal de taak van de beheerder echter alleen maar verlichten en het lijkt moeilijk om de investering in een BOS te rechtvaardigen door een aantal taken te verminderen die toekomen aan een multitechnische dienstverlener... 

```