Haystack, Brick … NE SONT PAS UNE SOLUTION
Suite à la lecture de cet article de Memoori, j’ai souhaité apporter ma vision sur ce sujet.
Haystack, Brick … ne sont pas une solution car ils ne couvrent qu’une partie du modèle de données requis. La seule solution consiste à utiliser un intergiciel (middleware) qui gère l’interopérabilité entre les silos par le biais d’une source unique de vérité. Encore une fois, la source unique de vérité ne peut pas être Haystack … ou une nouvelle source qui émergera puisque, par définition, vous ne pouvez pas penser à tous les cas d’utilisation d’une smartcity ou d’un smartbuilding. Par conséquent, la seule solution que nous avons trouvée chez SpinalCom est d’intégrer les données BIM au cœur de notre middleware. Les fichiers BIM contiennent toutes les informations nécessaires comme la description de l’espace, la liste des équipements par espace (localisation), des attributs comme la date d’installation… Ce n’est pas parce que vous avez deux silos utilisant le même protocole qu’ils sont interopérables. Cela dépend de la façon dont vos équipements ont été déployés, c’est-à-dire avec quelle normalisation des données. En bref, en utilisant Bacnet pour deux silos, vous pensez utiliser le même langage alors qu’en fait vous utilisez deux dictionnaires différents ! Alors comment peuvent-ils se comprendre ?
QUEL EST L’IMPACT De l’intégration des silos ot/it ?
Un autre problème se pose lorsque vous voulez intégrer des silos OT (GTB, IoT, sûreté, sécurité…) avec des silos IT (ticketing, application mobile occupant, systèmes de réservation…). D’un côté, vous avez des silos OT fonctionnant en temps réel et générant des séries temporelles quand les silos IT sont des données transactionnelles non-temps réel. La question suivante est donc : comment intégrer des systèmes qui ne parlent pas à la même fréquence ? Cela semble facile, non ? Eh bien, ce n’est pas tout. Cela signifie que vous avez besoin d’un intergiciel asynchrone !
La solution serait dans une GTB?
Je vois déjà beaucoup de gens dire qu’ils ont la solution avec une GTB !
- Un middleware GTB ne peut fonctionner qu’avec des données en temps réel, il ne sait pas ce qu’est un ticket par exemple. Par exemple, vous ne pouvez pas demander à une GTB de collecter un ticket à partir d’une GMAO et de l’envoyer ensuite à une autre application !
- Un autre problème avec le middleware de la GTB est la source unique de vérité gérée, qui est limitée au monde de l’OT ! C’est la raison pour laquelle nous disons que la normalisation des données comme Haystack, Brick … est trop limitée pour couvrir l’ensemble des besoins d’un bâtiment intelligent ou d’une ville intelligente.
Bien sûr, certains diront que vous pouvez intégrer des silos point par point et gérer l’interopérabilité sans middleware. Ils se trompent complètement, car le coût total de possession d’un spaghetti est dix fois plus élevé à long terme. De plus, il offre une très mauvaise expérience utilisateur. Par exemple, lorsque le partitionnement de l’espace change, que se passe-t-il dans un spaghettiware (et même avec une GTB) ? Eh bien, vous devez modifier chaque description de votre actif pour chacun de vos silos ! Un cauchemar et un coût important. Ici encore, la seule solution est d’avoir un middleware qui soit responsable de cette source unique de vérité et qui soit capable de pousser une nouvelle description du bâtiment vers chacun des silos connectés pour les mettre à jour.
Sébastien Coulon, Cofondateur, SpinalCom