Prescribe a BOS
Particular technical specifications elements
The paragraphs below describe the key elements of prescribing a BOS as a data platform. These requirements do not address business applications connected to the BOS
Why put a Building Information System (BIS)?
Set up a BIS (Building Information System) based on a core BOS platform
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.
Roles: Editor, Integrator and Maintainer
The software editor provides generic technical software bricks allowing the integrator to assemble and configure these software bricks to create a functional information system adapted to a project. Then the integrator will hand over the building information system to the maintainer / operator of the building information system.
The perimeter of BIS and BOS
From building to heritage
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.).
Definition: IT / OT / BIM convergence
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:
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.)
OT connection capacity
OT : Operational Technology (BMS, IoT, Access control, Bike terminal ...)
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).
IT connection capacities
IT : Information Technology (GMAO, ERP, Occupant services...)
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
BIM connection capacities
BIM : Building Information Modeling
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.
Adaptation and specific configuration of the BOS to a project
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
The test and trial process
Documentation and expected training
Handover to the maintainer
Maintenance of the building information system
The building information system requires actions comparable to a classic business IS.
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
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