Un standard pour le smart grid

Les propriétaires d’installations photovoltaïques optimisent leur consommation propre grâce à leur pompe à chaleur: ils chauffent leur maison ou leur eau lorsque le soleil brille. D’autres charges flexibles, telles que les voitures électriques ou les batteries, peuvent être utilisées de la même manière. Un système de gestion de l’énergie commute alors ces flexibilités au sein de la maison en fonction de la situation. Certaines charges particulièrement flexibles adaptent leur puissance au courant injecté: les pompes à chaleur équipées d’onduleurs règlent leur puissance en continu, et les stations de recharge contrôlent tout aussi finement le courant destiné aux voitures électriques.

Il manque un standard

Mais ce qui n’existe pas encore, c’est un standard de communication commun grâce auquel un système de gestion d’énergie pourrait contrôler tous les appareils. Qui construit une maison ne peut pas combiner les appareils à volonté. Un intégrateur de système doit parcourir les listes des fabricants et vérifier quel système de gestion est compatible avec quel onduleur PV, quelle pompe à chaleur et quelle borne de recharge. Et quiconque souhaite remplacer un dispositif des années plus tard est confronté au même problème: quel équipement puis-je intégrer dans mon système existant?

Du point de vue du réseau de distribution

Cela devient encore plus difficile lorsqu’un gestionnaire de réseau de distribution (GRD) souhaite piloter les flexibilités au sein de son réseau. Depuis les années 1970, il existe bien en Suisse les signaux de télécommande centralisée qui peuvent être utilisés pour bloquer les pompes à chaleur ou les machines à laver. Mais il n’est guère possible de contrôler de manière ciblée les charges flexibles dans un quartier pour éviter les pics d’énergie.

Pourtant, les charges flexibles seraient justement idéales pour cela: si une grande installation PV est installée sur une ligne sous-dimensionnée du réseau de distribution ou si, dans un parking souterrain, plusieurs places sont équipées de bornes de recharge pour voitures électriques, les tensions ou les courants peuvent dépasser rapidement les valeurs pour lesquelles les lignes ont été conçues. Le GRD se trouve alors confronté à la question de savoir s’il faut installer de nouvelles lignes.

Utiliser les flexibilités

Il pourrait utiliser les pompes à chaleur et les stations de recharge connectées au réseau de distribution de manière ciblée en tant que flexibilités, afin de désamorcer les rares situations au cours de l’année où des surtensions ou des courants excessifs sont observés (voir l’article «De l’intelligence dans le réseau» paru dans le Bulletin 8/2020). L’injection de la production des installations PV pourrait également être temporairement limitée. Mais il manque un standard de communication commun grâce auquel un GRD pourrait contrôler toutes ces flexibilités.

Paul Hugentobler, directeur du secteur Technologie chez Optimatik, explique qu’aujourd’hui, les systèmes sont souvent livrés et testés de manière à ce que les compteurs intelligents puissent commander des charges ou des systèmes photovoltaïques par l’intermédiaire de relais, mais qu’au quotidien, le potentiel est loin d’être exploité. «Cela va augmenter rapidement dans les années à venir», nuance-t-il. «Les systèmes PV n’exercent pas encore trop de pression sur le réseau, mais d’ici 2035, nous nous attendons à une production photovoltaïque trois à sept fois plus élevée qu’aujourd’hui.» Et l’expansion de la mobilité électrique risque d’être encore plus rapide, prévient-il.

Selon lui, il existe de nombreux standards de communication pour contrôler les flexibilités, mais aucun ne s’est imposé. On assiste à une prolifération des systèmes photovoltaïques, des pompes à chaleur, des voitures électriques et des batteries – le principal frein à l’essor du réseau intelligent. Aujourd’hui, on construit une interface après l’autre.

Modbus TCP dans la maison

Revenons à la communication à l’échelle de la maison: il y est déjà courant que les appareils communiquent entre eux afin d’optimiser l’autoconsommation. De nombreux fabricants prennent en charge le protocole Modbus TCP, simple à exploiter: «Les informations se trouvent dans des registres qu’il suffit de lire», explique Arne Meeuw, CTO chez Exnaton et responsable de la technologie dans le projet Quartierstrom. Modbus est un ancien standard issu de l’automatisation industrielle qui a trouvé une application dans la technique du bâtiment et a été étendu en 2018 avec une authentification et un cryptage des données.

