Schéma d’architecture du BIS (zoom sur l’échelle bâtimentaire)

À l’échelle du bâtiment (échelle intermédiaire du système globale), l’architecture du Système d’information du bâtiment (BIS) est représentée par le schéma ci-dessous :

Le détail des éléments de la couche patrimoniale (au-dessus) et de la couche terrain ou Edge (en-dessous) ne sont pas représentés. Le détail du système d’information bâtimentaire (BIS) schématisé comporte les éléments suivant :

• Le BOS SpinalCore, cœur de plateforme, qui assure les fonctions de gestion transverse des données du système et la gestion du jumeau numérique

  • Un SDK permettant le développement et le déploiement de services connectés au BOS et orchestrés par le BOS

  • Une suite de services / micro-services répartis en plusieurs catégories :

    • L’API gateway vers les services IT tiers de la couche patrimoniale ou de la couche bâtiment

    • L’API gateway (ou driver gateway) vers les systèmes OT tiers de la couche terrain

    • Les applications natives de la couche bâtimentaire construites directement sur la base du SDK SpinalCore

    • Les sources de données de la couche bâtimentaire (BIM, DOE, Occupation, Services de réservation de salle, agenda…)

Noyau logiciel (Kernel), parallèle avec le PC

Un noyau de système (ou simplement noyau, ou kernel) est une des parties fondamentales du système d’exploitation.

Dans le cadre du BOS, l’asset géré n’est pas « simplement » un ordinateur (un système) mais un bâtiment qui comporte lui-même des sous-systèmes (un système de système). Autrement dit, le BOS est un « OS virtuel » qui doit communiquer, orchestrer et gérer les données venant d’autres systèmes distribués dans le bâtiment.

En tant que partie du système d’exploitation, le noyau fournit :

• Des mécanismes d’abstraction du matériel : capteurs, actionneurs, automates, structure, mobilier, équipements du bâtiment, bâtiment complet. Le jumeau numérique apporte cette abstraction.

• Des mécanismes d’échanges d’informations entre logiciels et périphériques matériels (via API ou SDK). Le noyau autorise aussi diverses abstractions logicielles et facilite la communication entre les processus et l’orchestration des processus.

Le noyau d’un système d’exploitation est lui-même un logiciel. Dans le cadre du BOS, il s’agit du datahub SpinalCore ayant :

• Des compétences de gestion sémantique de graph pour gérer le jumeau numérique (ou Building Graph)

• Des compétences de gestion temps réel ou asynchrone pour gérer les données « chaudes »

• Des compétences de réplication de données et de graph pour distribuer des données complexes et les mécanismes d’abstraction aux autres systèmes…

Son rôle central impose par ailleurs des performances élevées. Le noyau SpinalCore met donc en œuvre un système de gestion de base de données « in-memory » et est déployé sur des serveurs riches en RAM. Cela fait du noyau la partie la plus performante du système d’exploitation.

Le schéma ci-dessous présente les différentes parties du noyau :

Fonctions remplies par le noyau

Le noyau a comme fonction de base d’assurer la gestion du jumeau numérique du bâtiment, de gérer les flux de données entre applications et de proposer une interface entre l’espace noyau et les programmes de l’espace utilisateur (SDK).

A côté des fonctions précédemment listées, le noyau fournira également des fonctions telles que :

• La gestion des systèmes des fichiers

• L’orchestration de plusieurs ordonnanceurs spécialisés (batch, temps réel, entrées/sorties, etc.)

Nature du BOS SpinalCore

Le BOS SpinalCore est une plateforme de gestion de données reposant sur un système de gestion de base de données graph, asynchrone, in-memory et distribué. Il existe plusieurs natures de plateforme de gestion de données que l’on classe généralement en trois catégories :

Data Lake : Un « lac de données » est un système ou un référentiel de données utilisé pour stocker des données dans son format naturel. Inventé en 2010 par James Dixon, alors directeur de la technologie chez Pentaho, ce terme désigne généralement un magasin unique de toutes les données d'entreprise sous forme de fichiers ou d'objets blobs. Qu'il s'agisse de données du système source ou d'autres données non traitées, un lac de données fait référence à un vaste pool de données brutes pour lesquelles l'objectif n'a pas encore été défini.

Exemple : SGBD MongoDB

Data Warehouse : Un « entrepôt de données » est un système de stockage de données utilisé pour la création de rapports et l'analyse de données. Également appelé entrepôt de données d'entreprise, ce type de système de référentiel traite les données téléchargées directement à partir des systèmes opérationnels d'une entreprise. Contrairement à un lac de données, un entrepôt de données ne traite que des données structurées, ce qui offre des avantages en termes d'espace de stockage et d'accessibilité à un public plus large.

