X

Le rôle clé de la GTB et des protocoles réseaux dans l’ouverture vers les smart grids

On peut distinguer quatre grands niveaux fonctionnels nécessaires à la gestion des systèmes actifs du bâtiment grand tertiaire. Trois niveaux sont internes au bâtiment proprement dit (smart building), le quatrième niveau représente la liaison du smart building vers le monde des smart grids.

« Si l’on veut à la fois un pilotage du bâtiment efficace et l’ouverture vers les smart grids, on se doit d’être interopérable sur les quatre niveaux, depuis les réseaux de terrain jusqu’aux échanges d’hyper vision pour interagir avec les smart grids », précise Serge Le Men, directeur général de Newron System. « Des produits et équipements 100 % interopérables sur des réseaux ouverts au niveau des automates terrain ne suffisent pas à rendre la solution ouverte : les logiciels et les bases de données doivent également l’être. Les protocoles vont être différents en fonction de leurs usages : un protocole c’est un langage commun, et ce langage doit permettre d’échanger des données de façon compréhensible entre des équipements issus de différents fabricants », poursuit Serge Le Men.

Le protocole va donc être associé à une sémantique qui lui est particulière et pour certains, comme LONWORKS® ou KNX, mettre à disposition une base de données lisible et ouverte qui permet de construire une image complète d’un réseau avec tous les appareils installés et leurs fonctions respectives.

L’interopérabilité intra-protocolaire, premier pas pour l’interopérabilité :

il s’agit de déterminer, au sein d’un protocole donné, si les équipements de ce réseau sont bel et bien capables d’échanger entre eux. « On peut ainsi, par exemple au niveau de la couche terrain, mixer des capteurs et actionneurs de différents fabricants en « plug and play », sans se poser de questions », ajoute Emmanuel François, directeur des ventes de EnOocean.

Trois grands protocoles ouverts dominent le marché : LONWORKS®, BACnet et KNX. On peut dire que ces réseaux couvrent 80 % des besoins, et chacun est normé et a défini son standard de langage. « Aujourd’hui, il n’y a plus vraiment de soucis d’interopérabilité au sein d’un même réseau, les fabricants jouent le jeu pour la plupart ; par exemple, avec le standard LonMark nous avons 20 ans d’expérience et pas loin d’un millier d’équipements existants certifiés interopérables. Tous les acteurs, intégrateurs, assistance à maîtrise d’ouvrage sont aussi impliqués dans ce processus, la compatibilité au sein du protocole est donc assurée », précise Pascal Tigréat de la société Wago Contact et président de l’association LonMark France.

Un processus de certification permet de renforcer l’interopérabilité intra-protocolaire. Suivant les réseaux, il est plus ou moins contraignant ; pour LONWORKS ®, la certification est délivrée par un laboratoire indépendant qui vérifie que les profils LonMark sont respectés au travers des tests et d’un cahier des charges précis, mais elle n’est cependant pas obligatoire, précise Pascal Tigréat. Autre exemple avec EnOcean, avec une autocertification par le constructeur d’équipements ; Emmanuel François indique qu’un programme de certification externe devrait être lancé courant 2014.

« L’ interopérabilité inter-protocolaire ou entre différents protocoles est quant à elle indispensable au niveau des réseaux de la couche terrain et de la couche automation », insiste Serge Le Men. Avec ce prérequis et si on utilise des réseaux de terrain qui donnent une lisibilité totale à la description des données, il sera possible alors à n’importe quel superviseur de recueillir les données de façon homogène pour tous les équipements. Ce n’est pas toujours le cas pour certains réseaux qui n’ont pas de base de données standard.

Ensuite, les architectures s’appuient de plus en plus sur un support de communication éprouvé qu’est Internet protocol (IP) car on peut y faire transiter énormément d’informations (à partir des couches automation et gestion/supervision). « Au niveau des échanges proprement dits entre protocoles, il existe des middlewares et plateformes d’échange entre les protocoles standard (LON®, KNX, BACnet, Dali, EnOcean…). Pour illustration, le lancement d’une « stack LON®-BACnet IP » est en cours, qui permet dans une seule puce de faire la conversion entre le niveau terrain LON® et la couche supervision sous BACnet en IP », ajoute Pascal Tigréat. On ne peut pas évoquer l’interopérabilité sans aborder la compétence nécessaire sur toute la chaîne de création de l’architecture réseau de la GTB et qui se doit désormais d’être ouverte sur le Grid.