«Il y a toujours un manque de normalisation», explique Arne Meeuw. «Il n’y a pas de cohérence systématique entre les données et les registres. Une norme réglementerait également d’autres aspects, par exemple le fait qu’une pompe à chaleur se protège contre un trop grand nombre de démarrages. Aujourd’hui, certains fabricants le font, d’autres non.»

Chaque fabricant est différent

Hans Fischer, responsable des ventes et du développement commercial chez Solar Manager, le fabricant d’un système de gestion d’énergie, déclare: «Aujourd’hui, chaque fabricant d’équipements a sa propre idée des interventions externes – jusqu’à quel point il est possible d’intervenir et comment cela doit se faire.» Le système Solar Manager prend en charge environ 150 appareils. L’intégration de nouveaux dispositifs peut être plus ou moins aisée, explique-t-il: «Il y a des fabricants qui s’appuient sur des interfaces standardisées. Nous ne devons alors plus discuter que de registres et de contenus. D’autres fournissent des interfaces de programmation (API) et d’autres encore utilisent leurs propres solutions de communication propriétaires. Ces dernières sont les plus complexes pour nous.»

SmartGridready est en train d’émerger

Suite à une initiative de la Conférence des associations de technique du bâtiment KGTV et de l’Association Smart Grid Suisse (VSGS), un groupe de gestionnaires de réseaux de distribution, il a déjà été question en 2016 de la manière dont un standard pourrait être défini. Avec le soutien de l’Office fédéral de l’énergie (OFEN), une interface a été élaborée pour contrôler le réseau intelligent: en 2019, l’association SmartGridready était fondée.

Le standard SmartGridready met les informations suivantes à disposition: quelles valeurs peuvent être récupérées ou écrites à quel endroit. Il se déplace sur la couche d’information et utilise les protocoles de communication existants dans le bâtiment tels que Modbus TCP ou KNX. Christoph Brönnimann est responsable de la technologie chez SmartGridready: «Nous nous concentrons sur les profils fonctionnels. Notre objectif est de créer un standard ouvert et neutre qui prend en charge toutes les générations de technologies, des contacts de commutation aux modèles de tarifs dynamiques.»

Profils fonctionnels pour l’échange de données

Les profils fonctionnels sont divisés en différents niveaux (tableau): les niveaux 1 et 2 correspondent à de simples signaux discrets tels que des signaux de télécommande ou des contacts de commutation SG Ready, par exemple, qui sont utilisés pour inciter les pompes à chaleur à chauffer. SmartGridready ne doit pas être confondu avec SG Ready. Cette dernière appellation correspond à l’interface déjà très répandue utilisant des contacts de commutation. SmartGridready est le label récemment lancé qui vise à créer une meilleure transparence dans la communication des données entre la technique du bâtiment et le réseau intelligent. Christoph Brönnimann évite le mot «norme», car SmartGridready n’est pas une norme formelle de la CEI ou du Cenelec, mais un «pont» entre les normes existantes.

Le niveau 3 fonctionne avec des caractéristiques fixes, par exemple des caractéristiques en matière de puissance réactive ou une réduction de l’injection dans le cas des installations photovoltaïques, comme convenu entre l’exploitant du réseau et celui de l’installation. Les niveaux 4 et 5 fonctionnent avec des incitations dynamiques (tarifs) ou des profils de puissance qui s’appliquent pendant une certaine période, ou qui sont ajustés dynamiquement dans le cas du niveau 5. Les applications typiques sont les installations des prosommateurs ou les communautés d’autoconsommation.

Le code source en un clic

SmartGridready est basé sur la norme CEI 61850, une norme pour les sous-stations et les appareillages électriques. Pour la communication physique, l’accent est mis sur les technologies Web et le protocole IP. «Notre objectif est qu’un nouvel équipement puisse être intégré en un clic de souris», explique Christoph Brönnimann. Le fabricant d’un système de gestion d’énergie peut télécharger le code source pour intégrer un dispositif sur le site de SmartGridready. Les fabricants d’appareils fournissent quant à eux les profils des dispositifs à SmartGridready sous forme de fichier XML.

Les profils fonctionnels sont actuellement définis pour le niveau 1 et sont mis à l’épreuve dans des installations de test. L’une des installations se trouve chez Energie Thun. Onze entreprises participent aux tests, et d’autres suivront. Exnaton testera également le standard SmartGridready: «Nous sommes très intéressés par cette solution», déclare Arne Meeuw. Le standard en est encore au stade de la démonstration, dit-il, mais il a l’air prometteur. «Tout fabricant peut abstraire son interface sur SmartGridready. Il s’agit d’une mise en correspondance de registres et de données.»

