The move towards the smart building, or the digital building, aims to transform the building into a platform of digital services that will make it possible to better manage, better operate, better maintain and better live in the building. To achieve these objectives and truly deliver the promises of smart building, all digital services must process, cross-reference or analyse building data.

Data management is therefore the heart of the construction of a smart building offer!

However, managing data is a complex activity, especially in a building which is itself a very complex asset in terms of the number of systems installed, the volume and heterogeneity of the data to be managed and the number of applications and of users. This activity must be carried out professionally by putting in place suitable models, products and quality processes.

The implementation of a BIS (Building Information System) process makes it possible to meet several concrete objectives of qualitative data management:

• Control your data

• Giving meaning to building data

• Streamline the management of building management systems:

  • • Convergence of repositories

    • Limitation of the number of connectors

    • Digital continuity throughout the life cycle

• Allow the evolution towards the smart building both technically and economically.

We can distinguish three levels of scale for information systems relating to the digital building :

• Level 1 or concentrator and PLC level : this level is made up of specific information systems operating on business verticals. For example, BMS, ISS, access control ... These information systems implement their own business applications which are generally presented in three layers:

  • • sensors, actuators, counters and all simple communicating equipment

    • PLCs and regulators

    • hubs and servers hosting supervisors

• Level 2 or BOS level : a true transversal layer of building data management, this new building information system aims to structure and comprehensively analyse building data. This system connects to field systems, structures the data in a unified building repository and implements applications in "fog computing" mode allowing the analysis, filtering, consolidation and management of building data as a whole. It is a building-wide layer of convergence.

• Level 3 or heritage level : this information system collects consolidated information from each building via a connection to the various BOS. It implements applications which make it possible to structure, analyse or consolidate data at the scale of a complete heritage (district). It allows data to be crossed between buildings and organizes the exchange of data with all the other cloud platforms or legacy systems (CMMS, district energy management services, property management, etc.).

The BOS (Buildings Operating System) is an operating system dedicated to the building. BOS is to buildings what Windows is to computers. A driver who speaks to everyone (motherboard, cd players, etc., for Windows) and allows everyone via a specialized application (program, driver, API, SDK, etc.) to have better use of its material and / or accessible data.

The BOS is therefore a data management platform that allows the convergence and restitution of building data:

• Descriptive data of the building: BIM and all the documentation

• Dynamic building data: all OT data (BMS, access control, SSI, etc.) and IoT (connected offices, dynamic signalling, etc.)

• Building usage data: all the information systems (IT) that use the building (CMMS, ERP, MS365, etc.)

The BOS makes it possible to "push" the building repository (for example building / floor / rooms / equipment) to all the applications connected to the BOS.

The functions of the platform core

A system kernel (or simply kernel, or kernel) is a fundamental part of the operating system.

Under BOS, a managed asset is not "just" a computer (a system) but a building that itself has subsystems (a system of systems). In other words, the BOS is a platform that must communicate, orchestrate and manage data coming from other distributed systems in the building.

As part of the operating system, the kernel provides:

• Hardware abstraction mechanisms (sensors, actuators, automatons, structure, furniture, building equipment, complete building).

• Information exchange mechanisms between software and hardware devices (via API or SDK). The kernel also allows various software abstractions and facilitates communication between processes.

• The core of an operating system is itself software with the following skills:

  • • semantic management

    • real-time or asynchronous management to manage "hot" data

    • Skills in data replication and in distributing complex data and abstraction mechanisms to other systems ...

    • File system management

    • orchestration of several specialized schedulers (batch, real time, inputs / outputs, etc.)

The BOS must enable data from building systems to be orchestrated on the main IP protocols: BACnet IP, JSON, Lonworks, SNMP, OPC, Azure IoTHub, Google IoT Core, Kafka, MQTT. It must also allow the creation of new connectors via an SDK (see below).

In order to function, the BOS must open “doors” or APIs to let data and requests from other software enter the BOS system. This system is called an "API Gateway". Third-party software (excluding BOS), whether physically present in the building or from an internet connection (SaaS or Cloud), must be able to use the open "doors" (API) of the BOS system to exchange data.

The BOS must also, for security reasons, close the "door" (stop the flow of data between the different systems) when the third-party program has finished its data exchanges or when the user exits the program.

To do this, the BOS software must have natively:

• Generic APIs allowing access to all the data contained in the BOS database

• Open SDK, documented to allow the BOS integrator or operator to create new specific APIs

• Publish with fine management of rights and security, APIs in API Gateway.

The SDK allows in particular:

• Data synchronization with BOS at a very fine level of granularity

• Managing access and data rights at a very fine level of granularity

• Managing events in the event of a change in data and launching an associated service (distributed CEP, Complex Event Processing)

• Improving or creating data models

• Connection and data exchange with new sources of building information

• The creation or improvement of new drivers / connectors with automated field systems

• Creation or improvement of data presentation API

The BOS must allow the use and recovery of data from BIM models:

• Modelling data: all modelled objects, their semantics and ontology

• The attributes: all the data, link, document linked to the object

There are currently two main formats of BIM model records :

• The called "open" format IFC (Industry Foundation Classes) which is a standardized format (ISO 16 739 standard) object-oriented for use in the construction industry. The IFC Format allows a standardized exchange that can be used by all BIM (Building Information Modelling) software. Since July 2016 the IFC format has been in IFC4 Add2 version.

• The called "proprietary" RVT Format (Revit) which is a format only used by software published by Autodesk, which is currently the software publisher most used by construction players. The RVT format allows all the data of a building to be exchanged in a single file. Since May 2019 Autodesk offers the 2020 version of the RVT format.

The integration process must describe:

• Each OT system connected to the BOS: protocol, data exchanged to allow connector configuration / development

• Each IT system connected to the BOS: protocol (API); data exchanged to enable use cases

• The BIM model creation charter: specifications and BIM convention to describe the content and organization of model data

• Application hosting

• The test and trial process

• Documentation and expected training

• Handover to the maintainer

The maintenance of the information system is at two levels:

• Maintenance of the technical architecture of the BIS information system based on the BOS

  • • Keep all "BOS and native application" documentation up-to-date available during the initialization and support (DEX) phase

    • Keeping all the documentation made available during the initialization and support phase "BOS and native application" up to date (SFD, DAT, SGT, Manual, user training)

    • Communication during production releases

    • Implementation of a user ticket management tool

    • Maintenance of environment copy scripts and associated documentation

    • Copy of environments

    • Correction of application anomalies

    • Level 1 support (taking into account requests from BOS users)

    • Level 1 support (functional administration)

    • Level 2 support (bug fixes)

    • Installation on environments

• Maintenance of data and parameters of the BIS Information System relating to the building

  • • Decision and responsibility for updating the model

    • Adding, modifying, moving equipment

    • Modification of partitioning

    • Correct organization of data and modelling

    • Validation of the conformity of BIM models

    • Transformation into Digital Twins

    • Update of the reference geographic context

    • Maintenance of links between data (BMS, BIM, etc.)

    • Data organization contexts

    • From the functional configuration context of building applications

    • Roles

    • Object attributes

    • Attached documentation

    • Correction of an IT API

    • Correction of an OT connector

    • Commissioning of pre-production for testing

    • Testing and validation of operation and non-regression

    • Switch to production

    • Saving configuration data

    • Updating the configuration log

    • Maintenance of contractual reports