Als Folge der voraussichtlichen erheblichen Zunahme der stochastischen Erzeugung im Stromnetz wird der Bedarf an Flexibilität und Koordinierung auf der Nachfrageseite voraussichtlich steigen. Dezentrale Energiemärkte gehören zu den vielversprechendsten Lösungen, die eine bessere Koordinierung von Erzeugung und Verbrauch ermöglichen, indem sie auch kleinen Akteuren die Möglichkeit geben, ihre Flexibilität zu nutzen. Das Hauptziel von Hive Power ist die Entwicklung einer Blockchain-basierten Plattform zur Unterstützung von Gruppen von Prosumenten, die ihren eigenen Energiemarkt schaffen wollen. Das Kernelement dieses Frameworks ist der sogenannte Hive, d.h. eine Implementierung eines Energiemarktes, der auf der Blockchain-Technologie basiert (siehe unser Whitepaper auf hivepower.tech, um detaillierte Informationen über die Hive Power-Plattform zu erhalten).Dieser Artikel beschreibt Demo Hive, das erste Testbed, das von unserem Team entwickelt und während des Energy Startup Day 2017 in Zürich, Schweiz, am 30. November 2017 vorgestellt wurde. Praktisch ist die Demo ein einfacher, aber auch aussagekräftiger Fall eines Bienenstocks; er besteht aus einem Produzenten und einem Konsumenten, den sogenannten Arbeitern. Ein drittes Element ist die QUEEN, deren Aufgabe es ist, die Interaktion zwischen den Arbeitern und dem externen Netz zu verwalten und die Messungen im Zusammenhang mit der von den Arbeitern verbrauchten/produzierten Energie zu verfolgen. Der Erzeuger, im Folgenden SOLAR genannt, simuliert eine Photovoltaikanlage mit einer Nennleistung von 5 kWp. Der andere Worker(LOAD) hingegen erzeugt Daten über einen Lastverbrauch. Abb. 1 zeigt das Demo-Testbed.

Abb. 1: Die Demo-Hive-Testumgebung

Die wichtigsten Hardwarekomponenten von Demo Hive sind:

• zwei SmartPIs, eine für jeden Arbeiter. Dieses Gerät besteht aus einer Erfassungskarte für die elektrischen Messungen (Spannungen und Ströme), die an einen Raspberry Pi 3 angeschlossen ist. In Abb. 1 sind die beiden Arbeiter die schwarzen Kästen am unteren Rand.
• A Raspberry Pi 3 um die Funktionalitäten der Königin bereitzustellen.
• Ein 5G-Router für die Internetverbindung und ein WLAN innerhalb des Testfelds.

Energie-Tokenisierung:Eines der wichtigsten Ziele von Demo Hive ist die Tokenisierung der produzierten/verbrauchten Energie und die Speicherung der entsprechenden Informationen auf einer Blockchain. Aus diesem Grund wurde ein ERC20-kompatibler Smart Contract im Ropsten Netzwerk eingesetzt, um einen Demo-Token mit der Bezeichnung DHTzu erstellen, der den folgenden festen Wert hat:

• 1 DHT = 1 cts = 0,01 CHF

Die Grundidee von Demo Hive ist, dass LOAD eine bestimmte Menge an DHTs besitzt und einen Teil davon an die Erzeuger (in der Regel SOLAR, aber auch das externe Netz durch QUEEN) sendet, um Energie zu kaufen. Im folgenden Kapitel werden diese Aspekte ausführlich beschrieben.Betriebsmodus: EineReihe von Anwendungen läuft auf den oben genannten Geräten, um die Demo Hive Plattform zu betreiben, ein Teil davon wurde von Hive Power entwickelt. In diesem Artikel wird nur das Hauptverhalten des Demo-Testbeds beschrieben, ohne den gesamten Code im Detail zu erläutern. Das folgende Bild zeigt die Software-Interaktionen innerhalb der Demo und außerhalb mit dem Ropsten-Netzwerk.

Abb. 2: Demo Hive Software-Interaktionen

Wie in unserem Whitepaper beschrieben, speichert die echte Hive-Plattform in regelmäßigen Abständen Daten über die tokenisierte Energie auf einer Blockchain. Dies ist in einem Demo-Testbed recht unpraktisch, da der Zeitraum zu lang sein kann. Aus diesem Grund berücksichtigt die Demosoftware virtuelle Tage mit einer Dauer von nur 10 Minuten. Das bedeutet, dass der SOLAR-Arbeiter in 10 Minuten die gleiche Energie produziert, die er in 24 Stunden tatsächlich erzeugt. In ähnlicher Weise werden die Leistungsmessungen, die in einer realen Anwendung außerhalb der Kette durchgeführt und normalerweise alle 15 Minuten erfasst werden, in Demo Hive alle 5 Sekunden gemessen. Wie in Abb. 2 dargestellt, werden die Leistungsmessungen während des virtuellen 10-Minuten-Tages von den Arbeitern in QUEEN (schwarze Pfeile) in einer InfluxDB Datenbank gespeichert, einem zeitserienorientierten DBMS, das üblicherweise in Überwachungsanwendungen verwendet wird. Wenn der simulierte Tag endet, werden die Energien der Arbeiter berechnet und in DHTs unter Berücksichtigung der folgenden statischen Tarife in Token umgewandelt.

