Als gevolg van de verwachte aanzienlijke toename van stochastische opwekking in het elektriciteitsnet, zal de behoefte aan flexibiliteit en coördinatie aan de vraagzijde naar verwachting toenemen. Gedecentraliseerde energiemarkten behoren tot de meest veelbelovende oplossingen om de coördinatie tussen productie en consumptie te stimuleren, door zelfs kleine actoren in staat te stellen hun flexibiliteit te benutten. Het hoofddoel van Hive Power is het ontwikkelen van een blockchain-gebaseerd platform om groepen prosumenten te ondersteunen die hun eigen energiemarkt willen creëren. Het kernelement van dit raamwerk is de zogenaamde Hive, d.w.z. een implementatie van een energiemarkt gebaseerd op blockchain technologie (zie onze whitepaper op hivepower.tech voor gedetailleerde informatie over het Hive Power platform).Dit artikel beschrijft Demo Hive, het eerste testbed ontwikkeld door ons team en gepresenteerd tijdens de Energy Startup Day 2017 in Zurich, Zwitserland op 30 november 2017. Praktisch gezien is de demo een eenvoudig maar ook betekenisvol geval van een bijenkorf; hij wordt gevormd door een producent en een consument, de zogenaamde werkers. Een derde element is de QUEEN, die tot doel heeft de interactie tussen de werkers en het externe net te beheren en de metingen in verband met de door de werkers verbruikte/geproduceerde stroom te volgen. De producent, hierna SOLAR genoemd, simuleert een fotovoltaïsche installatie met een nominaal vermogen van 5 kWp. De andere werker(LOAD) genereert daarentegen gegevens over een verbruik van de belasting. Fig. 1 toont het demo-testbed.

Fig1: Het Demo Hive testbed

De belangrijkste hardwarecomponenten van Demo Hive zijn:

• twee SmartPIséén voor elke arbeider. Dit apparaat bestaat uit een acquisitiebord voor de elektrische metingen (spanningen en stromen) dat is aangesloten op een Raspberry Pi 3. In fig. 1 zijn de twee werkers de zwarte dozen aan de onderkant.
• A Raspberry Pi 3 om de Queen functionaliteiten te bieden.
• Een 5G-router voor de internetverbinding en een WLAN binnen het testbed.

Energie tokenization:Een van de meest zinvolle doelen van Demo Hive is het tokenizeren van de geproduceerde/verbruikte energie en het opslaan van de gerelateerde informatie op een blockchain. Om die reden werd een ERC20-compliant smart contract ingezet op het Ropsten netwerk om een demo token te creëren, genaamd DHTdie de volgende vaste waarde heeft:

• 1 DHT = 1 cts = 0.01 CHF

Het basisidee van Demo Hive is dat LOAD een bepaalde hoeveelheid DHT's bezit en een deel daarvan naar de producenten stuurt (meestal SOLAR, maar ook het externe net via QUEEN) om energie te kopen. In het volgende hoofdstuk zullen deze aspecten uitvoerig worden beschreven.Werkingsmodus:Op de voornoemde apparaten draaiteenreeks toepassingen om het Demo Hive-platform te bedienen, waarvan een deel is ontwikkeld door Hive Power. In dit artikel zal enkel het hoofdgedrag van de demo testbed worden beschreven, waarbij vermeden wordt om alle code in detail uit te leggen. De volgende afbeelding rapporteert de software interacties binnen de demo en buiten met het Ropsten netwerk.

Fig 2: Demo Hive software interacties

Zoals geschreven in onze whitepaper, zal het echte Hive platform periodiek gegevens over de getoken energie opslaan op een blockchain. Dit is nogal onhandig in een demo testbed omdat de periode te lang kan zijn. Om die reden beschouwt de demo software virtuele dagen met een duur van slechts 10 minuten. Dit betekent dat de SOLAR-werker in 10 minuten dezelfde energie produceert die werkelijk in 24 uur wordt geproduceerd. Op dezelfde manier worden de vermogensmetingen, die in een echte toepassing buiten de keten worden uitgevoerd en gewoonlijk om de 15 minuten worden uitgevoerd, in Demo Hive om de 5 seconden gemeten. Zoals te zien is in Fig. 2, worden gedurende de virtuele dag van 10 minuten de energiemetingen door de werkers in QUEEN (zwarte pijlen) opgeslagen in een InfluxDB database, een tijdreeksgeoriënteerd DBMS dat vaak wordt gebruikt in monitoringstoepassingen. Wanneer de gesimuleerde dag eindigt, worden de energieën van de werkers berekend en getokenized in DHTs, rekening houdend met de volgende statische tarieven.