Et dès la conception, la finalité des protocoles aux différents niveaux doit être clairement énoncée : « Les protocoles sont des moyens pour être interopérables et ne font pas le résultat », souligne Alexandra Del Medico, déléguée générale BACnet France.

Enfin, sur tout le cycle du projet jusqu’à l’exploitation et la maintenance, « la montée en compétences des intégrateurs et des exploitants, que ce soit au travers de la formation continue ou initiale, est fondamentale pour maintenir interopérable et efficace la solution dans le temps », insiste Pascal Tigréat.

Interopérabilité et communication du bâtiment vers l’environnement extérieur :

l’interopérabilité ne se limite pas au bâtiment lui-même : il faudra également que le niveau supervision dans le bâtiment dialogue de façon simple avec le niveau hypervision/cloud et smart grid. Quelques initiatives sur le sujet : des messages standardisés sont en cours de définition au sein de la Smart Building Alliance dans le but de rendre interopérable les échanges aval-amont compteur. « Ces échanges tendent à libérer la data des bâtiments pour nourrir un écosystème d’applications logicielles dans le cloud telles que la gestion de la flexibilité énergétique, la mise en place d’une hypervision, de gestion de patrimoine, etc. », ajoute Serge Le Men.

BACnet est également en cours de développement de services Web, vers le cloud et les systèmes externes au bâtiment, cite Alexandra Del Medico. Il y a aussi l’association Obix qui a créé une spécification de services Web publics (utilisable par tous), basée sur du langage XML (langage préféré des applications échangeant via Internet). Les protocoles de terrain : deux protocoles dominent le marché, LONWORKS® et KNX, et il faut y ajouter des protocoles spécialisés métiers (comme Dali pour l’éclairage) ou encore les protocoles avec un support physique particulier (radio avec EnOcean et Zigbee). Quasiment tous sont connectables entre eux via des contrôleurs multi-protocoles.

Pour les protocoles de liaison entre les couches supervision et automation : si on peut parler d’une tendance, on peut dire que dans le grand tertiaire BACnet en IP est souvent l’épine dorsale entre les niveaux automation et supervision, remarque Serge Le Men. Avec BACnet, OPC UA, ou bien encore ModBub TCP, on peut choisir n’importe quel type de supervision ou d’automates. ll n’y a pas de réseau ou de bus parfait, il y a des réseaux qui sont plus adaptés à certains métiers et niveaux d’échange, selon Pascal Tigréat.

« Un véritable tournant s’effectuera quand la notion d’Internet des objets pourra s’intégrer totalement dans un bâtiment. Le développement massif de ces écosystèmes permettra la fusion de données inter-métiers dans une logique smart grid par l’utilisation notamment de méta-modèles comprenant les différentes sémantiques des protocoles des métiers du bâtiment », ajoute François Lemercier, responsable pédagogique en licence pro SPH à Rennes. Serge Le Men ajoute qu’actuellement, pour les immeubles grand tertiaire, on pourrait éviter les pièges d’une interopérabilité imparfaite, en répondant à trois questions clés :

  • Au niveau des protocoles « terrain », a-t-on choisi des protocoles ouverts type LONWORKS® ou KNX et/ou des protocoles dédiés par métier (Dali…), le tout dans un nombre limité ?
  • Au niveau du réseau reliant les couches « automation » et « supervision », a-t-on utilisé des protocoles standard type BACnet / IP ou OPC ? Est-ce qu’il est facile d’ajouter un second poste de supervision d’un autre éditeur sur mon réseau ?
  • Est-ce que mon système est suffisamment accessible au niveau de ses bases de données, de ses descriptifs d’architecture réseau pour être intégré par n’importe quel opérateur / intégrateur de la place ? Beaucoup de pilotes et de travaux sont en cours au niveau de la connexion du bâtiment intelligent vis-à-vis du smart grid et des différents systèmes applicatifs externes (gestion de patrimoine, système de flexibilité énergétique vers les opérateurs réseaux etc.) ; les acteurs majeurs de la gestion technique active sont très impliqués sur ces sujets, les règles de l’art vont évoluer et des protocoles d’échanges de haut niveau vont arriver à maturité.

Le cahier des charges du smart building devra donc également intégrer les contraintes liées à la connexion au smart grid et nous y reviendrons lors d’un prochain article.

Jean-François MOREAU:
Related Post