Come conseguenza del previsto aumento significativo della generazione stocastica nella rete elettrica, la necessità di flessibilità e coordinamento sul lato della domanda è destinata ad aumentare. I mercati energetici decentralizzati sono tra le soluzioni più promettenti che permettono di aumentare il coordinamento tra produzione e consumo, permettendo anche ai piccoli attori di capitalizzare la loro flessibilità. Lo scopo principale di Hive Power è quello di sviluppare una piattaforma basata su blockchain per supportare gruppi di prosumer che vogliono creare il proprio mercato energetico. L'elemento centrale di questo framework è il cosiddetto Hive, cioè un'implementazione di un mercato dell'energia basato sulla tecnologia blockchain (vedi il nostro white paper su hivepower.tech per avere informazioni dettagliate sulla piattaforma Hive Power).Questo articolo descrive Demo Hive, il primo testbed sviluppato dal nostro team e presentato durante l'Energy Startup Day 2017 a Zurigo, Svizzera il 30 novembre 2017. In pratica, la demo è un caso semplice ma anche significativo di un alveare; è costituito da un produttore e un consumatore, i cosiddetti lavoratori. Un terzo elemento è il QUEEN, il cui scopo è quello di gestire l'interazione tra i lavoratori e la rete esterna e di tracciare le misure relative alla potenza consumata/prodotta dai lavoratori. Il produttore, di seguito denominato SOLAR, simula un impianto fotovoltaico con una potenza nominale di 5 kWp. L'altro lavoratore(LOAD) genera invece i dati relativi al consumo di un carico. La Fig. 1 mostra il testbed dimostrativo.

Fig1: Il banco di prova Demo Hive

Essenzialmente, i principali componenti hardware di Demo Hive sono:

• due SmartPIsuno per ogni lavoratore. Questo dispositivo è costituito da una scheda di acquisizione per le misure elettriche (tensioni e correnti) collegata a un Raspberry Pi 3. Nella Fig. 1 i due lavoratori sono le scatole nere in basso.
• A Raspberry Pi 3 per fornire le funzionalità della regina.
• Un router 5G per fornire la connettività Internet e una WLAN all'interno del testbed.

Totalizzazione dell'energia:Uno degli obiettivi più significativi di Demo Hive è quello di citare l'energia prodotta/consumata e di salvare le relative informazioni su una blockchain. Per questo motivo uno smart contract conforme a ERC20 è stato distribuito sulla Ropsten al fine di creare un token demo, chiamato DHTche ha il seguente valore fisso:

• 1 DHT = 1 cts = 0,01 CHF

L'idea di base di Demo Hive è che LOAD possiede una certa quantità di DHT e ne invia una parte ai produttori (tipicamente SOLAR, ma anche la rete esterna attraverso QUEEN) per comprare energia. Nel capitolo seguente questi aspetti saranno descritti in modo esaustivo.Modalità di funzionamento: uninsieme di applicazioni gira sui dispositivi sopra menzionati per attuare la piattaforma Demo Hive, una parte di esse sviluppate da Hive Power. In questo articolo verrà descritto solo il comportamento principale del testbed demo, evitando di spiegare tutto il codice in dettaglio. L'immagine seguente riporta le interazioni del software all'interno del demo e all'esterno con la rete Ropsten.

Fig 2: Interazioni del software Hive demo

Come scritto nel nostro whitepaper, periodicamente la vera piattaforma Hive salverà i dati sull'energia tokenizzata su una blockchain. Questo è abbastanza scomodo in un testbed demo perché il periodo può essere troppo lungo. Per questo motivo il software demo considera giorni virtuali con una durata di soli 10 minuti. Questo significa che il lavoratore SOLAR produce in 10 minuti la stessa energia realmente eseguita in 24 ore. Allo stesso modo le misure di potenza, in un'applicazione reale eseguite fuori dalla catena e solitamente acquisite ogni 15 minuti, in Demo Hive sono misurate ogni 5 secondi. Come mostrato in Fig. 2, durante la giornata virtuale di 10 minuti le misure di potenza sono salvate dai lavoratori in QUEEN (frecce nere) in un InfluxDB database, un DBMS orientato alle serie temporali comunemente usato nelle applicazioni di monitoraggio. Quando la giornata simulata finisce, le energie dei lavoratori sono calcolate e tokenizzate in DHTs considerando le seguenti tariffe statiche.