Actifs dans la normalisation

Il s’agit toujours d’une initiative suisse. Cependant, Christoph Brönnimann est actif au sein du comité technique TC 205 du Cenelec, où il s’investit dans le groupe de travail WG 18 pour les «Customer Energy Manager & Ressource Manager». Christoph Brunner de SmartGridready est quant à lui membre du TC 57 de la CEI dans le WG 17 pour les «Distributed Energy Resources», et Roland Ullmann est actif au sein du TC 205 WG 19 du Cenelec pour l’ontologie, la représentation formelle de l’information. Ensemble, ils tentent de faire de SmartGridready une norme internationale.

Les fabricants déploient des interfaces ouvertes

Un standard évolue lorsqu’il est soutenu par de nombreux fabricants. Alors que font donc ces derniers? Stiebel Eltron est l’un des plus grands fabricants de pompes à chaleur en Europe. En Suisse, Zdravko Djuric y est responsable de la technologie: «Nos pompes à chaleur peuvent être commandées par le biais d’une interface SG Ready avec des relais, par une interface analogique de 0 à 10 V ou par un bus. Nous prenons en charge Modbus-TCP, utilisé par 90% de nos clients, et KNX.» L’interface analogique de 0 à 10 V est destinée aux spécialistes qui programment leur propre automate, ajoute-t-il. Il est ainsi possible de régler la température de la pompe à chaleur, et même de l’utiliser pour rafraîchir le bâtiment en été.

Pour les interfaces de bus, Stiebel Eltron suit l’approche consistant à mettre toutes les informations à disposition. Environ 230 points de données sont définis avec leurs adresses pour le Modbus, où les températures de départ, les pressions et les débits volumiques peuvent être lus. «Les températures de consigne et les courbes de chauffe peuvent être réglées via le Modbus. Le propriétaire du bâtiment peut aussi lire les données énergétiques», précise Zdravko Djuric. Ainsi, le Solar Manager mentionné plus haut utilise l’interface de Stiebel Eltron pour optimiser l’autoconsommation dans la maison: les températures de consigne sont ajustées et le bâtiment est utilisé comme un accumulateur de chaleur.

Coordonner les dispositifs

Mais, selon Zdravko Djuric, il ne suffit pas de fournir les données: «Lorsqu’un fabricant d’un système de gestion d’énergie nous contacte, nous l’aidons à régler correctement la maison.» Falko Schmidt, responsable des produits en matière de technologie solaire chez SMA, déclare également: «Il faut se coordonner avec les autres fabricants.» SMA prend en charge l’interface Modbus avec une documentation ouverte: selon sa propre interface Modbus propriétaire et selon le format normalisé de la SunSpec Alliance – une norme américaine qui s’est imposée dans le secteur PV. En outre, SMA a développé son propre protocole de communication SEMP pour la gestion de l’énergie, qui est désormais de plus en plus complété par EEBus. EEBus est soutenu par de nombreux fabricants allemands dans le domaine du photovoltaïque, des pompes à chaleur, mais aussi des machines à laver (marque blanche) et des constructeurs automobiles. «Nous nous appuyons fortement sur EEBus», déclare Jochen Bornemann, responsable du secteur numérique chez SMA.

EEBus et SmartGridready

EEBus et SmartGridready se font-ils concurrence? Zdravko Djuric ne le voit pas ainsi: «EEBus et SmartGridready se complètent. EEBus est le canal de données, SmartGridready le langage commun.» EEBus définit l’échange de données sur plusieurs niveaux: dans la couche de communication, il repose sur le protocole TCP/IP standard, mais détermine précisément certaines valeurs et exige, par exemple, un cryptage TLS. Les données sont transmises au format XML ou JSON. Tout ceci est spécifié dans son propre protocole SHIP. Dans la couche d’information (Spine), les modèles de données sont définis pour les appareils: quelles valeurs se trouvent dans les fichiers XML/JSON.

Plus poussé et plus complexe que SmartGridready, EEBus a été élaboré sur plusieurs couches de protocole et fournit des outils étendus pour différents groupes d’équipements: pour les marques blanches, pour les pompes à chaleur, pour le photovoltaïque, pour les compteurs intelligents ou pour la mobilité électrique.

