Sardegna FESR 2014/2020 - ASSE PRIORITARIO I
“RICERCA SCIENTIFICA, SVILUPPO TECNOLOGICO E INNOVAZIONE”
Azione 1.1.4 Sostegno alle attività collaborative di R&S per lo sviluppo di nuove tecnologie sostenibili, di nuovi prodotti e servizi
PROGETTI CLUSTER TOP DOWN R.4.1 – Realizzazione del sistema
VIRTUALENERGY
Sommario
1. Introduzione ... 3
2. Architettura del sistema ... 5
2.1 Infrastrutture di rete ... 5
2.2 Piano dei test ... 9
2.2.1 Aggregato di consumer residenziali focalizzato sulla fornitura di servizi per il DSM ... 10
2.2.2 Aggregato di prosumer industriali focalizzato sul mercato della mobilità elettrica ... 10
2.2.3 Aggregato di prosumer industriali focalizzato sul mercato dei servizi ancillari ... 11
2.2.4 Aggregato di prosumer residenziali focalizzato sul concetto di comunità energetica ... 11
3. Piattaforma per la gestione del DSM ... 13
4. Piattaforma per la gestione delle DER... 26
4.1 Simulatore e casi uso implementati ... 26
4.1.1 Impianto fotovoltaico ... 26
4.1.2 Impianto fotovoltaico + lavastoviglie ... 27
4.1.3 Impianto fotovoltaico + batteria standard ... 27
4.1.4 Impianto fotovoltaico + batteria standard + lavastoviglie ... 27
4.1.5 Impianto fotovoltaico + batteria standard + lavastoviglie + carico non controllato ... 27
4.1.6 Impianto fotovoltaico + batteria standard avanzato + lavastoviglie + carico non controllato ... 27
4.1.7 Impianto fotovoltaico + batteria Tesla Powerwall + lavastoviglie + carico non controllato 28 4.1.8 Impianto fotovoltaico + batteria Sony Fortelion + lavastoviglie + carico non controllato . 28 4.1.9 Impianto fotovoltaico + batteria Sony Fortelion + lavastoviglie + carico non controllato . 28 4.1.1 Scenario di esempio ... 29
Bibliografia... 33
1. Introduzione
Il progetto VIRTUALENERGY è uno dei tanti progetti collaborativi promossi da Sardegna Ricerche attraverso il programma “Azioni Cluster Top-Down”, finanziato grazie al fondo di sviluppo regionale POR- FESR Sardegna 2014-2020. La finalità principale che accomuna queste iniziative è quella di svolgere attività di trasferimento tecnologico nei confronti delle aziende partecipanti, attraverso la risoluzione di problematiche condivise, mediante l’applicazione di competenze e risultati frutto dell’attività di ricerca.
L’obiettivo del progetto VIRTUALENERGY è quello di implementare un prototipo di Virtual Power Plant (VPP), ovvero una centrale elettrica virtuale, costituita dall’integrazione e coordinamento di sistemi eterogenei (potenza, controllo e comunicazione) in grado di interfacciarsi con la rete elettrica ed i vari stakeholders che operano sul mercato elettrico per il dispacciamento di energia e la fornitura di servizi ancillari.
Questo documento rendiconta e discute le diverse attività di sperimentazione e testing svolte nell’ambito del progetto, volte sia a validare il sistema implementato, sia a massimizzare il trasferimento tecnologico che il DIEE si è impegnato a realizzare nei confronti delle aziende che hanno partecipato attivamente al cluster.
Per poter meglio comprendere e contestualizzare lo spettro delle attività svolte, è importante ricordare la particolare configurazione del cluster, caratterizzato in particolare da 14 imprese coinvolte, di cui:
✓ 4 (Neula Soc. Cooperativa, Abirk Srl, Tholos PHP e EnerMed Srl): operanti a vario titolo nell’ambito dei servizi legati alla gestione di asset energetici;
✓ 2 (Franchini Service snc e Mobilificio Orrù snc): attive su segmenti commerciali non attinenti all’energia, ma caratterizzate da profili di consumo elettrico rilevanti, a causa del proprio processo produttivo;
✓ 2 (Sinerg Srl, Essei Srl): studi di ingegneria interessati ad acquisire know-how sul tema degli aggregatori e dei relativi progetti pilota in corso per la sperimentazione di nuove tecnologie per la gestione flessibile dell’energia;
✓ 2 (Soltea Srl, Alea Spa): focalizzate sulle attività di Operation & Maintenance (O&M) di impianti per la produzione di energia da fonti rinnovabili;
✓ 2 (Oil&Sun Srl e Proxienergy): operanti su due differenti segmenti commerciali legati al settore energetico;
✓ 2 (IAT Consulenza e Progetti Srl. e Building Technology Facilities Srls) con cui non si è purtroppo mai riusciti ad interagire a causa della scarsa disponibilità di tempo da parte dei referenti aziendali.
Per promuovere una partecipazione attiva e mantenere alto l’interesse di tutti i soggetti coinvolti, una volta determinate le reali aspettative dei singoli, il gruppo di coordinamento del progetto ha predisposto un piano di attività operative, che fosse in grado di stimolare lo studio e la sperimentazione delle diverse tecnologie che concorrono alla realizzazione di un VPP.
2. Architettura del sistema
Questo capitolo illustra e descrive in dettaglio i componenti che costituiscono i diversi ambienti di test e sviluppo realizzati dal DIEE in collaborazione con alcune imprese del cluster per l’esecuzione delle attività sperimentali.
2.1 Infrastrutture di rete
Nel corso del progetto sono state testate diverse infrastrutture di rete, che hanno consentito di sperimentare le funzionalità di networking necessarie per lo scambio di dati tra i vari elementi del prototipo di VPP oggetto di studio.
Inizialmente, grazie alla sinergia avviata con il progetto di ricerca CoNetDomeSys (Cooperative constrained optimization of Networked domestic thermal Systems for efficient and coordinated urban energy consumption) [1], è stato possibile avviare le prime attività di testing e validazione di un particolare insieme di funzionalità, relative specificamente al controllo remoto di carichi elettrici, sull’infrastruttura già realizzata nell’ambito della precedente iniziativa. I dettagli di questa prima fase di attività sperimentali sono illustrati nel capitolo 3.
L’infrastruttura IT sviluppata successivamente, e descritta in dettaglio nel documento R.2.1, è stata implementata lato server su una workstation messa a disposizione da Neula, una delle aziende del cluster.
La dotazione hardware presente all’interno della workstation è standard, e caratterizzata in particolare da una CPU quad-core Intel i5-4440 @3.10GHz e 12GB di RAM, con due unità di archiviazione SATA da 500 GB ciascuna.
Attraverso questa macchina è stato possibile realizzare l’installazione del “cloud server” in grado di erogare le diverse tipologie di servizi necessari per il funzionamento del prototipo di VPP oggetto di studio. I dettagli delle attività sperimentali relative alla validazione delle componenti del VPP in grado di implementare la gestione remota delle Distributed Energy Resources (DER) sono illustrati nel capitolo 4.
Il risultato è stato raggiunto attraverso l’installazione della piattaforma di cloud computing VMWare vSphere.
La licenza d’uso attivata in questo caso è stata quella gratuita, data la natura prototipale dell’applicazione, in cui l’interesse principale era rivolto unicamente agli aspetti funzionali.
Le componenti che caratterizzano l’installazione dell’hypervisor di macchine virtuali, sono in particolare:
✓ Il sistema operativo ESXi,6.7, installato sul primo dei due hard disk SATA disponibili sul server fisico.
✓ Un datastore da 500 GB, installato sul secondo dei due hard disk SATA disponibili sul server fisico.
✓ Tre Virtual Machine (VM), ognuna corrispondente ad una specifica funzionalità del sistema in cloud
In Figura 1 è riportata una vista di dettaglio della dashboard di ESXi, che riassume le informazioni principali relative al sistema hardware utilizzato nell’installazione realizzata.
Figura 1: Dashboard ESXi – configurazione hardware del server host
L’infrastruttura di rete è stata realizzata attraverso la virtual appliance contente la community edition della versione 2.4.5 Release del firewall open source pfsense [2]. L’interconnessione delle varie DER, distribuite tra i vari nodi del VPP, è stata studiata per essere realizzata attraverso l’implementazione di una Virtual Private Network (VPN) in cui ogni nodo della rete, indipendentemente dalla propria natura (producer, consumer, prosumer), risulta essere un client che, per entrare all’interno del VPP, deve instaurare una connessione dedicata e criptata (tunnel), previa autenticazione con il server VPN, ovvero il servizio gestito lato server proprio da questa appliance.
I dettagli relativi alla configurazione di sistema per questa VM sono riportati in Figura 2
Figura 2: Informazioni di sistema relative all'istanza di Pfsense utilizzata
La seconda virtual appliance, i cui dettagli sono riportati in Figura 3, è una VM che ospita un ambiente di sviluppo su sistema operativo Windows 7 Professional Edition, con risorse hardware virtuali allocate pari a: 2CPU, 4GB di RAM, 50 GB di Hard Disk, un controller USB 2.0, un controller ethernet, ed una scheda video, per la codifica e testing di applicazioni scritte in linguaggio Python. In essa, è stato installato l’IDE PyCharm e tutte le dipendenze necessarie per poter implementare il modulo software che effettua una stima dell’andamento temporale di una grandezza dinamica equivalente alla temperatura interna di uno scaldacqua, sulla base di un certo insieme di determinati parametri acquisiti nel corso del tempo dalla Smart Power Socket (SPS) a cui risulta connesso l’apparato, i cui dettagli sono riportati nel documento R.3.1.
Figura 3: Dashboard ESXi – configurazione VM di sviluppo (Win 7 PRO)
La terza virtual appliance, i cui dettagli sono riportati in Figura 4, è la VM che ospita i vari moduli software che caratterizzano le funzionalità associate al prototipo di VPP oggetto di studio. Si tratta in particolare, di un sistema operativo kubuntu Linux 20.04, con risorse hardware virtuali allocate pari a: 2CPU, 4GB di RAM, 40 GB di Hard Disk, un controller USB 2.0, un controller ethernet, ed una scheda video.
Figura 4: Dashboard ESXi – configurazione VM di servizio (VIRTUALENERGY SERVER)
L’infrastruttura IT lato client è costituita principalmente da due componenti hardware, che caratterizzano il kit di accessori presente in ogni singolo nodo delle installazioni programmate per la sperimentazione del VPP:
✓ Un dispositivo embedded (Raspberry Pi Zero), da utilizzarsi come gateway, basato su sistema operativo Linux, e dotato di porta USB e interfaccia di rete WiFi, su cui vengono eseguiti i vari moduli software che consentono la comunicazione sia a livello locale, con i dispositivi presenti in campo, sia a livello remoto, con il server in cloud. Tra questi moduli, è previsto anche il client VPN, ovvero la routine che si occuperà di instaurare e mantenere una connessione dedicata con il server VPN, ed eventualmente anche con altri nodi della rete;
✓ Un modem 4G/LTE in formato USB stick (Huawei E3372), da connettere al dispositivo gateway per abilitare una connessione ad Internet su rete mobile fino a 150 Mbps, eventualmente alternativa alla connessione già disponibile in campo.
A questi elementi, si aggiungono altri apparati fisici per il controllo e la gestione delle risorse energetiche a seconda della particolare installazione considerata.
Nel corso del progetto infatti, sono state sviluppate diverse sinergie con altri progetti di ricerca, con l’obiettivo di utilizzare apparati reali di produzione e consumo di energia già installati nel corso di queste iniziative, in modo da ovviare il problema della mancanza di asset fisici su cui validare la sperimentazione.
In particolare, attraverso la sinergia con il progetto StoRES (Promotion of higher penetration of distributed PV through storage for all) [3], l’intenzione era quella di testare il funzionamento del prototipo di VPP sviluppato nell’ambito di VIRTUALENERGY su alcuni dei sistemi domestici costituiti da impianto fotovoltaico con relativo sistema di accumulo elettrico installati in diverse abitazioni del comune di Ussaramanna.
La sinergia con il progetto SmartPolyGen (Sviluppo di Microreti Polienergetiche Intelligenti) [4] invece, era finalizzata ad integrare nel VPP alcuni componenti della micro-rete in corso di realizzazione nella zona industriale del comune di Siamaggiore. In particolare, nel corso del progetto si è provveduto ad installare un apposito dispositivo hardware (Mikrotik SXT LTE kit), messo a disposizione di VIRTUALENERGY da parte del progetto CoNetDomeSys, per abilitare una connessione protetta con gli apparati in situ attraverso il collegamento alla rete Internet esistente. In questo modo, è stata ottenuta la possibilità di interagire in particolare con:
✓ un impianto fotovoltaico da 9kWp, caratterizzato dalla presenza di due differenti tipologie di inverter (Solax, SMA) con un sistema di accumulo da 12,7 kWh (PylonTech);
✓ un boiler elettrico da 10kW;
✓ un gruppo elettrogeno da 20 kVA a giri costanti;
✓ un gruppo elettrogeno da 10 kVA a giri variabili;
✓ un convertitore statico AC/DC/AC da 10 KVA;
✓ un carico elettronico variabile da 10 kVA;
✓ un sistema accoppiatore + trasformatore in configurazione triangolo stella da 10 KVA
2.2 Piano dei test
Il piano dei test descritto in questo paragrafo è stato predisposto mettendo a fattor comune le informazioni acquisite nel corso dell’attività di studio ed analisi degli scenari descritti nel documento R.1.1 con le disponibilità di apparati fisici e specifiche necessità di validazione e testing di alcune ipotetiche applicazioni manifestate da parte di alcune aziende del cluster.
Queste interazioni hanno portato in particolare alla definizione di quattro differenti casi d’uso che, per le ragioni di seguito discusse, purtroppo non è stato possibile implementare.
Infatti, il perdurare delle condizioni di emergenza indotte dalla pandemia di Covid-19, ha inevitabilmente condizionato anche l’evoluzione delle attività operative del cluster, che di conseguenza hanno subito forti disagi e rallentamenti, soprattutto per quanto concerne la realizzazione delle attività sperimentali previste nel piano di lavoro. Le principali cause che hanno impedito l’implementazione dei casi d’uso sono in particolare: le difficoltà di interazione con e tra le aziende, le difficoltà di interazione tra i ricercatori, le
difficoltà di accesso ai laboratori del DIEE, i ritardi dovuti alla necessità di implementare una modalità di accesso remoto agli ambienti di testing e sviluppo, ed infine l’impossibilità di accedere ai siti individuati, che purtroppo non hanno permesso a ricercatori ed aziende di completare le attività preliminari di configurazione ed installazione dei vari componenti hardware e software che fisicamente avrebbero dovuto abilitare la validazione delle funzionalità attese. Le attività sperimentali condotte hanno consentito di validare il corretto funzionamento di quanto implementato per quanto concerne il corretto scambio di informazioni tra le componenti fondamentali del sistema, sia lato client che lato server. Tuttavia, la validazione degli scenari applicativi associati ai diversi casi d’uso richiede anche la definizione di particolari funzioni obiettivo ed altri parametri di controllo che dipendono strettamente dalla configurazione della rete di apparati considerata, nonché l’implementazione di driver di comunicazione specifici per ogni dispositivo.
Entrambe le attività necessitano di un accesso fisico ai luoghi in cui si trovano gli apparati per il tempo necessario allo sviluppo delle componenti di integrazione da inserire nel sistema di gestione del VPP.
2.2.1 Aggregato di consumer residenziali focalizzato sulla fornitura di servizi per il DSM
Un primo caso d’uso prevedeva la gestione di un aggregato di consumer di tipo residenziale, caratterizzato in particolare dalla presenza di un certo numero di utenze dotate di elettrodomestici controllabili termostaticamente, come gli scaldacqua elettrici. Le utenze (circa 20) in cui installare il sistema di controllo degli scaldacqua erano state individuate tra un gruppo di volontari all’interno di un condominio sito nel comune di Golfo Aranci. L’obiettivo della sperimentazione, in questo caso, era quello di verificare quanto il sistema di controllo nel suo complesso sarebbe stato in grado di coordinare i consumi di energia dell’aggregato, in modo da penalizzare i picchi di richiesta di potenza, livellare il profilo di carico, ed abilitare di conseguenza un Virtual Power Load in grado di fornire servizi in ottica di Demand Side Management (DSM).
2.2.2 Aggregato di prosumer industriali focalizzato sul mercato della mobilità elettrica
Il secondo caso d’uso faceva capo allo studio di fattibilità tecnico-economica promosso da Oil&Sun, una delle aziende del cluster, e riguardante in particolare l’implementazione di un VPP focalizzato su un aggregato di prosumer di tipo industriale, in grado di offrire servizi specifici per il mercato della mobilità elettrica. L’attività sperimentale, in questo caso, prevedeva l’installazione di un certo numero di multimetri, datalogger ed altri eventuali apparati per il controllo di carichi elettrici, che eventualmente sarebbero stati messi a disposizione ed installati da parte dell’azienda Enermed, altro soggetto del cluster, all’interno di un una stazione di servizio realmente esistente, individuata tra i contatti dell’azienda Oil&Sun, con l’obiettivo di mettere questa utenza virtualmente a sistema con uno o più impianti fotovoltaici di potenza idonea ad alimentare la stazione di servizio, installati presso altre strutture ubicate sul territorio regionale, ed individuati tra quelli monitorati dell’azienda Neula, altra società partecipante al cluster. Il risultato atteso era quello di valutare l’impatto che un’eventuale installazione di colonnine per la ricarica elettrica alimentate
mediante un impianto fotovoltaico con accumulo avrebbe avuto in termini economici per la stazione di servizio. I dati acquisiti dai vari siti avrebbero costituito i profili di carico e di produzione, puntuali e reali, con cui andare sviluppare simulazioni molto più attendibili e precise di quelle ottenibili a partire da profili stimati. Altro grande vantaggio offerto da questo approccio innovativo al revamping di una stazione di servizio, sarebbe stato quello di poter eventualmente valutare in un secondo momento l’effettivo utilizzo delle colonnine di ricarica in scenari legati all’erogazione di servizi basati sull’applicazione della tecnologia Vehicle-to-Grid (V2G), grazie alla possibilità di modellare questa particolare funzionalità delle stazioni di ricarica all’interno del VPP.
La tecnologia V2G consente ai proprietari di veicoli elettrici di utilizzare l'auto come accumulatore di energia e di risparmiare sui costi ottimizzando l'uso dell'energia e fornendo servizi alla rete.
2.2.3 Aggregato di prosumer industriali focalizzato sul mercato dei servizi ancillari
Il terzo caso d’uso, così come quello precedente, è stato predisposto per soddisfare un’ulteriore esigenza rilevata da parte di un’altra impresa del cluster, ovvero il Mobilificio Orrù, ed anch’essa legata ad uno studio di fattibilità tecnico-economica. In questo caso, per l’azienda era interessante valutare l’opportunità di mettere a disposizione di qualche soggetto la copertura del proprio stabilimento produttivo, su cui installare un impianto per la produzione di energia elettrica da fonte rinnovabile, ad esempio eolico o fotovoltaico. Anche in questo caso, l’attività sperimentale prevedeva l’installazione, presso la sede operativa del mobilificio, di un certo numero di multimetri, datalogger ed altri eventuali apparati per il controllo di carichi elettrici, da parte dell’azienda Enermed. Anche in questo caso, l’intenzione era quella di mettere questa utenza virtualmente a sistema con uno o più impianti fotovoltaici di potenza idonea ad alimentare lo stabilimento produttivo, individuati tra quelli monitorati dell’azienda Neula, con l’obiettivo di simulare un VPP focalizzato sulla fornitura di servizi ancillari, da poter valorizzare economicamente sul Mercato dei Servizi di Dispacciamento (MSD). In particolare, i dati acquisiti dal campo avrebbero costituito i profili di carico e di produzione, puntuali e reali, con cui andare sviluppare simulazioni sia in ottica di autoconsumo che di erogazione di servizi di flessibilità al gestore di rete.
2.2.4 Aggregato di prosumer residenziali focalizzato sul concetto di comunità energetica
Un quarto caso d’uso prevedeva la gestione di un aggregato di prosumer di tipo residenziale, caratterizzato in particolare dalla presenza di un certo numero di carichi elettrici ad uso domestico (es. lavatrici, lavastoviglie, etc…), ed un certo numero di impianti fotovoltaici con sistema di accumulo. Purtroppo, per i motivi sopra citati, non è stato acquisire la disponibilità degli utenti, individuati tra i volontari del comune di Ussaramanna che hanno preso parte al progetto StoRES. L’obiettivo della sperimentazione in questo caso era quello di verificare quanto il sistema nel suo complesso sarebbe stato in grado di gestire in autonomia, ovvero senza la necessità di acquistare energia elettrica fornita dal gestore di rete, l’utilizzo degli elettrodomestici da parte degli utenti senza intaccare il livello di comfort percepito da questi ultimi. In pratica,
l’idea era quella di validare il comportamento di una piccola comunità energetica locale, gestita tramite un VPP in grado di coordinare gli scambi di energia tra i vari prosumer, con l’obiettivo di realizzare un utilizzo efficiente delle risorse energetiche disponibili.
3. Piattaforma per la gestione del DSM
In questa sezione vengono descritte in dettaglio le attività sperimentali rivolte allo sviluppo della componente di VPP che avrebbe dovuto implementare alcune logiche per la gestione del DSM attraverso il controllo remoto di carichi elettrici, grazie alla sinergia con il progetto di ricerca CoNetDomeSys. Tra i risultati attesi di questo progetto, vi è la realizzazione di un dimostratore sperimentale a basso costo orientato all'IoT per la prototipazione rapida e il test di algoritmi di DSM su grandi popolazioni di elettrodomestici controllati e monitorati da prese di corrente intelligenti. Lo staff di VIRTUALENERGY intendeva avvalersi di questo framework per sviluppare alcune logiche di controllo e gestione del VPP. Un altro obiettivo che VIRTUALENERGY aveva in comune con CoNetDomeSys era quello di valutare le prestazioni di un sistema di controllo remoto dei carichi elettrici basato sull’utilizzo di hardware a basso costo. Altri obiettivi specifici che lo staff di VIRTUALENERGY intendeva perseguire attraverso questa piattaforma di prototipazione a basso costo erano quelli di:
✓ Implementare e validare uno o più casi d’uso;
✓ Sviluppare e validare nuovi algoritmi per il DSM.
I risultati sperimentali ottenuti nel corso di questa prima fase esplorativa hanno purtroppo fatto registrare una serie di limiti e problematiche operative, che hanno reso necessaria una reingegnerizzazione del sistema software sviluppato nell’ambito della precedente iniziativa.
Il caso d’uso oggetto della sperimentazione iniziale effettuata in VIRTUALENERGY è stato lo stesso proposto in [5] per la validazione di un'architettura di controllo multi-agente in grado di implementare logiche di DSM basate sul coordinamento di carichi elettrici. Il banco di prova è stato realizzato intorno agli stessi componenti hardware a basso costo descritti in [5], di cui il componente principale è la WeMo Insight Switch SPS [6]. La scelta di questa particolare SPS è stata dettata dalla disponibilità di API aperte e gratuite per integrare i dispositivi con software di terze parti. Questa SPS è dotata in particolare di:
✓ un'unità di rilevamento del consumo energetico con risoluzione di 1mW e frequenza di campionamento massima testata pari a 1Hz;
✓ un interruttore per accendere e spegnere a distanza l'apparecchio elettrico collegato alla presa;
✓ un microcontrollore e capacità di comunicazione WiFi.
Il caso di studio realizzato ha preso in considerazione unicamente elettrodomestici in grado di abilitare un controllo del carico termico, ovvero scaldabagni situati in case private e piccoli uffici di alcuni volontari che hanno accettato di partecipare alla validazione sperimentale. Il software sviluppato nell’ambito del progetto CoNetDomeSys implementa in particolare un'architettura di data logging e controllo di tipo client-server, costituita da due applicazioni Java e da un insieme di script eseguiti in ambiente Matlab. Il framework
permette di gestire un insieme distribuito di SPS attraverso qualsiasi connessione Internet disponibile, cioè ADSL, 3G, LTE, ecc...
Il processo server si trova in esecuzione su una postazione di lavoro fisicamente ospitata a Cagliari, all'interno dell'AutoLAB del DIEE, e collegata ad Internet attraverso la WAN dell'Università di Cagliari. La workstation è una Dell Precision t5810, equipaggiata con un Intel Xeon E5-1620 v3 (10M Cache, 3.50 GHz), 64GB di RAM, su cui è installato il sistema operativo Windows 10 Pro. Ogni processo client è ospitato in una differente piattaforma embedded, ovvero un Raspberry Pi Zero W. Ognuna di queste unità di controllo viene installata in un diverso ambiente domestico ed è configurata per funzionare come gateway verso il server per tutti gli SPS collegati alla stessa LAN WiFi. L'applicazione in esecuzione sui Raspberry gestisce il monitoraggio e il controllo locale di ogni SPS. Inoltre, ogni gateway trasmette le misurazioni e riceve i comandi di controllo dal server. L'applicazione lato server raccoglie i dati dalle SPS, gestisce un database SQLite [7], ed invia comandi di attuazione. Un'interfaccia Matlab è stata integrata con il software per la prototipazione rapida di algoritmi di coordinamento distribuito. La Figura 5 fornisce una rappresentazione schematica dell'architettura attraverso cui il sistema sviluppato nell’ambito del progetto CoNetDomeSys implementa l’acquisizione dei dati. La Figura 6 fornisce invece una rappresentazione della topologia di rete utilizzata.
Figura 5: Architettura di acquisizione dati del sistema CoNetDomeSys
Figura 6: Topologia di rete del sistema CoNetDomeSys
Nel corso di questa prima fase di attività sperimentali, alcuni kit di controllo remoto dei carichi sono stati installati presso alcuni volontari, individuati in particolare tra diversi soggetti privati ed alcune aziende aderenti al cluster. Ogni singolo kit è composto in particolare a livello hardware da:
✓ Una o più SPS, attraverso cui è possibile azionare a distanza l’accensione e lo spegnimento del carico elettrico ad essa connesso.
✓ Un dispositivo embedded (Raspberry Pi Zero W), eventualmente dotato di modem 4G/LTE (Huawei E3372) nei casi in cui non è disponibile una connessione ad Internet, per abilitare la comunicazione bidirezionale tra tutte le SPS che si trovano sulla stessa LAN ed il server centrale.
Dall’analisi dei dati storici acquisiti mediante l’architettura client-server appena descritta, sono emersi svariati refusi, descritti nel seguito di questa sezione, che hanno portato a considerare come non attendibili alcuni indicatori di stato delle SPS.
Per ogni campione k acquisito dalla singola SPS, le informazioni registrate nel corrispondente database dei dati storici, sono quelle di seguito riportate:
➢ id (k): numero progressivo, identificativo univoco del record all’interno del database
➢ name (k): nome assegnato alla SPS
➢ address (k): indirizzo IP pubblico del client attraverso cui la SPS invia i dati al server tramite rete Internet
➢ port (k): porta di comunicazione attraverso cui avviene la comunicazione tra il client a cui è connessa la SPS ed il server
➢ sample_id (k): numero sequenziale del sample ricevuto dalla SPS
➢ time_sent (k): timestamp relativo all’istante di invio del sample al server da parte del client
➢ time_received (k): timestamp relativo all’istante in cui il client riceve una richiesta di sample dal server
➢ active (k): flag che identifica lo stato di attività (ON/OFF) della SPS
➢ value (k): valore della grandezza elettrica (potenza) misurata dalla SPS
La Figura 7 mostra, a titolo esemplificativo, un insieme di record estratti dallo storico dei dati acquisiti nel corso della sperimentazione preliminare, allo scopo di evidenziare la struttura del database appena descritta.
Figura 7: Esempio di record memorizzati nel database di dati storici acquisiti nella sperimentazione preliminare Dall’analisi dei dati storici acquisiti nel corso di queste prime attività sperimentali, sono emerse in particolare le seguenti anomalie:
✓ Il sample_id veniva resettato con una frequenza di 30 minuti circa. Il reset del numero di campioni ricevuti era previsto che avvenisse in corrispondenza di una perdita di pacchetto, ma ci si è accorti che in realtà non sempre questo riavvio del conteggio era associato ad un effettivo evento di questo tipo.
✓ L’intervallo di tempo che intercorre tra la richiesta di invio e la ricezione di un sample tra client e server, definito come:
𝛥𝑡(𝑘) = 𝑡𝑖𝑚𝑒 𝑠𝑒𝑛𝑡(𝑘) − 𝑡𝑖𝑚𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑(𝑘)
presentava periodicamente dei valori negativi, più o meno ravvicinati nel tempo, per poi tornare ad assumere nuovamente valori coerenti. L’inversione di segno si verificava quasi sempre in corrispondenza di un reset del sample_id.
L’SDK delle SPS utilizzate nell’ambito di questa sperimentazione, non implementa al suo interno in maniera nativa un’associazione tra il valore della misura rilevata dal dispositivo e l’istante di tempo in cui la misura viene effettuata, e le anomalie riscontrate nell’implementazione del sistema di campionamento non rendevano possibile effettuare operazioni come ad esempio il conteggio del numero di pacchetti “persi”.
L’affidabilità nella procedura di archiviazione delle misure e degli stati delle SPS dipendeva dalla modalità attraverso cui era stato implementato lo scambio di informazioni tra client e server, con particolare riferimento alle logiche di aggiornamento degli indici sample_id, time_sent e time_received. L’inattendibilità dell’indice sample_id non consentiva di discriminare con certezza tra tutti gli eventuali problemi che si possono verificare nella trasmissione dei dati dal client al server, quali ad esempio: perdita di un certo numero di pacchetti, arrivo non sequenziale dei pacchetti, ritardo di ricezione tra due pacchetti successivi, o altre problematiche simili che possono presentarsi o meno a seconda dalla particolare rete di carichi elettrici considerata.
Inizialmente, si è cercato di ovviare a questi inconvenienti sfruttando i restanti indici. Nonostante le anomalie sopra descritte, l’attuale versione dell’architettura client-server avrebbe dovuto comunque consentire di implementare un sistema di acquisizione delle misure e controllo remoto dei carichi in grado di soddisfare le specifiche funzionali oggetto della sperimentazione.
In particolare, si è ritenuto opportuno non tener conto dell’indicatore sample_id, ma generare un nuovo vettore, denominato sample_ERR, contente i flag che determinano se una misura è da considerarsi corrotta oppure no, sulla base della condizione di coerenza tra i due timestamp disponibili, ovvero:
𝑠𝑎𝑚𝑝𝑙𝑒 𝐸𝑅𝑅(𝑘) = {0 𝑖𝑓 𝑡𝑖𝑚𝑒 𝑠𝑒𝑛𝑡(𝑘) > 𝑡𝑖𝑚𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑(𝑘) (𝑚𝑖𝑠𝑢𝑟𝑎 𝐶𝑂𝑅𝑅𝐸𝑇𝑇𝐴) 1 𝑖𝑓 𝑡𝑖𝑚𝑒 𝑠𝑒𝑛𝑡(𝑘) < 𝑡𝑖𝑚𝑒 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑(𝑘) (𝑚𝑖𝑠𝑢𝑟𝑎 𝐶𝑂𝑅𝑅𝑂𝑇𝑇𝐴)
Per valutare la qualità del Sistema di data logging, sono stati implementati alcuni script in ambiente Matlab, che per ogni SPS determinavano i seguenti indicatori, ricavati attraverso l’analisi di un certo numero N di record presenti nel database, a seconda della finestra temporale considerata.
Quantificazione misure acquisite
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑇𝑂𝑇 = 𝑁
Numero totale di misure aventi timestamp all’interno della finestra temporale di logging considerata registrate nel database
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝐿𝑂𝑆𝑆 = ∑ 𝑠𝑎𝑚𝑝𝑙𝑒
𝑁
𝑘=1
𝐸𝑅𝑅(𝑘)
Numero di misure CORROTTE all’interno del totale nella finestra temporale
considerata
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑂𝐾 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑇𝑂𝑇 − 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝐿𝑂𝑆𝑆 Numero di misure CORRETTE rispetto al totale nella finestra temporale considerata
Quantificazione durate temporali
𝑡𝑖𝑚𝑒 𝑂𝐾 = 𝑡𝑖𝑚𝑒 𝐼𝑁𝐼𝑇 − 𝑡𝑖𝑚𝑒 𝐸𝑁𝐷 Durata complessiva della finestra temporale di logging presa in esame.
𝑡𝑖𝑚𝑒 𝑂𝐾 = ∑ 𝛥
𝑁
𝑘=1
𝑡 𝑂𝐾(𝑘)
𝛥𝑡 𝑂𝐾(𝑘) = {𝛥𝑡(𝑘) 𝑖𝑓 𝑠𝑎𝑚𝑝𝑙𝑒 𝐸𝑅𝑅(𝑘) = 0 0 𝑖𝑓 𝑠𝑎𝑚𝑝𝑙𝑒 𝐸𝑅𝑅(𝑘) = 1
Intervallo di tempo, all’interno della finestra temporale di logging considerata, calcolato come somma degli intervalli di trasmissione relativi alle MISURE CORRETTE registrate sul database.
𝑡𝑖𝑚𝑒 𝐿𝑂𝑆𝑆 = ∑ 𝛥
𝑁
𝑘=1
𝑡 𝐿𝑂𝑆𝑆(𝑘)
𝛥𝑡 𝐿𝑂𝑆𝑆(𝑘) = {|𝛥𝑡(𝑘)| 𝑖𝑓 𝑠𝑎𝑚𝑝𝑙𝑒 𝐸𝑅𝑅(𝑘) = 1 0 𝑖𝑓 𝑠𝑎𝑚𝑝𝑙𝑒 𝐸𝑅𝑅(𝑘) = 0
Intervallo di tempo, all’interno della finestra temporale di logging considerata, calcolato come somma degli intervalli di trasmissione relativi al numero di MISURE CORROTTE registrate sul database.
𝑡𝑖𝑚𝑒 𝐷𝐼𝑆𝐶𝑂𝑁𝑁 = 𝑡𝑖𝑚𝑒 𝑇𝑂𝑇 − (𝑡𝑖𝑚𝑒 𝑂𝐾 + 𝑡𝑖𝑚𝑒 𝐿𝑂𝑆𝑆)
Intervallo di tempo, all’interno della finestra temporale di logging considerata, in cui il dispositivo è risultato disconnesso.
Statistiche relative alla trasmissione corretta delle misure
𝛥𝑡𝑚𝑎𝑥= 𝑚𝑎𝑥{𝛥𝑡 𝑂𝐾(𝑘) ∀𝑘 = 1: 𝑁}
Massimo intervallo di tempo in cui è avvenuta correttamente la trasmissione di una misura
𝛥𝑡𝑚𝑖𝑛= 𝑚𝑖𝑛{𝛥𝑡 𝑂𝐾(𝑘) ∀𝑘 = 1: 𝑁}
Minimo intervallo di tempo in cui è avvenuta correttamente la trasmissione di una misura
𝛥𝑡𝑚𝑒𝑎𝑛= 1 𝑁∑ 𝛥
𝑁
𝑘=1
𝑡 𝑂𝐾(𝑘)
Intervallo di tempo medio in cui è avvenuta correttamente la trasmissione di una misura
𝛥𝑡𝑣𝑎𝑟= 1
𝑁∑(𝛥𝑡 𝑂𝐾(𝑘) − 𝛥𝑡𝑚𝑒𝑎𝑛)2
𝑁
𝑘=1
Varianza degli intervalli di tempo con cui sono avvenute correttamente le trasmissioni delle misure
𝛥𝑡𝑠𝑡𝑑= √ 1
𝑁 − 1∑(𝛥𝑡 𝑂𝐾(𝑘) − 𝛥𝑡𝑚𝑒𝑎𝑛)2
𝑁
𝑘=1
Deviazione standard degli intervalli di tempo con cui sono avvenute correttamente le trasmissioni delle misure
Valore stimato delle tempistiche associate alle misure (totali, trasmesse, perse)
𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝑇𝑂𝑇 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑇𝑂𝑇 ⋅ 𝛥𝑡𝑚𝑒𝑎𝑛
Stima dell’intervallo di tempo, all’interno della finestra temporale di logging considerata, corrispondente al numero di misure registrate nel database.
𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝐿𝑂𝑆𝑆 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝐿𝑂𝑆𝑆 ⋅ 𝛥𝑡𝑚𝑒𝑎𝑛
Stima dell’intervallo di tempo, all’interno della finestra temporale di logging considerata, corrispondente al numero di misure corrotte presenti nel database.
𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝑂𝐾 = 𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑂𝐾 ⋅ 𝛥𝑡𝑚𝑒𝑎𝑛
Stima dell’intervallo di tempo, all’interno della finestra temporale di logging considerata, corrispondente al numero di misure registrate correttamente nel database.
Per chiarire meglio il significato degli indicatori appena descritti, in Tabella 1 vengono riepilogati a titolo esemplificativo i valori ottenuti analizzando il contenuto del database nella finestra temporale corrispondente a due giorni di logging per 5 differenti SPS.
In particolare:
✓ SPS2 ed SPS9 erano due SPS che controllavano due scaldacqua installati presso i rispettivi appartamenti di due volontari del progetto CoNetDomeSys. Entrambi i client erano connessi ad Internet attraverso la rete wifi domestica.
✓ SPS4 era la SPS connessa ad uno scaldacqua installato ad Oristano presso la sede operativa di Proxienergy, una delle aziende aderenti al progetto cluster VIRTUALENERGY. Il dispositivo era connesso ad Internet attraverso un collegamento ADSL.
✓ SPS10 ed SPS11 erano due SPS temporaneamente utilizzate per effettuare test di connessione mediante rete cellulare (operatore: TIM, connessione: 4G). In particolare, SPS10 era la SPS attraverso cui veniva alimentata SPS11, a cui invece non risultava connesso alcun carico elettrico.
Le coppie di grafici riportati in Figura 8 invece, rappresentano rispettivamente l’andamento delle misure di potenza (Power) acquisite correttamente da ogni SPS presente in Tabella 1, e dell’intervallo di tempo (DeltaT) associato all’acquisizione di ognuno di questi campioni.
SPS2 SPS4 SPS9 SPS10 SPS11
𝑡𝑖𝑚𝑒 𝑇𝑂𝑇[hh:mm:ss] 48:00:00 48:00:00 48:00:00 48:00:00 48:00:00 𝑡𝑖𝑚𝑒 𝑂𝐾 [hh:mm:ss] 02:24:52 17:16:04 36:52:37 34:25:07 32:17:49 𝑡𝑖𝑚𝑒 𝐿𝑂𝑆𝑆 [hh:mm:ss] 00:00:00 13:23:01 00:03:35 00:07:42 00:07:57 𝑡𝑖𝑚𝑒 𝐷𝐼𝑆𝐶𝑂𝑁𝑁 [hh:mm:ss] 45:35:07 17:20:54 11:03:46 13:27:10 15:34:13 𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝑇𝑂𝑇[hh:mm:ss] 02:50:36 20:06:42 38:29:49 37:00:53 34:40:33 𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝑂𝐾[hh:mm:ss] 02:50:36 17:32:12 37:45:53 34:50:21 32:36:28 𝑡𝑖𝑚𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝐿𝑂𝑆𝑆[hh:mm:ss] 00:00:00 03:34:29 01:44:55 02:10:31 02:05:05
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑇𝑂𝑇[samples] 5116 88925 158796 160051 154967
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝑂𝐾[samples] 5116 76592 153123 150927 145763
𝑚𝑒𝑎𝑠𝑢𝑟𝑒 𝐿𝑂𝑆𝑆[samples] 0 12333 5673 9124 9204
𝛥𝑡𝑚𝑎𝑥[sec] 1,741 1,624 1,742 1,721 1,697
𝛥𝑡𝑚𝑖𝑛[sec] 0,813 0,001 0,001 0,001 0,001
𝛥𝑡𝑚𝑒𝑎𝑛[sec] 1,699 0,81163 0,867 0,82097 0,79766 𝛥𝑡𝑣𝑎𝑟[sec] 0,00093598 0,22099 0,24923 0,23239 0,22293 𝛥𝑡𝑠𝑡𝑑[sec] 0,030594 0,47009 0,49923 0,48207 0,47216 Tabella 1: Elenco misure ricavate dalle SPS considerate nella sperimentazione preliminare
Dall’analisi del grafico relativo alla potenza assorbita, è possibile notare che, nella finestra di osservazione considerata:
✓ la SPS2 è stata attiva (interruttore ON), ma disconnessa per gran parte del tempo. Durante l’intero periodo in cui è stata connessa al server, ovvero poco meno di tre ore, ha sempre alimentato lo scaldacqua. In questo caso non ci sono stati errori nel logging delle misure;
✓ la SPS4 è stata attiva, ma disconnessa per circa un terzo del tempo. Durante il periodo in cui è risultata connessa al server, ha sempre mantenuto l’intrerruttore in posizione OFF. In questo caso si sono registrati parecchi errori nel logging delle misure;
✓ la SPS9 è stata connessa al server per buona parte del tempo, ma anche in questo caso si sono registrati errori nel logging delle misure. In questo caso, lo scaldacqua è risultato alimentato in maniera intermittente;
✓ la SPS10 è stata attiva per gran parte del tempo, ed ha alimentato continuativamente un carico molto piccolo, quale appunto la SPS11, ad eccezione di alcune brevi sequenze di accensione/spegnimento dell’interruttore.
✓ La SPS11 ha avuto un andamento molto simile a quello di SPS10. I valori di potenza registrati, inferiori al mW, danno evidenza di come l’interruttore è stato per un certo intervallo di tempo anche sullo stato ON, ma nessun carico è stato mai connesso alla presa.
Un elemento comune a tutte e cinque le connessioni analizzate che è immediato osservare, riguarda l’evoluzione temporale del parametro DeltaT. Indipendentemente dalla connessione considerata infatti, questo intervallo di tempo risulta subire un incremento nei valori registrati, mentre in condizioni nominali l’andamento atteso avrebbe dovuto oscillare attorno ad un certo valore costante, caratteristico della particolare modalità di accesso alla rete. Questa ulteriore anomalia ha reso necessaria una reingegnerizzazione di questa piattaforma, che è stata quindi studiata per consentire alle aziende una prototipazione rapida di logiche per il DSM basate sul controllo dei carichi elettrici.
In estrema sintesi, è stato ripreso il framework client-server, con la definizione di nuove componenti software, ereditando dal progetto iniziale solamente alcuni elementi di architettura generale di sistema. I dettagli della nuova piattaforma software sono discussi nel documento R.3.1.
La nuova piattaforma software è stata installata sulla nuova infrastruttura IT predisposta per il testing del prototipo di VPP descritta nella sezione 2.1, ed in particolare sulla VM denominata VIRTUALENERGY_SERVER, i cui dettagli sono riportati in Figura 4.
Purtroppo, le particolari condizioni di lavoro indotte dalla pandemia di Covid-19 discusse nella sezione 2.2 non hanno consentito di portare a termine le attività pianificate per la validazione in contesti reali della piattaforma realizzata. Le attività sperimentali condotte hanno comunque consentito di validare il corretto funzionamento di quanto implementato per quanto concerne il corretto scambio di informazioni tra le componenti fondamentali del sistema, sia lato client che lato server.
Le quattro figure che seguono rappresentano i risultati delle due diverse tipologie di esperimento, descritte nel documento R.3.1, che è possibile impostare e gestire tramite il frontend della piattaforma. In particolare, la Figura 9 mostra gli andamenti temporali delle due grandezze principali, ovvero la potenza assorbita dal carico elettrico connesso all’unica smart socket attiva nell’esperimento, ed il parametro che misura l’intervallo di tempo che intercorre tra la richiesta di invio e la ricezione di un sample tra il client e il server,
misurate nell’esperimento di “sola lettura”. In questo caso la durata complessiva dell’esperimento è stata di circa un’ora e mezza, con frequenza di campionamento pari a 5 secondi. Nel corso dell’esperimento, una stufa elettrica con assorbimento intorno ai 600 Watt, è stata inizialmente tenuta accesa per circa due minuti e mezzo, per essere poi tenuta spenta per quasi un’ora, e quindi riaccesa per il tempo rimanente.
La Figura 10 mostra gli indicatori statistici misurati per l’esperimento considerato, che in questo caso danno evidenza di una comunicazione senza alcun tipo di problema.
In Figura 11 invece, sono riportati gli andamenti temporali ottenuti nell’esperimento di “lettura-scrittura” su due smart socket, a cui sono state connesse due stufe elettriche con differente assorbimento, e che in particolare sono state tenute accese e poi spente ad intervalli regolari della durata di dieci minuti ciascuno.
La Figura 12 mostra gli indicatori statistici misurati per l’esperimento considerato, che anche in questo caso si riferiscono ad una comunicazione senza anomalie.
Figura 8: Grafici delle misure acquisite dalle SPS nell'esperimento riportato in Tabella 1
Figura 9: Andamento temporale delle due grandezze principali misurate nell’esperimento di "sola lettura"
Figura 10: Visualizzazione degli indicatori statistici rilevati nell'esperimento di "sola lettura"
Figura 11: Andamento temporale delle due grandezze principali misurate nell’esperimento di “lettura-scrittura”
Figura 12: Visualizzazione degli indicatori statistici rilevati nell'esperimento "lettura-scrittura""
4. Piattaforma per la gestione delle DER
Questa sezione è dedicata alla descrizione delle attività sperimentali relative alla validazione della componente del VPP in grado di implementare la gestione remota delle DER, ovvero risorse energetiche distribuite quali ad esempio: impianti fotovoltaici, sistemi di accumulo, elettrodomestici, ed altre tipologie di carichi e generatori di energia, a cui VIRTUALENERGY avrebbe avuto accesso grazie alle sinergie attivate con i progetti StoRES e SmartPolygen discusse nella sezione 2.1.
Purtroppo, anche in questo caso, le particolari condizioni di lavoro indotte dalla pandemia di Covid-19 discusse nella sezione 2.2, non hanno consentito di portare a termine le attività pianificate per la validazione della piattaforma realizzata.
4.1 Simulatore e casi uso implementati
Per ovviare a questi inconvenienti e mantenere comunque l'obiettivo di realizzare un proof-of-concept in grado di dimostrare il conseguimento dei risultati attesi, è stato predisposto un sistema di simulazione in sostituzione delle installazioni reali, attraverso cui le aziende hanno comunque avuto modo di apprezzare le funzionalità sviluppate ed i concetti affrontati nell'ambito del cluster.
Il simulatore in questione è un particolare tool presente all’interno della “PowerMatcher Suite”, la soluzione software che si è scelto di utilizzare per implementare le funzionalità di controllo e gestione del VPP, descritta in dettaglio nel documento R.2.1.
In Figura 13 è riportata la pagina iniziale dell’interfaccia utente attraverso cui è possibile interagire con il simulatore, ed in particolare selezionare quale scenario attivare tra quelli che risultano configurati. Ogni scenario consiste in un’applicazione che coinvolge diverse tipologie di componenti. Ogni componente ha un widget ad essa associato. La dashboard può ospitare fino a sei widget per pagina; nel caso in cui sia presente un numero maggiore di componenti, gli ulteriori widget saranno caricati sulla pagina successiva.
Inoltre, una volta attivato lo scenario, sarà possibile accedere a pagine dedicate alla gestione dell’applicazione, attraverso i widget che compariranno nella banda verde in basso sulla dashboard.
Il simulatore mette a disposizione degli utenti 9 configurazioni di base, da cui è possibile partire per realizzare scenari differenti sia per numero che per tipologia di apparati coinvolti. Le versioni simulate degli apparati, sebbene in alcuni casi presentino una dinamica semplificata rispetto a quella dei componenti reali, consentono comunque di apprezzare le funzionalità del sistema di gestione dell’aggregato in termini di utilizzo efficiente delle risorse energetiche disponibili.
4.1.1 Impianto fotovoltaico
Questo scenario è costituito dalla presenza di un solo componente, in grado di produrre energia elettrica, ovvero un impianto fotovoltaico. Una volta avviata la simulazione, è possibile apprezzare una variazione
della dinamica del sistema andando a modificare il tipo di condizioni meteo in cui si trovano a lavorare i pannelli solari dell’apparato in questione.
4.1.2 Impianto fotovoltaico + lavastoviglie
Questo scenario considera la presenza di due apparati, un produttore di energia elettrica, ovvero un impianto fotovoltaico, ed un consumatore di energia elettrica che implementa una logica di avvio flessibile, ovvero una lavastoviglie. In questo caso, la risposta del sistema può essere modificata dall’utente sia agendo sulle condizioni meteo, che influenzano la produzione di energia, sia andando a pianificare la partenza del carico elettrico.
4.1.3 Impianto fotovoltaico + batteria standard
Questo scenario, al posto del carico elettrico considera un componente in grado di immagazzinare energia elettrica, ovvero una batteria di tipo generico, caratterizzata da una dinamica di funzionamento standard.
In questo caso, la risposta del sistema può essere modificata dall’utente solamente agendo sulle condizioni meteo che influenzano la produzione di energia, in quanto la batteria effettua in autonomia il passaggio ai diversi stati di funzionamento (IDLE, CHARGE, DISCHARGE).
4.1.4 Impianto fotovoltaico + batteria standard + lavastoviglie
Questo scenario, agli apparati dello scenario precedente integra un carico elettrico dotato di logica di avvio flessibile, ovvero una lavastoviglie. In questo caso pertanto, l’utente ha modo di influenzare la dinamica del sistema sia agendo sulle condizioni meteo che sull’avvio ritardato dell’elettrodomestico.
4.1.5 Impianto fotovoltaico + batteria standard + lavastoviglie + carico non controllato
Questo scenario contiene tutte le diverse tipologie di apparati simulati disponibili nel simulatore. Oltre all’impianto fotovoltaico con sistema di accumulo ed alla lavastoviglie, è possibile infatti selezionare un ulteriore carico elettrico non controllato, a scelta tra un televisore ed una macchinetta per il caffè. L’unica differenza che di fatto sussiste tra i due carichi simulati è la quantità di potenza assorbita quando uno di essi viene attivato dall’utente. La possibilità di agire anche su questo ulteriore grado di libertà consente di sperimentare ulteriori casi d’uso in cui apprezzare la capacità del sistema di mantenersi in condizioni operative associate ad un utilizzo efficiente dell’energia disponibile.
4.1.6 Impianto fotovoltaico + batteria standard avanzato + lavastoviglie + carico non controllato
L’unica differenza che questo scenario presenta rispetto al precedente è il modello di funzionamento associato all’accumulatore di energia elettrica. In questo caso, l’apparato in questione risulta influenzato dal numero di cicli di carica e scarica a cui è sottoposto, in quanto la sua dinamica subisce un leggero decremento di prestazioni ogni volta che la batteria viene scaricata. Questo aspetto avvicina le simulazioni
effettuate con questo tipo di scenario alle dinamiche di funzionamento che è possibile apprezzare in contesti reali, soprattutto in ambito domestico.
4.1.7 Impianto fotovoltaico + batteria Tesla Powerwall + lavastoviglie + carico non controllato
Questo scenario si differenzia rispetto al precedente per il modello di accumulatore di energia elettrica considerato. In questo caso, l’apparato in questione modella il comportamento di un particolare prodotto disponibile in commercio, ovvero la Tesla Powerwall [8], una batteria in grado di accumulare 7 kWh di energia.
4.1.8 Impianto fotovoltaico + batteria Sony Fortelion + lavastoviglie + carico non controllato
Anche questo scenario fa riferimento ad un particolare modello di accumulatore di energia elettrica presente in commercio. In questo caso, l’apparato in questione modellato nella simulazione è la batteria Sony Fortelion [9], nella sua versione da 4,5 kWh di energia.
4.1.9 Impianto fotovoltaico + batteria Sony Fortelion + lavastoviglie + carico non controllato
Questo scenario è identico al precedente per quanto riguarda il numero e tipo di apparati coinvolti, ma si differenzia per la particolare configurazione del sistema di accumulo, che in questo caso presenta una ridotta quantità di carica iniziale, ed una inferiore capacità di accumulo totale, pari a 1,2 kWh.
Figura 13: Dashboard del simulatore PowerMatcher
4.1.1 Scenario di esempio
Una volta selezionato lo scenario, cliccando sul tasto Activate il sistema carica un certo insieme di componenti, che è possibile configurare attraverso il pannello di amministrazione mostrato in Figura 14.
Figura 14: Pannello di amministrazione per la gestione dei componenti PowerMatcher
Ogni volta che viene attivato un nuovo scenario, il sistema aggiorna anche la configurazione dei componenti; i dettagli della nuova configurazione operativa saranno visualizzabili attraverso un refresh della pagina di amministrazione. In realtà il processo di configurazione, effettuato in maniera automatica dal sistema attraverso la selezione di uno degli scenari disponibili dal menù a tendina dell’interfaccia utente, potrebbe essere realizzato anche manualmente attraverso il pannello di amministrazione.
In Figura 15 è riportato uno scenario di esempio, selezionato tra quelli disponibili. In questo caso, si nota come oltre ai widget nella dashboard, ora compaiano anche altre icone nella fascia verde in basso.
In questo scenario di esempio, riconducibile ad una configurazione in linea con gli attuali standard abitativi di un singolo nucleo familiare, troviamo le simulazioni di diversi dispositivi, tra cui in particolare: una batteria, un pannello fotovoltaico, una lavastoviglie, ed un elettrodomestico a scelta tra un televisore o una macchinetta per il caffè. Inoltre, è presente un widget, relativo all’applicazione PowerMatcher, che mostra gli stati del cluster.
Quest’ultimo widget mostra l’attuale prezzo di mercato, gli agenti al momento attivi e la loro offerta corrente, che in pratica riflette il livello di flessibilità dell’apparato che essi rappresentano.
Figura 15: Simulazione scenario PowerMatcher
Nella pagina relativa all’applicazione PowerMatcher, mostrata in Figura 16, è possibile osservare gli andamenti temporali delle offerte che ogni singolo agente dispositivo invia all’agente concentratore, ed il corrispondente aggregato di offerte ricevuto dall’agente concentratore, rappresentati attraverso la linea di colore giallo nei grafici; la linea verticale azzurra rappresenta invece il prezzo che ogni agente dispositivo riceve dal concentratore, ovvero il prezzo che l’agente banditore invia agli agenti ad esso connessi.
Attraverso il widget relativo al pannello fotovoltaico, mostrato in Figura 15, è possibile simulare una variazione delle condizioni meteo. In particolare, è possibile ad esempio passare dalla notte al giorno. In corrispondenza di questo cambio di stato, il valore della potenza prodotta dal modulo comincia a diventare positivo, ovvero il pannello produce energia, e di conseguenza la batteria comincia a caricare.
I grafici mostrati in Figura 16 fanno riferimento a questa particolare condizione operativa. In particolare, è possibile osservare come l’agente che rappresenta l’impianto fotovoltaico rifletta un comportamento non flessibile, presentando tuttavia una produzione di energia pari a circa 2kW (in PowerMatcher per convenzione i valori positivi indicano potenza assorbita, mentre quelli negativi corrispondono a potenza prodotta). E’ possibile inoltre notare come invece la batteria esponga un certo livello di flessibilità. In particolare, in corrispondenza di un prezzo molto basso dell’energia, l’apparato si mostra disponibile a consumare, ovvero a caricarsi, mentre per prezzi elevati espone la propria disponibilità a scaricarsi, ovvero a produrre energia.
Il dispositivo non controllato, che in questo caso particolare risulta essere la macchinetta del caffè, presenta una potenza assorbita costante pari a 1500W.
Nel grafico in alto a sinistra è rappresentato l’andamento dell’aggregato di offerte, che in questo caso è costituito dalla somma delle offerte di: batteria, pannello solare, lavastoviglie e macchinetta per il caffè.
Come osservato nel documento R.2.1, l’agente banditore cerca di trovare il punto di equilibrio, ovvero il valore più vicino a zero, che in questo caso corrisponde al minimo prezzo.
Analizzando le singole offerte corrispondenti al punto di minimo prezzo, si nota come il pannello solare in questa condizione particolare si troverà a produrre energia, mentre la batteria risulterà essere in carica, in quanto assorbirà l’energia prodotta dal pannello.
L’agente che rappresenta la macchinetta del caffè, ovvero il carico non controllato, una volta attivato, espone un’offerta corrispondente ad una domanda non flessibile, e di conseguenza porta l’agente banditore a modificare il punto di equilibrio, perchè ora il valore dell’offerta aggregata più vicino a zero risulta associato ad un valore di prezzo minimo non nullo.
Il valore di prezzo minimo non nullo corrisponde alla condizione in cui il sistema si trova ad incentivare i produttori ad immettere la loro energia in rete.
Figura 16: Pagina dell’applicazione PowerMatcher
In Figura 17 è mostrata la pagina attraverso cui è possibile gestire le connessioni tra i componenti dell’applicazione PowerMatcher, che in pratica mostra in che modo i diversi componenti presenti nello scenario stanno comunicando tra di loro.
Figura 17: Pagina di gestione delle connessioni PowerMatcher
Bibliografia
[1] «CoNetDomeSys,» [Online]. Available: https://sites.google.com/site/conetdomesys/conetdomesys.
[2] «https://www.pfsense.org/,» [Online]. Available: https://www.pfsense.org/.
[3] «StoRES,» [Online]. Available: https://stores.interreg-med.eu.
[4] «SmartPolyGen,» [Online]. Available:
https://www.sardegnaricerche.it/index.php?xsl=370&s=358926&v=2&c=15067&nc=1&sc=.
[5] P. A. G. A. Franceschelli M., «Multi-Agent Coordination of Thermostatically Controlled Loads by Smart Power Sockets for Electric Demand Side Management,» [Online]. Available:
https://ieeexplore.ieee.org/document/9043754.
[6] «WeMo Insight Smart Plug,» [Online]. Available: https://www.belkin.com/us/p/P-F7C029/.
[7] «SQLite,» [Online]. Available: https://www.sqlite.org/index.html.
[8] «Tesla Powerwall,» [Online]. Available: https://www.tesla.com/it_IT/powerwall.
[9] «Sony Fortelion,» [Online]. Available: https://batterytestcentre.com.au/batteries/sony-fortelion/.