• Kauf im Netz: 20 cts/kWh
• Verkauf ins Netz: 5 cts/kWh
• Im Bienenstock kaufen: 10 ct/kWh
• Im Bienenstock verkaufen: 10 ct/kWh

Man bedenke, dass der LOAD/SOLAR-Arbeiter nur Energie kaufen/verkaufen kann. Stattdessen darf QUEEN, die die Schnittstelle zum Netz verwaltet, beide Operationen durchführen. Am Ende eines simulierten Tages versucht ein Tokenisierungsalgorithmus, die Autarkie des Bienenstocks anhand der folgenden Regeln zu maximieren (siehe auch Abb. 2) 2):IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 :
LOAD kauft 𝑬_𝑺𝑶𝑳𝑨𝑹 von SOLAR (10 cts/kWh) und 𝑬_𝑳𝑶𝑨𝑫-𝑬_𝑺𝑶𝑳𝑨𝑹 von QUEEN (20 CHF/kWh)ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 :
SOLAR verkauft 𝑬_𝑳𝑶𝑨𝑫 an LOAD (10 CHF/kWh) und 𝑬_𝑺𝑶𝑳𝑨𝑹-𝑬_𝑳𝑶𝑨𝑫 an QUEEN (5 CHF/kWh)Praktisch tauschen die Arbeiterinnen die gesamte im Bienenstock verfügbare Energie aus und nutzen dabei die günstigeren Tarife.Die Energie wird in DHTs gespeichert, und die entsprechenden Token (wie bereits erwähnt, 1 DHT = 1 cts) werden von den Käufern (LOAD oder QUEEN) an die Verkäufer (SOLAR oder QUEEN) nach dem oben beschriebenen Algorithmus gesendet. In Abb. 2 sind diese Vorgänge durch die roten und hellblauen Pfeile dargestellt. Die DHTs-Transfers werden dann in der Ropsten-Blockchain gespeichert. Dies ist möglich, weil auf jedem Demo-Gerät ein geth Client einen Knoten unterhält, der mit dem Ethereum-Testnet-Netzwerk synchronisiert ist. Um den benötigten Speicherplatz zu minimieren, führen die geth-Instanzen das Ethereum Light-Client-Protokoll. Die Ropsten-Konten der Komponenten sind unten aufgeführt:

• LOAD: 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:

• SOLAR: Es werden zwei Profile betrachtet, wobei das erste (im Folgenden CLEAR genannt) eine hohe Produktion aufweist, die einem wolkenlosen Tag entspricht. Das zweite Profil (im Folgenden CLOUDY genannt) hingegen hat eine schwache Produktion und simuliert einen bewölkten Tag. Die Abfolge der Profile in den simulierten Tagen ist ein kontinuierlicher Wechsel, d. h. auf einen CLEAR-Tag folgt ein CLOUDY-Tag usw.
• LOAD: Ein einziges typisches Profil wird als Basislinie berücksichtigt, zu dem dann jeden Tag ein Rauschen hinzugefügt wird. Infolgedessen sind die resultierenden Profile während der simulierten Tage immer ähnlich, aber nie gleich.

Abb. 3 zeigt ein Beispiel für zwei simulierte Tage. Der Unterschied zwischen den Fällen CLEAR und CLOUDY ist leicht zu erkennen.

Abb. 3: Profile von zwei simulierten Tagen (hellblau: SOLAR, dunkelgelb: LOAD)

Die in Abb. 3 gezeigten Profile wurden während des Energy Startup Day 2017 erstellt. Beim ersten Profil (CLEAR) ist leicht zu erkennen, dass die SOLAR-Produktion den LOAD-Verbrauch übersteigt. Folglich wird die gesamte von LOAD benötigte Energie lokal im Bienenstock vom SOLAR-Produzenten zum günstigen Hive-Tarif (d. h. 10 cts/kWh) gekauft. Die verbleibende Menge an erzeugter Energie, die nicht von LOAD gekauft wird, wird von SOLAR zu einem weniger günstigen Tarif (d.h. 5 cts/kWh) an das Netz verkauft. Auf diese Weise wird der lokale Energieaustausch maximiert, so dass die beiden Arbeiter durch die Nutzung der Hive-Tarife Geld sparen/gewinnen.Im zweiten Fall (Profil CLOUDY) kann die Produktion nicht den gesamten Verbrauch decken. Am Ende des simulierten Tages werden die Einsparungen/Gewinne in Token umgewandelt und die entsprechenden DHTs vom Verbraucher (z.B. LOAD im CLOUDY-Fall) an die Erzeuger (z.B. SOLAR und QUEEN im CLOUDY-Fall) verteilt, um die verbrauchte Energie zu bezahlen. In der folgenden Liste werden die Energiegewinne/-kosten in DHTs angegeben, wobei die Fälle des Demo-Hive mit einer Business-as-usual-Situation (BAU) verglichen werden, in der der Hive-Markt nicht existiert (d. h. nur die Netztarife, 20/5 cts/kWh für den Kauf/Verkauf von Energie, sind verfügbar).