Le standard SmartGridready, quant à lui, correspond à une interface simplifiée au niveau de la couche d’information, qui vise à permettre l’échange de données entre les fabricants et grâce à laquelle un système de gestion d’énergie peut accéder aux appareils. SmartGridready utilise des protocoles existants tels que Modbus (y compris SunSpec), JSON REST ou l’EEBus mentionné plus haut. La couche d’application – et donc la conception des cas d’utilisation – est laissée aux fabricants d’équipements et de systèmes de gestion d’énergie.

Incitations du réseau

Alors que les équipements domestiques apprennent à communiquer entre eux, le réseau de distribution n’a encore que peu accès aux flexibilités du bâtiment. Le réseau et le bâtiment ont des intérêts différents, explique Henning Fuhrmann, responsable du pré-développement chez Siemens Building Products. «Le bâtiment veut optimiser l’autoconsommation, le réseau de distribution veut éviter les pics d’injection et les courants élevés.» Un système, ajoute-t-il, doit optimiser le fonctionnement du bâtiment tout en tenant compte des conditions du réseau et du fournisseur d’énergie. «Il n’est pas possible de le faire depuis le réseau. Le gestionnaire de réseau ne connaît pas assez bien le bâtiment: la demande de chaleur, les dimensions du stockage d’énergie et les prévisions de consommation.» Finalement, Henning Fuhrmann voit l’utilisation d’un signal basé sur les prix pour l’utilisation du réseau et de l’énergie en tant que «protocole de communication» entre le réseau et le bâtiment – transmis par une communication IP standard.

Paul Hugentobler pense, quant à lui, que le gestionnaire de réseau devrait pouvoir contrôler directement les flexibilités en fonction de l’application. «Bien sûr, le client doit par exemple pouvoir disposer comme bon lui semble de son propre chauffage et être à même de passer outre les commandes du fournisseur d’énergie. Mais si le gestionnaire de réseau veut éviter des pics d’injection et des surcharges, ou mettre en commun les flexibilités pour offrir de l’énergie de réglage, il doit pouvoir contrôler les flexibilités de manière fiable. Pas nécessairement chaque appareil individuellement, mais au moins à l’échelle du bâtiment.» Les cas d’utilisation des points de vue du réseau de distribution et du bâtiment ne se contredisent pas nécessairement – la situation change selon le moment, elle est dynamique, explique-t-il. «Les flexibilités peuvent être réglées de manière à ce que le client n’y voie aucun inconvénient.»

TCP/IP et technologies Web

Paul Hugentobler confirme que le protocole TCP/IP est utilisé pour la communication entre le fournisseur d’énergie, le réseau, le bâtiment et le client. Pour l’intégration de systèmes back-end, dit-il, il s’agit souvent de services de type «Message Queuing» tels que MQTT. Les portails des clients finaux communiquent via des services Web tels que REST, qui repose sur JSON, pour stocker et transmettre des données structurées.

La norme CEI 60870-5-104 est encore souvent utilisée pour regrouper les flexibilités, mais elle est déjà assez ancienne, souligne-t-il. Arne Meeuw prévient, quant à lui, que la norme CEI 60870-5-104 ne connaît pas le cryptage: «Vous pouvez bien sûr encapsuler les données avec TLS, mais alors ce n’est plus une norme.»

L’électromobilité en tant que moteur du réseau intelligent

Selon Paul Hugentobler, aucune meilleure pratique ne s’est encore imposée pour la mobilité électrique. Ce qui est clair, dit-il, c’est que le réseau de distribution communique avec l’opérateur du point de charge (CPO) ou directement avec la station de recharge locale, et règle ainsi le courant via la station de recharge. «D’autres flexibilités tendent aussi à être contrôlées directement ou par le biais d’un système de gestion d’énergie, et pas uniquement via le compteur intelligent», poursuit Paul Hugentobler.

Les échanges personnels sont aussi importants

Les prochains mois montreront si SmartGridready et EEBus peuvent s’établir. Hans Fischer, de Solar Manager, Paul Hugentobler, d’Optimatik, et Arne Meeuw, d’Exnaton, sont d’accord: un standard faciliterait leur travail et donnerait une impulsion au réseau intelligent. Arne Meeuw relativise toutefois: «L’intégration des appareils ne demande pas tant d’efforts que cela si l’on obtient les données des fabricants.» La Suisse n’est pas si grande, dit-il, il n’y a pas beaucoup de fabricants différents. «Cela laisse également de la place aux entreprises qui programment des interfaces», poursuit-il. Zdravko Djuric estime, pour sa part, qu’il est tout aussi important que les acteurs du secteur se mettent en réseau et partagent leurs connaissances.