• Koop op het net: 20 cts/kWh
• Verkoop aan het net: 5 cts/kWh
• Koop in de korf: 10 cts/kWh
• Verkoop in de korf: 10 cts/kWh

Bedenk dat LOAD/SOLAR worker alleen energie kan kopen/verkopen. In plaats daarvan mag QUEEN, die de interface met het net beheert, beide operaties uitvoeren. Aan het eind van een gesimuleerde dag probeert een tokenization algoritme de autarkie van de korf te maximaliseren aan de hand van de volgende regels (zie ook Fig. 2):IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 :
LOAD koopt 𝑬_𝑺𝑶𝑳𝑨𝑹 van SOLAR (10 cts/kWh) en 𝑬_𝑳𝑶𝑨𝑫-𝑬_𝑺𝑶𝑳𝑨𝑹 van QUEEN (20 CHF/kWh)ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 :
SOLAR verkoopt 𝑬_𝑳𝑶𝑨𝑫 aan LOAD (10 CHF/kWh) en 𝑬_𝑺𝑶𝑳𝑨𝑹-𝑬_𝑳𝑶𝑨𝑫 aan QUEEN (5 CHF/kWh)Praktisch gezien wisselen de werkers alle beschikbare energie in de bijenkorf uit, gebruik makend van de gunstigste tarieven.De energie wordt dus getokeniseerd in DHTs en de bijbehorende tokens (zoals eerder geschreven, 1 DHT = 1 cts) worden door kopers (LOAD of QUEEN) naar verkopers (SOLAR of QUEEN) gestuurd volgens het eerder genoemde algoritme. In fig. 2 worden deze operaties voorgesteld door de rode en lichtblauwe pijlen. De overdrachten van de DHT's worden vervolgens opgeslagen op de Ropsten blockchain. Dit kan worden uitgevoerd omdat op elk demo-apparaat een geth client een node onderhoudt die gesynchroniseerd is met het Ethereum testnet netwerk. Om de benodigde schijfruimte te minimaliseren, draaien de geth instances de Ethereum licht client-protocol. De Ropsten-rekeningen van de componenten worden hieronder gerapporteerd:

• LAD: 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: er worden twee profielen in aanmerking genomen, het eerste (hierna CLEAR genoemd) met een aanzienlijke productie, gerelateerd aan een dag zonder bewolking. Het tweede profiel (hierna CLOUDY genoemd) heeft daarentegen een geringe productie en simuleert een dag met bewolking. De opeenvolging van de profielen in de gesimuleerde dagen is een continue afwisseling, d.w.z. na een CLEAR-dag volgt een CLOUDY-dag, enzovoort.
• LOAD: een uniek typisch profiel wordt als basislijn genomen, en vervolgens wordt er elke dag een ruis aan toegevoegd. Als gevolg daarvan zijn de resulterende profielen tijdens de gesimuleerde dagen altijd gelijk, maar nooit gelijk.

Fig. 3 toont een voorbeeld van twee gesimuleerde dagen. Het verschil tussen de CLEAR en CLOUDY gevallen is eenvoudig op te merken.

Fig. 3: Profielen van twee gesimuleerde dagen (lichtblauw: SOLAR, donkergeel: LOAD)

De in Fig. 3 getoonde profielen werden uitgevoerd tijdens de Energy Startup Day 2017. Als we het eerste profiel (CLEAR) bekijken, is het eenvoudig te begrijpen hoe de SOLAR-productie het verbruik van LOAD overschrijdt. Als gevolg hiervan wordt alle energie die LOAD nodig heeft, lokaal in de korf gekocht van SOLAR-producent tegen het gunstige Hive-tarief (d.w.z. 10 cts/kWh). Anderzijds wordt de resterende hoeveelheid geproduceerde energie die niet door LOAD wordt gekocht, door SOLAR aan het net verkocht tegen een minder gunstig tarief (d.w.z. 5 cts/kWh). In het tweede geval (CLOUDY profiel) is de productie niet in staat het volledige verbruik te dekken. Aan het einde van de gesimuleerde dag worden de besparingen/winsten getokeniseerd en de bijbehorende DHT's verdeeld door de consument (bijv. LOAD in een CLOUDY geval) aan de producenten (bijv. SOLAR en QUEEN in een CLOUDY geval) om de verbruikte energie te betalen. In de volgende lijst worden de energiewinsten/kosten in DHT's gerapporteerd, waarbij de gevallen van Demo Hive worden vergeleken met een "business as usual"-situatie (BAU), waarin de markt voor bijenkasten niet bestaat (d.w.z. dat alleen de nettarieven, 20/5 cts/kWh om energie te kopen/verkopen, beschikbaar zijn).