Exemple : SGBD SQL

Data Hub Un Data Hub, ou hub de données, est une plateforme de stockage virtuel. Elle regroupe un ensemble de données en provenance de systèmes d’informations multiples qui sont homogénéisées pour être redistribuées.

L’objectif du Data Hub est de fournir aux entreprises une source de données unifiée et centralisée, afin que les systèmes tiers puissent accéder rapidement et facilement aux informations dont ils ont besoin.

Exemple : SAP Hana

→ Le BOS SpinalCore est, selon les définitions précédentes, un data hub dédié à la gestion de jumeaux numériques d’asset physiques.

Serveur physique ou virtuel

Il est recommandé de déployer un serveur par BOS (machine physique ou virtuelle) et de ne déployer sur ce serveur que le BOS et ses applications natives. Ceci afin de garantir la disponibilité réseau, la disponibilité de la RAM et plus généralement de l’ensemble des ressources nécessaires au bon fonctionnement du BIS. Les caractéristiques et performances attendues dépendent du bâtiment sur lequel le BOS est déployé. Il est possible, sur des bâtiments de grande taille, d’envisager le bâtiment comme un patrimoine et de déployer plusieurs BOS et un POS.

Les compétences minimales des serveurs à fournir seront les suivantes :

• Un OS Linux (Ubuntu 18.04 LTS)

• 4 Gbit (Gigabit) de RAM minimum par bâtiment géré (à adapter en fonction de la taille du bâtiment)

• Un processeur 4 cœurs et 2GHz minimum

• Une carte réseau Gigabit

Les capacités en RAM et en puissance de calcul pourront évoluer en fonction :

• De la taille et de la complexité du bâtiment (nombre de points GTB, SSI… à remonter)

• Du nombre d’applications déployées au-dessus du BOS et de leur nature

• Du volume et de l’historique de données à conserver dans la base de données in-memory du BOS

• Il sera nécessaire de faire un dimensionnement du serveur pour chaque projet.

Hébergement cloud, hybride, on premise

Le BOS SpinalCore n'a pas de contrainte d'hébergement. Il est deployable sur des architectures full cloud, hybride ou on premise.

Full Cloud : elle présente des avantages : souplesse de mise en œuvre, évolution, prix

Points d’attention :

• Cette option va nécessiter la mise en œuvre d’un mécanisme de sécurisation des données complémentaire (cryptage…) puisque les données vont sortir du bâtiment pour aller vers le BOS dans le cloud

• La réactivité et le temps de latence seront à surveiller pour garantir une bonne expérience utilisateur.

Hybride : pour optimiser les flux de données, nous pouvons déployer des architectures hybrides (de type Microsoft Azure Edge, Google Anthos, AWS Edge, ...), en déléguant une partie des calculs sur les infrastructures du bâtiment. Ainsi nous transférons dans le cloud des données consolidées et agglomérées, réduisant très fortement les volumes de données (facteur 10 en estimation). À l'image des API du BOS qui ont plusieurs natures :

• API de bas niveau : API graph qui permettent d’accéder aux données brutes en parcourant le Graph de données (par exemple, la température d’un capteur dans un bureau à un instant donné) ;

• API de niveau intermédiaire : API de processus : le BOS assemble des données pour mettre à disposition des données consolidées (par exemple : la température moyenne sur une période d’un étage) ;

• API de haut niveau : API de KPI : le BOS assemble et consolide un grand nombre de données pour mettre à disposition le résultat d’un assemblage complexe de données (par exemple le taux de confort sur une période de l’ensemble du bâtiment).

Points d’attention :

• Cette solution est plus complexe à maintenir et plus chère.

• Une partie des activités du BOS est déportée hors du bâtiment donc des mécanismes de sécurisation de la donnée devront être mis en place.

On premise : consiste à héberger le BOS sur site (on premise) avec du Hardware souple et évolutif selon les besoins (as a service). Avec cette option, les millions de données générées chaque jour au sein du bâtiment sont orchestrées et consolidées sur des serveurs locaux.

• Cette stratégie de délégation de l’orchestration et la consolidation des données du bâtiment avant transmission dans le cloud permet comme dans l’option précédente de gagner significativement en performance et en réduction des temps de latence.

• Cette option est également plus sécuritaire car les données du bâtiment ne sortent pas de la tour.

• Elle favorise enfin une meilleure résilience du système d’information bâtimentaire

Points d’attention :

• Cette solution est plus chère.

• La solution reste évolutive mais nécessite une intervention physique si besoin.