En raison de l'augmentation significative prévue de la production stochastique dans le réseau électrique, le besoin de flexibilité et de coordination du côté de la demande devrait augmenter. Les marchés énergétiques décentralisés font partie des solutions les plus prometteuses permettant de stimuler la coordination entre la production et la consommation, en permettant même aux petits acteurs de capitaliser sur leur flexibilité. L'objectif principal de Hive Power est de développer une plateforme basée sur la blockchain pour soutenir les groupes de prosommateurs qui souhaitent créer leur propre marché de l'énergie. L'élément central de ce cadre est ce qu'on appelle le Hive, c'est-à-dire une mise en œuvre d'un marché de l'énergie basé sur la technologie blockchain (voir notre livre blanc sur hivepower.tech pour avoir des informations détaillées sur la plateforme Hive Power).Cet article décrit Demo Hive, le premier banc d'essai développé par notre équipe et présenté lors de l'Energy Startup Day 2017 à Zurich, en Suisse, le 30 novembre 2017. Pratiquement, la démo est un cas simple mais aussi significatif d'une ruche ; elle est constituée d'un producteur et d'un consommateur, les fameux travailleurs. Un troisième élément est la QUEEN, dont le but est de gérer l'interaction entre les travailleurs et le réseau externe et de suivre les mesures liées à l'énergie consommée/produite par les travailleurs. Le producteur, ci-après nommé SOLAR, simule une installation photovoltaïque d'une puissance nominale de 5 kWc. En revanche, l'autre travailleur(LOAD) génère des données sur la consommation d'une charge. La figure 1 montre le banc d'essai de démonstration.

Fig1 : Le banc d'essai Demo Hive

Essentiellement, les principaux composants matériels de Demo Hive sont :

• deux SmartPIsun pour chaque travailleur. Ce dispositif est constitué d'une carte d'acquisition pour les mesures électriques (tensions et courants) connectée à un Raspberry Pi 3. Sur la Fig. 1, les deux travailleurs sont les boîtes noires en bas.
• A Raspberry Pi 3 afin de fournir les fonctionnalités de la Reine.
• Un routeur 5G pour fournir la connectivité Internet et un WLAN à l'intérieur du banc d'essai.

Tokenisation de l'énergie :L'un des objectifs les plus significatifs de Demo Hive est de tokeniser l'énergie produite/consommée et de sauvegarder les informations correspondantes sur une blockchain. Pour cette raison, un contrat intelligent conforme à la norme ERC20 a été déployé sur le réseau afin de créer un contrat de démonstration. Ropsten afin de créer un jeton de démonstration, appelé DHTqui a la valeur fixe suivante :

• 1 DHT = 1 cts = 0,01 CHF

L'idée de base de Demo Hive est que LOAD possède une certaine quantité de DHTs et en envoie une partie aux producteurs (typiquement SOLAR, mais aussi le réseau externe à travers QUEEN) pour acheter de l'énergie. Cet aspect sera décrit de manière exhaustive dans le chapitre suivant.Mode de fonctionnement : Unensemble d'applications s'exécute sur les dispositifs susmentionnés pour actionner la plateforme Demo Hive, dont une partie a été développée par Hive Power. Dans cet article, seul le comportement principal du banc d'essai de démonstration sera décrit, en évitant d'expliquer tout le code en détail. L'image suivante rapporte les interactions du logiciel à l'intérieur de la démo et à l'extérieur avec le réseau Ropsten.

Fig 2 : Interactions du logiciel Demo Hive

Comme indiqué dans notre livre blanc, la plateforme Hive réelle enregistre périodiquement les données relatives à l'énergie tokenisée sur une blockchain. C'est assez peu pratique dans un banc d'essai de démonstration car la période peut être trop longue. C'est pourquoi le logiciel de démonstration considère des jours virtuels d'une durée de seulement 10 minutes. Cela signifie que le travailleur SOLAR produit en 10 minutes la même énergie que celle réellement produite en 24 heures. De même, les mesures de puissance, effectuées hors chaîne dans une application réelle et généralement acquises toutes les 15 minutes, sont mesurées toutes les 5 secondes dans Demo Hive. Comme le montre la Fig. 2, pendant la journée virtuelle de 10 minutes, les mesures de puissance sont sauvegardées par les travailleurs de QUEEN (flèches noires) dans une InfluxDB un SGBD orienté séries temporelles couramment utilisé dans les applications de surveillance. Lorsque la journée simulée se termine, les énergies des travailleurs sont calculées et tokenisées dans des DHTs en considérant les tarifs statiques suivants.

• Achat sur le réseau : 20 cts/kWh
• Vente sur le réseau : 5 cts/kWh
• Achetez dans la Ruche : 10 cts/kWh
• Vendre dans la Ruche : 10 cts/kWh

