Architecture Système
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…)
Définitions importantes
« AEP » : Application Enablement platform. Ce terme désigne l’ensemble des composants de la plateforme permettant de faciliter de développement de nouvelles applications fonctionnant au-dessus du BOS (applications natives) et d’en minimiser le coût. Le SDK (voir définition ci-dessous) est un élément indispensable d’une AEP.
« API » : ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle le logiciel offre des services à d'autres applications. Dans le cadre du BIS, nous distinguons deux types d’API :
« API natives » : API développées sur la base du SDK SpinalCore qui présentent des données gérées par le BOS
« API tierces » : API des systèmes tiers qui seront utilisées par des connecteurs natifs du BOS
« API gateway » : l’API gateway est le cœur de la solution de gestion d’API. Elle agit comme la seule entrée dans un système permettant à plusieurs API ou micro-services d'agir de manière cohérente et de fournir une expérience uniforme à l'utilisateur. Dans notre cadre, l’API gateway regroupe l’ensemble des API natives du BOS Spinalcore.
« Application » : programme informatique (ou ensemble de logiciel) directement utilisé pour réaliser une tâche, ou un ensemble de tâches. Nous distinguons deux types d’applications :
« Applications natives » : Applications développées sur la base du SDK SpinalCore en relation directe avec le BOS
« Applications Tierces » : Applications développées par des tiers, qui ne fonctionnent pas sur la base du SDK du BOS et qui pourront être connectées, via un connecteur ou une API, au BOS.
« BOS ou Building Operating System » ou SpinalCore : plateforme logicielle développée et commercialisée par SpinalCom. Celle-ci contient notamment le datahub objet-graph SpinalCore, le SDK SpinalCore, une interface d’administration, un système d’orchestration d’événements distribué, un système de réplication et de synchronisation de données, une librairie de modèles de données open source pouvant évoluer…
« Connecteur » : logiciel ou partie d’un logiciel réalisant l’interaction, l’échange de données entre le BOS et une application ou un autre système d’information. Nous distinguons deux types de connecteurs :
Les connecteurs natifs : connecteurs natifs développés directement sur la base du SDK SpinalCore. Ils se connectent aux API tiers pour réaliser le lien entre le BOS et une application tierce.
Les connecteurs tiers : connecteurs développés par des tiers. Ils se connectent avec une API native pour réaliser le lien entre le BOS et une application tierce.
« Jumeau numérique » : modèle de données représentatif de la description physique, de l’état réel, de l'historique et du comportement d’un bâtiment ou plus généralement d’un asset physique à tout moment.
« Logiciel » : ensemble des programmes et des procédures nécessaires au fonctionnement d'un système informatique.
« Logiciels natifs » : logiciels développés sur la base du SDK SpinalCore, nativement couplés au BOS.
« Modèle de données » : Modèle qui décrit de façon abstraite comment sont représentées les données dans une organisation métier, un système d'information ou une base de données. Dans le cadre du BIS, nous distinguons :
Les modèles de données natifs : décrits et développés dans le cadre du SDK SpinalCore. Tous les modèles de données natifs sont open source
Les modèles de données Tiers : décrits dans les API Tiers ou dans le cahier des charges ou la documentation des applications tierces.
« SDK » : un Software Development Kit (SDK) est un ensemble de librairies logicielles, de documentations et de tutoriels permettant de faciliter la création de nouveaux logiciels dans un environnement défini. Le SDK SpinalCore permet de créer de nouveaux logiciels (applications, APIs, Connecteurs, modèles de données…) nativement compatibles avec le BOS SpinalCore.
« Système d’Information Bâtimentaire ou BIS » : système complet présenté dans le schéma ci-dessus. Le BIS regroupe le BOS et l’ensemble des logiciels connectés au BOS : Applications, Analytics, connecteurs, API…
« SpinalTwin Suite » : correspond à l’ensemble des logiciels natifs (Applications, Analytics, connecteurs et APIs) développés et commercialisés par SpinalCom qui permettent d’interagir avec les données du jumeau numérique. Tous les Logiciels de la suite SpinalTwin sont des logiciels natifs, développés sur la base du SDK SpinalCore.
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.