• Solareinnahmen:

12:00-12:10 (KLAR):
BIENENSTOCK = 432 DHT
BAU = 254 DHT
BIENENSTOCK-BAU = 178 DHT12:10-12:20 (BEWÖLKT):
BIENENSTOCK = 135 DHT
BAU = 68 DHT
BIENENSTOCK-BAU = 67 DH

• Kosten der Belastung:

12:00-12:10 (CLEAR):
HIVE = 356 DHT
BAU = 713 DHT
HIVE-BAU = -357 DHT12:10-12:20 (CLOUDY):
HIVE = 590 DHT
BAU = 725 DHT
HIVE-BAU = -123 DHEs ist leicht festzustellen, dass die Ersparnisse/Erträge von LOAD/SOLAR während des CLEAR-Tages viel höher sind, da die Solarproduktion in der Lage ist, den gesamten Energiebedarf im Bienenstock zu decken. In der folgenden Liste sind die genauen Beträge aufgeführt:

• LOAD spart 3,57 CHF während der CLEAR-Tage
• LOAD spart 1,23 CHF während CLOUDY-Tagen
• SOLAR nimmt während der CLEAR-Tage 1,78 CHF ein
• SOLAR verdient 0,67 CHF während CLOUDY-Tagen

Die folgenden URLs zeigen die Details der Ropsten-Transaktionen für die simulierten Tage.

• TX_CLEAR_1: 356 DHTs von LOAD an SOLAR gesendet
• TX_CLEAR_2: 76 DHTs von QUEEN an SOLAR gesendet
• TX_CLOUDY_1: 455 DHTs von LOAD an QUEEN gesendet
• TX_CLOUDY_2: 135 DHTs gesendet von LOAD an SOLAR

Nächste Schritte:Das Demo Hive Testbed implementiert einen sehr einfachen Fall von Hive. Es ist ein wichtiger Ausgangspunkt für die Entwicklung des kompletten Frameworks, aber einige Verbesserungen müssen noch implementiert werden. In der folgenden Liste sind die wichtigsten noch zu entwickelnden Funktionen aufgeführt.

• Prototyp eines "Blockchain-fähigen" Zählers: Das SmartPi-Gerät basiert auf einem Raspberry Pi 3-Board, einer großartigen Hardware-Plattform für Prototypen und erste Tests, die jedoch nicht ohne weiteres in ein industrielles Produkt integriert werden kann. Um einen Blockchain-Zähler zu entwickeln, der in unserem Rahmen natürlich notwendig ist, besteht die Idee von Hive Power darin, industrietauglichere Hardware-Plattformen zu berücksichtigen und sie als Ersatz für die SmartPi-Geräte zu verwenden.
• Leistungsprofile: Derzeit sind die Profile der Arbeiter während der "simulierten Tage" von 10 Minuten recht ähnlich. Praktisch gibt es einen genauen Wechsel von klaren und bewölkten Tagen für die SOLAR-Produktion. Was die LAST betrifft, so wird an jedem simulierten Tag ein Rauschen zu demselben vordefinierten Profil hinzugefügt. Um eine realistischere Situation zu erhalten, müssen neue Profile in Betracht gezogen werden (z. B. zwei verschiedene LOAD-Profile, das erste für Werktage und das zweite für das Wochenende)
• State Channels: In unserem Demo-Testbed werden die Leistungsmessungen nun alle 5 Sekunden erfasst und die zugehörigen Daten in einer auf QUEEN laufenden Datenbank gespeichert. Um einen vollständig dezentralisierten Ansatz zu haben, besteht unsere Idee darin, die Leistungsdaten mit Hilfe der State-Channels-Technologie zu verarbeiten und die Verwendung einer lokalen Datenbank zu vermeiden.
• Mehr Arbeiter: Um eine realistischere Simulation eines Hive-Energiemarktes zu erhalten, sollte die Anzahl der Arbeiter erhöht werden.
• Prosumer/Speicherarbeiter: Da es in Demo Hive derzeit nur einen Konsumenten (LOAD) und einen Produzenten (SOLAR) gibt, wird es sinnvoll sein, Prosumer und Storage Worker einzuführen, um einen vollständigen Markt zu haben. Interessant ist, dass es bei Speichersystemen möglich wäre, Lastverschiebungsalgorithmen zu implementieren, um die Kosteneinsparungen zu maximieren.
• Dynamische Tarife: In Demo Hive werden nur statische Tarife für den Energieeinkauf/-verkauf berücksichtigt. Dies ist natürlich keine realistische Situation und daher muss ein dynamisches Tarifsystem eingeführt werden.

‍