Considérons que le travailleur LOAD/SOLAR peut seulement acheter/vendre de l'énergie. Au contraire, QUEEN, qui gère l'interface avec le réseau, est autorisée à effectuer les deux opérations. À la fin d'une journée simulée, un algorithme de tokenisation tente de maximiser l'autarcie de la ruche en utilisant les règles suivantes (voir aussi Fig. 2):SI 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 :
LOAD achète 𝑬_𝑺𝑶𝑳𝑨𝑹 à SOLAR (10 cts/kWh) et 𝑬_𝑳𝑶𝑨𝑫-𝑬_𝑺𝑶𝑳𝑨𝑹 à QUEEN (20 CHF/kWh)ELSE SI 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 :
SOLAR vend 𝑬_𝑳𝑶𝑨𝑫 à LOAD (10 CHF/kWh) et 𝑬_𝑺𝑶𝑳𝑨𝑹-𝑬_𝑳𝑶𝑨𝑫 à QUEEN (5 CHF/kWh)Pratiquement, les travailleurs échangent toute l'énergie disponible dans la ruche, en exploitant les tarifs les plus avantageux.Ainsi, les énergies sont mises en jetons dans des DHTs et les jetons correspondants (comme écrit précédemment, 1 DHT = 1 cts) sont envoyés par les acheteurs (LOAD ou QUEEN) aux vendeurs (SOLAR ou QUEEN) selon l'algorithme mentionné ci-dessus. Dans la Fig. 2, ces opérations sont représentées par les flèches rouge et bleu clair. Les transferts de DHTs sont ensuite enregistrés sur la blockchain Ropsten. Ceci peut être réalisé car sur chaque dispositif de démonstration, un client maintient un nœud synchronisé avec la blockchain Ropsten. geth client maintient un nœud synchronisé avec le réseau Ethereum testnet. Afin de minimiser l'espace disque nécessaire, les instances de geth exécutent le programme Ethereum protocole client léger. Les comptes Ropsten des composants sont rapportés ci-dessous :

• CHARGER : 0x888d0aafc4d7c95fcaff9264d4bc2c1829a575be
• SOLAR: 0x3b5b6bbF5A14259bdF499f526A51aE7bF21c7476
• QUEEN: 0x7ab0c357cf3ae3c36b7ee8d4a84722a96790a6bd

Simulation results:As explained above, the Demo Hive testbed simulates “virtual” days with a duration of 10 minutes. During a single day the produced/consumed power of the two workers is saved every 5 seconds. At the end of the day (i.e. 10 minutes) the related energies are calculated, tokenized and saved on Ropsten network. In order to have days with both the aforementioned cases of the autarky algorithm (i.e. solar production > load consumption and solar production < load consumption) the following power profiles are taken into account for the workers:

• SOLAIRE : deux profils sont considérés, le premier (ci-après nommé CLEAR) avec une production importante, liée à un jour sans nuages. Le second (nommé CLOUDY par la suite) a une faible production, simulant un jour couvert. La séquence des profils dans les jours simulés est une alternance continue, c'est-à-dire qu'après un jour CLAIR, il y a un jour CLOUDY, et ainsi de suite.
• CHARGE : un profil type unique est pris en compte comme ligne de base, puis chaque jour un bruit est ajouté à celui-ci. Par conséquent, pendant les jours simulés, les profils résultants sont toujours similaires, mais jamais égaux.

La figure 3 montre un exemple de deux jours simulés. Il est simple de noter la différence entre les cas CLEAR et CLOUDY.

Fig 3 : Profils de deux jours simulés (bleu clair : SOLAIRE, jaune foncé : CHARGE)