• Comprare in rete: 20 cts/kWh
• Vendere alla rete: 5 cts/kWh
• Comprare nell'alveare: 10 cts/kWh
• Vendere nell'alveare: 10 cts/kWh

Consideriamo che il lavoratore LOAD/SOLAR può solo comprare/vendere energia. Invece QUEEN, che gestisce l'interfaccia con la rete, è autorizzato ad eseguire entrambe le operazioni. Alla fine di una giornata simulata un algoritmo di tokenization cerca di massimizzare l'autarchia dell'alveare usando le seguenti regole (vedi anche Fig. 2):IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 :
LOAD compra 𝑬_𝑺𝑶𝑳𝑨𝑹 da SOLAR (10 cts/kWh) e 𝑬_𝑳𝑶𝑨𝑫-𝑬_𝑺𝑶𝑳𝑨𝑹 da QUEEN (20 CHF/kWh)ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 :
SOLAR vende 𝑬_𝑳𝑶𝑨𝑫 a LOAD (10 CHF/kWh) e 𝑬_𝑺𝑶𝑳𝑨𝑹-𝑬_𝑳𝑶𝑨𝑫 a QUEEN (5 CHF/kWh)In pratica i lavoratori si scambiano tutta l'energia disponibile nell'alveare, sfruttando le tariffe più convenienti.Quindi, le energie vengono tokenizzate in DHT e i relativi token (come scritto prima, 1 DHT = 1 cts) inviati dai compratori (LOAD o QUEEN) ai venditori (SOLAR o QUEEN) secondo l'algoritmo di cui sopra. Nella Fig. 2 queste operazioni sono rappresentate dalle frecce rosse e azzurre. I trasferimenti DHTs vengono poi salvati sulla blockchain di Ropsten. Questo può essere eseguito perché su ogni dispositivo demo un geth client mantiene un nodo sincronizzato alla rete Ethereum testnet. Al fine di ridurre al minimo lo spazio su disco richiesto, le istanze geth eseguono l'Ethereum protocollo client leggero. I conti Ropsten dei componenti sono riportati di seguito:

• CARICO: 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: vengono considerati due profili, il primo (di seguito denominato CLEAR) con una produzione significativa, relativa ad una giornata senza nuvole. Invece il secondo (di seguito denominato CLOUDY) ha una produzione scarsa, simulando una giornata nuvolosa. La sequenza dei profili nei giorni simulati è un'alternanza continua, cioè dopo un giorno CLEAR ce n'è uno CLOUDY, e così via.
• LOAD: un unico profilo tipico viene preso in considerazione come linea di base, poi ogni giorno viene aggiunto un rumore ad esso. Di conseguenza, durante i giorni simulati i profili risultanti sono sempre simili, ma mai uguali.

La Fig. 3 mostra un esempio di due giorni simulati. È semplice notare la differenza tra i casi CLEAR e CLOUDY.

Fig. 3: Profili di due giorni simulati (blu chiaro: SOLAR, giallo scuro: LOAD)

I profili mostrati in Fig. 3 sono stati eseguiti durante l'Energy Startup Day 2017. Considerando il primo profilo (CLEAR), è semplice capire come la produzione SOLAR superi il consumo di LOAD. Di conseguenza, tutta l'energia necessaria al LOAD viene acquistata localmente nell'alveare dal produttore SOLAR alla conveniente tariffa Hive (cioè 10 cts/kWh). D'altra parte, la quantità rimanente di energia prodotta non acquistata da LOAD sarà venduta da SOLAR sulla rete con una tariffa meno conveniente (cioè 5 cts/kWh). Agendo come descritto, lo scambio locale di energia è massimizzato e, di conseguenza, i due lavoratori realizzano un risparmio/profitto approfittando delle tariffe dell'Alveare.Nel secondo caso (profilo CLOUDY), la produzione non è in grado di coprire tutto il consumo. Così, LOAD deve comprare parte dell'energia necessaria dalla rete pagando 20 cts/kWh.Alla fine della giornata simulata i dati di risparmio/profitto sono poi tokenizzati e i relativi DHTs distribuiti dal consumatore (es. LOAD in un caso CLOUDY) ai produttori (es. SOLAR e QUEEN in un caso CLOUDY) per pagare l'energia utilizzata. Nel seguente elenco i profitti/costi energetici in DHT sono riportati confrontando i casi di Demo Hive contro una situazione di business as usual (BAU), dove il mercato dell'alveare non esiste (cioè sono disponibili solo le tariffe di rete, 20/5 cts/kWh per comprare/vendere energia).