• Zonne-inkomsten:

12:00-12:10 (HELDER):
BIJENKAST = 432 DHT
BAU = 254 DHT
BIJENKAST-BAU = 178 DHT12:10-12:20 (BEWOLKT):
BIJENKAST = 135 DHT
BAU = 68 DHT
BIJENKAST-BAU = 67 DH

• Lasten:

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 DHHet is gemakkelijk te zien hoe het bespaarde/verdiende geld van LOAD/SOLAR veel hoger is gedurende de CLEAR dag, daar de zonneproductie in staat is alle energie te dekken die in de bijenkast nodig is. De volgende lijst geeft de precieze bedragen:

• LOAD bespaart 3,57 CHF tijdens CLEAR dagen
• LOAD bespaart 1,23 CHF tijdens CLOUDY dagen
• SOLAR verdient 1,78 CHF tijdens CLEAR-dagen
• SOLAR verdient 0,67 CHF tijdens CLOUDY dagen

De volgende URL's geven de details weer van de Ropsten-transacties met betrekking tot de gesimuleerde dagen.

• TX_CLEAR_1: 356 DHT's verzonden door LOAD naar SOLAR
• TX_CLEAR_2: 76 DHT's verzonden door QUEEN naar SOLAR
• TX_CLOUDY_1: 455 DHT's verzonden door LOAD naar QUEEN
• TX_CLOUDY_2: 135 DHT's verzonden door LOAD naar SOLAR

Volgende stappen:Het Demo Hive testbed implementeert een zeer eenvoudig geval van Hive. Het is een belangrijk startpunt voor de ontwikkeling van het volledige raamwerk, maar er moeten nog enkele verbeteringen worden doorgevoerd. De volgende lijst vermeldt de meest betekenisvolle functies die nog moeten worden ontwikkeld.

• Prototype van een "blockchain-ready" meter: Het SmartPi apparaat is gebaseerd op een Raspberry Pi 3 board, een geweldig hardware platform voor prototyping en initiële tests, maar niet geprojecteerd om gemakkelijk geïntegreerd te worden in een industrieel product. Om een blockchain-meter te ontwikkelen, wat natuurlijk noodzakelijk is in ons kader, is het idee van Hive Power om rekening te houden met meer industrieel georiënteerde hardwareplatforms en deze te gebruiken ter vervanging van de SmartPi-apparaten.
• Vermogensprofielen: Momenteel zijn de arbeidsprofielen tijdens de "gesimuleerde dagen" van 10 minuten vrij gelijklopend. In de praktijk is er een nauwkeurige afwisseling van heldere en bewolkte dagen voor de SOLAR-productie. Wat de LOAD betreft, wordt elke gesimuleerde dag een ruis toegevoegd aan hetzelfde voorgedefinieerde profiel. Om een meer realistische situatie te verkrijgen, moeten nieuwe profielen worden overwogen (b.v. twee verschillende LOAD-profielen, het eerste voor werkdagen en het tweede voor het weekend)
• State channels: in ons demo-testbed worden de vermogensmetingen nu elke 5 seconden verzameld en de bijbehorende gegevens opgeslagen in een database die draait op QUEEN. Om een volledig gedecentraliseerde aanpak te hebben, is het ons idee om de vermogensgegevens te behandelen met behulp van State Channels technologie en daarbij het gebruik van een lokale database te vermijden.
• Meer werkers: Voor een realistischer simulatie van een Hive-energiemarkt moet het aantal werkers worden verhoogd.
• Prosumer/opslagwerker: Op dit moment zijn er in Demo Hive alleen een consument (LOAD) en een producent (SOLAR), het zal zinvol zijn om prosumer en storage workers te introduceren om een volledige markt te hebben. Het is interessant om te overwegen dat het met opslagsystemen mogelijk zou zijn om load-shifting algoritmen te implementeren om de kostenbesparingen te maximaliseren.
• Dynamische tarieven: In Demo Hive wordt alleen rekening gehouden met statische tarieven voor de inkoop/verkoop van energie. Het is duidelijk dat dit geen realistische situatie is en dat derhalve een dynamisch tariefsysteem moet worden ingevoerd.

‍