Les profils présentés dans la figure 3 ont été réalisés lors de la journée de démarrage de l'énergie 2017. Si l'on considère le premier profil (CLEAR), il est facile de comprendre comment la production de SOLAR dépasse la consommation de LOAD. Par conséquent, toute l'énergie nécessaire à LOAD est achetée localement dans la ruche auprès du producteur SOLAR au tarif pratique de la ruche (c'est-à-dire 10 cts/kWh). D'autre part, la quantité restante d'énergie produite non achetée par LOAD sera vendue par SOLAR sur le réseau à un tarif moins avantageux (c'est-à-dire 5 cts/kWh). En agissant comme décrit, l'échange local d'énergie est maximisé et, par conséquent, les deux travailleurs réalisent des économies/profits en profitant des tarifs de la Ruche. Dans le deuxième cas (profil CLOUDY), la production n'est pas capable de couvrir toute la consommation. Dans le second cas (profil CLOUDY), la production n'est pas en mesure de couvrir la totalité de la consommation. Ainsi, LOAD doit acheter une partie de l'énergie nécessaire au réseau en payant 20 cts/kWh. À la fin de la journée simulée, les données relatives aux économies/profits sont ensuite symbolisées et les DHT correspondantes sont distribuées par le consommateur (par exemple LOAD dans un cas CLOUDY) aux producteurs (par exemple SOLAR et QUEEN dans un cas CLOUDY) afin de payer l'énergie utilisée. Dans la liste suivante, les profits/coûts de l'énergie dans les DHT sont présentés en comparant les cas de Demo Hive à une situation de business as usual (BAU), où le marché de la ruche n'existe pas (c'est-à-dire que seuls les tarifs du réseau, 20/5 cts/kWh pour acheter/vendre l'énergie, sont disponibles).

• Revenus solaires :

12:00-12:10 (CLAIR) :
RUCHE = 432 DHT
BAU = 254 DHT
RUCHE-BAU = 178 DHT12:10-12:20 (NUAGEUX) :
RUCHE = 135 DHT
BAU = 68 DHT
RUCHE-BAU = 67 DH

• Coûts de la charge :

12:00-12:10 (CLAIR) :
HIVE = 356 DHT
BAU = 713 DHT
HIVE-BAU = -357 DHT12:10-12:20 (CLOUDY) :
HIVE = 590 DHT
BAU = 725 DHT
HIVE-BAU = -123 DHIl est facile de noter comment l'argent économisé/gagné de LOAD/SOLAR est beaucoup plus élevé pendant le jour CLAIR, étant donné que la production solaire est capable de couvrir toute l'énergie nécessaire à l'intérieur de la ruche. La liste suivante indique les montants précis :

• LOAD économise 3,57 CHF pendant les journées CLEAR
• LOAD économise 1,23 CHF pendant les jours CLOUDY
• SOLAR gagne 1,78 CHF pendant les journées CLEAR
• SOLAR gagne 0,67 CHF pendant les jours CLOUDY

Les URLs suivants rapportent les détails des transactions Ropsten relatives aux jours simulés.

• TX_CLEAR_1 : 356 DHTs envoyés par LOAD à SOLAR
• TX_CLEAR_2 : 76 DHTs envoyés par QUEEN à SOLAR
• TX_CLOUDY_1 : 455 DHTs envoyés par LOAD à QUEEN
• TX_CLOUDY_2 : 135 DHTs envoyés par LOAD à SOLAR

Prochaines étapes :Le banc d'essai Demo Hive met en œuvre un cas très simple de hive. Il constitue un point de départ important pour le développement du cadre complet, mais certaines améliorations doivent être mises en œuvre. La liste suivante présente les fonctionnalités les plus significatives qui restent à développer.

• Prototype d'un compteur "blockchain-ready" : Le dispositif SmartPi est basé sur une carte Raspberry Pi 3, une excellente plateforme matérielle pour le prototypage et les premiers tests mais non projetée pour être facilement intégrée dans un produit industriel. Afin de développer un compteur blockchain, naturellement nécessaire dans notre cadre, l'idée de Hive Power est de prendre en compte des plateformes matérielles plus orientées vers l'industrie et de les utiliser pour remplacer les dispositifs SmartPi.
• Profils de puissance : Actuellement les profils des travailleurs sont assez similaires pendant les "journées simulées" de 10 minutes. En pratique, il y a une alternance précise de jours clairs et de jours couverts pour la production SOLAIRE. En ce qui concerne la CHARGE, chaque jour simulé, un bruit est ajouté au même profil prédéfini. Afin d'obtenir une situation plus réaliste, de nouveaux profils doivent être envisagés (par exemple, deux profils de charge différents, le premier pour les jours ouvrables et le second pour le week-end).
• State channels : dans notre banc d'essai de démonstration, les mesures de puissance sont acquises toutes les 5 secondes et les données correspondantes sont sauvegardées dans une base de données fonctionnant sur QUEEN. Afin d'avoir une approche totalement décentralisée, notre idée est de traiter les données de puissance en utilisant la technologie des State Channels en évitant d'utiliser une base de données locale.
• Plus d'ouvriers : Pour avoir une simulation plus réaliste d'un marché de l'énergie de la Ruche, le nombre de travailleurs devrait être augmenté.
• Prosommateur/Stockeur : Actuellement, il n'y a dans Demo Hive qu'un consommateur (LOAD) et un producteur (SOLAR), il sera utile d'introduire des prosommateurs et des travailleurs de stockage afin d'avoir un marché complet. Il est intéressant de considérer qu'avec les systèmes de stockage, il serait possible d'implémenter des algorithmes de transfert de charge pour maximiser les économies de coûts.
• Tarifs dynamiques : Dans Demo Hive, seuls les tarifs statiques sont pris en compte pour l'achat/la vente d'énergie. Il est clair que ce n'est pas une situation réaliste et qu'il faut donc mettre en place un système de tarifs dynamiques.

‍