Qualité, Qualification et Sémantique des données

La notion de sémantique des données est importante. La pyramide de l’information ci-dessous présente de manière imagée les typologies de données en fonction de la richesse de l’information traitée :

Les couches de la pyramide de l’information sont :

• Couche 1, données brutes : ce sont les données que nous trouvons directement en sortie de capteur. Par exemple, un capteur de température nous fournira, pour une température de 23 °C une donnée brute de 23.

• Couche 2, informations : les informations correspondent à des données brutes enrichies avec des métadonnées ou des attributs permettant de les spécifier. Dans l’exemple précédent, nous pouvons enrichir les données avec leur unité, leur numéro de capteur, leur date… Des initiatives comme Haystack visent à standardiser des noms d’attribut afin de pouvoir plus facilement rechercher les données dans un tableau

Toute table d’une base SQL, objet en programmation, objet dans un maquette BIM… peut être considérée comme une information. A cette échelle de représentation, les liens entre objets n’existent pas. Les données liées peuvent être retrouvées à condition de connaître :

• • La nature des attributs associés à l’objet

  • La table à laquelle fait référence l’attribut

Dans une base SQL par exemple, seules des informations sont stockées. Le SGBD (Système de Gestion de Base de Données) ne connaît pas à priori les liens entre objets, mais il est possible à un opérateur connaissant la structuration de la base (nature des attributs, table cible…) d’écrire une requête spécifique permettant de retrouver les données (faire des jointures). Sans cette connaissance de la structure de la base, il n’est pas possible de retrouver les relations entre données.

• Couche 3, contexte : un contexte est un graph de données dans lequel chaque information est un nœud et les nœuds peuvent être reliés entre eux par des relations. Dans un SGBD graph, les nœuds et les relations sont des objets de la base (qui peuvent tous deux contenir des métadonnées). Ainsi, le SGBD graph connaît les nœuds et les relations et est capable, en une seule requête, de renvoyer un graph complet en conservant la cohérence et la consistance de l’ensemble des données et des relations entre données.

Les modélisations BIM, Building graph, BRICKS… reposent sur cette typologie de représentation. Un jumeau numérique repose aussi sur cette typologie de représentation. Le BOS SpinalCore repose sur un SGBD graph.

• Couche 4, wisdom : dans un système d’information, les applications, système d’analyse… jouent sur cette couche. Les applications utilisent des données contextualisées afin d’apporter de la valeur (prise de décision, action, conseil…)

Le BOS a pour objectif la gestion du jumeau numérique du bâtiment (aussi appelé dynamic building graph). C’est une plateforme logicielle qui fonctionne sur les couches 2 et 3 et qui permet la gestion de graph de données afin de faciliter le développement d’applications sur la couche 4.

Le BOS SpinalCom repose sur le noyau SpinalCore qui met en œuvre :

• Un SGBD in-memory, orienté graph, distribué

• Un protocole de réplication de graph asynchrone & bi-directionnel

• Un système de gestion d’événement distribué.

Jumeau numérique, référentiel unique & Building Graph

Le référentiel unique du bâtiment permet d’assurer la cohérence et les mises à jour de l’ensemble des systèmes connectés à ce référentiel (à l’image de la LDAP pour gérer les personnes sur un réseau informatique).

Le schéma ci-dessous organise ce référentiel sous forme d’arborescence spatiale :

La notion de données pivots est importante pour comprendre quel est le cœur de cible, le rôle et le positionnement de chacun des systèmes. Ces données donnent une information importante sur ce à quoi ce système donne du sens. Ceci permet aussi de distinguer les différentes solutions entre elles :

• Un Field Information System (FIS) ou BMS se concentrera sur des données de points de mesures ou d’équipement. Ce qui veut dire que les autres données (bâtiment, étage, local…) ne sont en général que des attributs (des métadonnées) associées aux points et non des objets à part entière de la base de données. Les initiatives Haystack, Bricks et plus généralement les GTB ou middleware GTB fonctionnent avec ces données pivots.

• Un Building Information System (BIS) se concentrera sur une description détaillée du bâtiment. Ce qui veut dire que chaque étage, pièce, éléments de structure… est un objet de sa base. Par contre l’adresse, la région ou la ville sont des attributs du bâtiment. Le BOS SpinalCore repose sur ce type de données pivots et utilise la ou les maquettes BIM pour initialiser le référentiel de données du bâtiment (ou building graph).

• Un portfolio Information System (PIS) ou BaaS se concentrera sur une description détaillée du patrimoine et une vision « grossière » de chaque bâtiment. Dans une GMAO par exemple, l’arborescence commence ressemble à contrats/région/sites/bâtiments/étages/pièces/groupe d’équipement. Le détail des luminaires dans une pièce et leur positionnement est rarement précisé et les murs, sols et autres équipements qui ne rentrent pas directement dans le contrat de maintenance ne sont pas décrits. Ils feront l’objet d’une note, d’un attribut dans un ticket lié à une pièce. Un SIG (Système d’Information Géographique) rentre aussi dans ce cadre.

Modèles de données gérés par le BOS SpinalCore

Sur le principe, il est possible de gérer n’importe quel type de modèle de données dans la technologie SpinalCore. Le SDK permet de créer un nouveau format de données si celui-ci n’existe pas encore.

Aujourd’hui, SpinalCom fournit et prend en charge dans son jumeau numérique, un ensemble de modèles de données ouverts qui peuvent être résumés dans le schéma suivant :