Quels Web Services pour répondre à la demande de R2S
Un des piliers du label R2S (Ready2Services) avec le réseau Smart est l’ouverture des données techniques du bâtiment au travers de Web Services. L’idée est de développer des applications de services capables de s’interfacer avec les équipements qui gèrent le confort, la sécurité, … du bâtiment permettant ainsi de renforcer l’expérience utilisateur et faciliter le déploiement de ces offres.
En discutant avec plusieurs opérateurs de services qui veulent s’interfacer avec ces Web Services, je me rends compte de difficultés et idées préconçues : j’aimerais apporter mon éclairage.
Un web service qui expose quoi ? Assurément pas un capteur technique mais une zone d'usage
Beaucoup de constructeurs intègrent les capteurs et actionneurs physiques à l’informatique. De fait, ils exposent des Web Services liés à ces capteurs et actionneurs. A mon sens cela est une fausse bonne idée. Quand je suis opérateur de services et que je développe une application mobile, ai-je besoin de savoir que le capteur d’occupation situé sur l’entrée 4 de l’automate 8 du réseau 2 de l’étage 23, dit « occupé » ? Ou ai-je besoin de savoir que le bureau de Serge est occupé ? Ceci qu’importe le nombre de capteurs dans le bureau et sans savoir à quel automate ils sont raccordés sur quel réseau ?
La réponse est évidente, mais quand on regarde les solutions actuelles, nous sommes loin de cela car beaucoup collent à la représentation physique et proposent des Web Services dans les produits ou alors avec ces données techniques unitaires décorrélées de l’usage.
Il faut progresser vers la création d’une vraie ontologie d’usage qui expose non pas les données physiques mais les données logiques telles que les zones, car les services sont sur les usages. Mais il faut toutes les zones d’usage : pas seulement les zones bureaux, mais les façades, les groupes de fourniture, les zones de repos … et même les zones dans les zones à l’aune des nouveaux espaces de travail qui offrent une kyrielle d’espace de fonctions. En fait, il faudrait représenter toute entité logique capable de recevoir des services.
Ainsi, l’opérateur de services peut développer facilement une interface réduisant ainsi les coûts travaux preneur et augmentant l’expérience utilisateur. Ces Web Services doivent supporter de surcroît les modifications de zones, le re-cloisonnement, les changements d’usage de zone, ….
À quel niveau publier le web service ? Pas au niveau produit terrain mais au niveau infrastructure
Là encore une fausse bonne idée est de publier les Web Services au niveau des produits. Pourquoi ? Deux raisons principales que je développerai : les Web Services doivent être exposés sur Internet. Si on suit cette logique, on devrait exposer les produits ou réseau terrain sur Internet. Cela relève soit d’une plaisanterie ou alors d’une complexité accrue, impliquant des réseaux virtuels à créer mais surtout exploiter in fine. Et dans ce cas, quid de la segmentation en preneurs ? On comprend que ce n’est pas forcément la bonne idée.
De plus, si je descends au niveau du produit, je ne peux avoir de Web Service sur l’usage et la zone comme vu précédemment, je suis trop bas au niveau de la technique… Je n’accède qu’à la partie du produit d’automatisme sans donnée contextuelle.
Alors on me dira qu’il est possible avec des Switchs de niveau 3 de faire des réseaux virtuels qui isolent les réseaux, …. En effet pour un BAC+8 avec un tournevis, mais dans ce cas les coûts travaux et maintenance s’envolent … mais même si nous faisons cela, il demeure qu’en travaillant au niveau terrain, on n’a pas les données logiques, on est trop bas : comment proposer une seule donnée simple comme « occupation du bureau de Serge » si plusieurs capteurs sont dans le bureau – oui le bureau de Serge est grand – et que chaque capteur fournit sa donnée ? Pas possible …. il faut remonter à un niveau supérieur. Autrement c’est l’opérateur de services qui recrée ceci dans son application, bonjour les coûts !
Il faut ainsi imaginer un déploiement de données contextualisées au travers des zones logiques depuis un outil dans le bâtiment, tel un outil d’intégration graphique hébergé sur un serveur de GTB réseau. Cela permet de ventiler ces informations et publier ces zones d’usage en web services sur des réseaux différents en fonction des consommateurs de ces informations.
Il faut pouvoir déployer des services par preneur et par métier et non par produit
Les bâtiments tertiaires sont mono ou multi preneurs. Il faut donc penser multi preneurs mais également exploitation … chaque preneur ayant le choix de son fournisseur de services, nous devons pouvoir exposer les données depuis des sources différentes, sur des réseaux différents les données propres au preneur. L’exploitant n’interagira pas avec le bureau de Serge de la même manière que Serge dans son utilisation quotidienne. L’exploitant aura besoin de l’occupation, de la position de la vanne, de l’historique de température de consigne, … alors que Serge voudra allumer, éteindre, augmenter la température – oui Serge est frileux dans un grand bureau …
Là encore, le seul moyen est de proposer une suite logicielle qui va permettre d’affecter des étages à des preneurs, de représenter différemment la même zone et les publier en Web Services adéquates sur les réseaux IP adéquates.
Des web services orientés preneur exposant des zones logiques orientées usages avec une ontologie, surtout pas au niveau terrain orienté technique brut
En conclusion, je dirai qu’il ne faut pas se faire berner et penser en raccourcis du genre : il faut tous les automates sur IP et des Web Services dedans ; le miroir aux alouettes typique, né de raccourcis. Il faut demander la création d’une vraie ontologie du bâtiment, découpant physiquement mais également logiquement le bâtiment en zones et publiant au bon niveau les Web Services structurés, documentés et qualifiés. C’est sur ces données que vont s’appuyer les propositions de valeur des services qu’ils soient au preneur, au visiteur, au mainteneur ou aux property manager.