• Entrate solari:

12:00-12:10 (CHIARO):
ALVEARE = 432 DHT
BAU = 254 DHT
ALVEARE-BAU = 178 DHT12:10-12:20 (NUVOLOSO):
ALVEARE = 135 DHT
BAU = 68 DHT
ALVEARE-BAU = 67 DH

• Costi di carico:

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 DHÈ facile notare come il risparmio/guadagno di LOAD/SOLAR sia molto più alto durante la giornata CLEAR, essendo la produzione solare in grado di coprire tutta l'energia necessaria all'interno dell'arnia. La seguente lista riporta gli importi precisi:

• LOAD risparmia 3,57 CHF durante i giorni di CLEAR
• LOAD risparmia 1,23 CHF durante i giorni di CLOUDY
• SOLAR guadagna 1,78 CHF durante le giornate CLEAR
• SOLAR guadagna 0,67 CHF durante i giorni CLOUDY

I seguenti URL riportano i dettagli delle transazioni Ropsten relative ai giorni simulati.

• TX_CLEAR_1: 356 DHT inviati da LOAD a SOLAR
• TX_CLEAR_2: 76 DHT inviati da QUEEN a SOLAR
• TX_CLOUDY_1: 455 DHT inviati da LOAD a QUEEN
• TX_CLOUDY_2: 135 DHT inviati da LOAD a SOLAR

Iprossimi passi:Il testbed Demo Hive implementa un caso molto semplice di alveare. È un punto di partenza significativo per lo sviluppo del framework completo, ma alcuni miglioramenti devono essere implementati. La seguente lista riporta le caratteristiche più significative ancora da sviluppare.

• Prototipo di un contatore "blockchain-ready": Il dispositivo SmartPi è basato su una scheda Raspberry Pi 3, un'ottima piattaforma hardware per la prototipazione e i test iniziali ma non progettata per essere facilmente integrata in un prodotto industriale. Per sviluppare un contatore blockchain, naturalmente necessario nel nostro quadro, l'idea di Hive Power è di prendere in considerazione piattaforme hardware più orientate all'industria e usarle per sostituire i dispositivi SmartPi.
• Profili di potenza: Attualmente i profili dei lavoratori sono abbastanza simili durante i "giorni simulati" di 10 minuti. In pratica c'è un'alternanza precisa di giorni sereni e nuvolosi per la produzione SOLAR. Per quanto riguarda il LOAD, ogni giorno simulato viene aggiunto un rumore allo stesso profilo predefinito. Per avere una situazione più realistica, si devono considerare nuovi profili (ad esempio due diversi profili di LOAD, il primo per i giorni lavorativi e il secondo relativo al fine settimana)
• Canali di stato: nel nostro testbed dimostrativo, le misure di potenza sono ora acquisite ogni 5 secondi e i relativi dati salvati in un database in esecuzione su QUEEN. Al fine di avere un approccio completamente decentralizzato, la nostra idea è quella di gestire i dati di potenza utilizzando la tecnologia State Channels evitando di utilizzare un database locale.
• Più lavoratori: Per avere una simulazione più realistica di un mercato energetico dell'alveare, il numero di lavoratori dovrebbe essere aumentato.
• Lavoratore prosumer/stoccaggio: Attualmente essendo in Demo Hive solo un consumatore (LOAD) e un produttore (SOLAR), sarà significativo introdurre prosumer e storage worker per avere un mercato completo. E' interessante considerare che con i sistemi di stoccaggio sarebbe possibile implementare algoritmi di load-shifting per massimizzare il risparmio sui costi.
• Tariffe dinamiche: In Demo Hive solo le tariffe statiche sono prese in considerazione per la compravendita di energia. Chiaramente, questa non è una situazione realistica e di conseguenza deve essere implementato un sistema dinamico di tariffe.

‍