Il progetto in sintesi
Una centralina energetica deve trasformare misure, limiti e richieste dell’utente in comportamenti comprensibili. L’accensione del forno durante la ricarica dell’auto modifica il prelievo dalla rete; il passaggio di una nuvola cambia il margine disponibile per utenze flessibili e accumulo. SLX SolarPilot permette di verificare questa catena completa: applicazione touch, controllo embedded, protocolli di comunicazione e un impianto domestico simulato in 3D.
Il progetto comprende una centralina Linux con interfaccia LVGL e un simulatore Windows. Nel banco dimostrativo il PC rappresenta fotovoltaico, batteria, abitazione, elettrodomestici e veicolo elettrico. La centralina riceve le grandezze attraverso la rete e invia comandi che modificano il modello. Il collegamento usa uno stack EEBUS effettivo: la scena virtuale rende visibile l’effetto dei messaggi, mentre il software embedded viene eseguito su una Raspberry Pi fisica.
Il dettaglio di potenze, rendimenti e interoperabilità è trattato nell’approfondimento Fotovoltaico e ricarica EV: EEBUS e Linux embedded in SLX SolarPilot. Il repository pubblico e la versione Windows 0.4.5 permettono di esplorare il dimostratore.
Applicazione touch
L’interfaccia è progettata per un display Hamtysan HDMI touch da 10,1 pollici, 1024 × 600 pixel. La navigazione principale rimane riconoscibile durante l’uso: Panoramica, Energia, Carichi, Impianto, Ricarica, Eventi e Sistema. Le schermate di dettaglio raccolgono parametri e operazioni senza trasformare la pagina principale in un pannello di configurazione permanente.
La Panoramica mette in relazione produzione fotovoltaica, consumo dell’abitazione, accumulo, ricarica EV e rete elettrica. I flussi animati aiutano a distinguere dove sta andando l’energia. Potenze e stato di carica hanno unità e convenzioni dichiarate: nella schermata dell’accumulo una potenza negativa indica carica, una positiva indica scarica. È un dettaglio operativo importante quando si confrontano display, protocollo e registrazioni.
La pagina Energia conserva il contesto dei consumi; Carichi permette di osservare e comandare gli apparecchi del banco; Impianto raccoglie configurazione fotovoltaica, riserva e limiti dell’accumulo. Ricarica presenta modalità e obiettivi del veicolo. Eventi e stato della comunicazione aiutano a interpretare un risultato senza confondere una misura recente con un valore rimasto a schermo.
Comandi grandi, feedback alla pressione, tastiera a schermo, conferme e finestre di configurazione fanno parte dell’esperienza d’uso. Anche il comportamento asincrono conta: una ricerca Wi-Fi completata in ritardo non deve sostituire la pagina in cui l’utente sta inserendo una rete manualmente. Le risposte del servizio vengono quindi associate alla richiesta e al contesto dell’interfaccia.
Architettura del sistema
Il simulatore calcola l’evoluzione dell’impianto; l’EMS, Energy Management System, sceglie come usare la flessibilità disponibile; la HMI, Human-Machine Interface, presenta dati e comandi. Questa separazione consente di verificare ciascun passaggio: un comando è stato accettato? Il limite è cambiato? La potenza risultante rispetta il nuovo vincolo? Il display sta mostrando lo stato aggiornato?
Impianto virtuale
Il PC calcola fotovoltaico, accumulo, carichi ed EV e rende visibili gli effetti nella casa 3D. C++20, OpenGL, Dear ImGui e ImPlot gestiscono modello e strumenti di osservazione.
Controllo embedded
Il servizio EMS esegue strategie, conserva la configurazione e applica i comandi verso il banco, separatamente dalla pagina visualizzata.
Applicazione touch
LVGL presenta flussi, carichi, ricarica e impostazioni. C/C++ ed eventi asincroni mantengono distinti rendering, interazione e operazioni di rete.
Comunicazione energetica
EEBUS SHIP/SPINE trasporta misure e comandi. I percorsi SunSpec Modbus TCP espongono i modelli standard dichiarati dal simulatore.
Il controllo embedded è un servizio distinto dalla GUI e non richiede che la finestra del simulatore decida ogni azione. Durante queste prove il PC rimane la sorgente dell’impianto virtuale: arrestarlo interrompe quella sorgente di misure. La gestione di dati scaduti e perdita del collegamento fa quindi parte delle verifiche, insieme al recupero della comunicazione.
Linux embedded essenziale
La piattaforma scelta è Raspberry Pi 3 Model A+, con processore Cortex-A53, 512 MB di RAM e Wi-Fi integrato. È una base utile per progettare un’applicazione che deve impiegare le risorse in modo consapevole. La connettività del banco passa dal router Wi-Fi; non dipende da una porta Ethernet della scheda.
La distribuzione utilizza Buildroot per assemblare toolchain, kernel, filesystem e servizi richiesti. La configurazione del progetto usa Buildroot 2026.08.1, Linux 6.12.61 e un ambiente ARM a 32 bit. L’avvio porta dal logo Silicon LogiX all’applicazione, con un’animazione che rende percepibile il caricamento.
La distribuzione include i servizi necessari al funzionamento: supervisione di controllo e interfaccia, autenticazione Wi-Fi, acquisizione dell’indirizzo, sincronizzazione dell’ora e gestione dei dati persistenti. Il filesystem di sistema è in sola lettura; configurazioni e storico utilizzano un’area dati dedicata. Questa organizzazione separa il software distribuito dalle informazioni che cambiano durante l’uso.
La configurazione Wi-Fi può essere inserita dal display oppure importata attraverso un file sulla partizione accessibile della microSD. L’importazione valida i campi e trasferisce la configurazione nell’area persistente; il file attivo viene rimosso dopo il completamento. La manutenzione dispone anche di una console seriale con comandi applicativi validati, senza esporre una shell nell’interfaccia operatore.
LVGL e visualizzazione 3D
LVGL offre widget, eventi e rendering per interfacce embedded. In SolarPilot gestisce pagine, pulsanti, campi numerici, tastiera e visualizzazione dei flussi. Gli aggiornamenti interessano gli elementi che cambiano; l’interazione rimane separata dalle operazioni di rete che possono richiedere più tempo.
Il profilo video usa il framebuffer disponibile sulla piattaforma, mantenendo il modo HDMI qualificato con il display del banco. La documentazione del driver framebuffer LVGL descrive questo percorso, che permette di disegnare direttamente senza introdurre un desktop o un browser. Le prestazioni dipendono comunque da risoluzione, formato dei pixel, quantità di aggiornamenti e configurazione del driver: il nome della libreria, da solo, non costituisce una misura di fluidità.
Sul PC, OpenGL visualizza l’abitazione e i suoi componenti. Dear ImGui e ImPlot organizzano controlli e grafici. Il modello energetico viene eseguito attraverso un’API separata dal renderer: cambiare la visuale della casa non cambia i calcoli, mentre modificare un carico produce un nuovo stato elettrico che l’interfaccia può rappresentare.
Impianto virtuale e calcoli
Il banco comprende falde fotovoltaiche configurabili, inverter, accumulo, utenze domestiche e ricarica del veicolo. Ora, mese, copertura nuvolosa e temperatura permettono di esplorare condizioni diverse. La potenza nominale dei pannelli, il limite dell’inverter e la capacità della batteria rimangono parametri distinti: aumentare i moduli non aumenta automaticamente tutti gli altri componenti.
Anche gli elettrodomestici hanno un comportamento nel tempo. La lavatrice attraversa fasi con assorbimenti differenti; il forno alterna preriscaldamento e mantenimento; un ciclo già avviato può avere una priorità diversa da una nuova richiesta di partenza. Questo rende possibile discutere una strategia energetica considerando sia la potenza disponibile sia il servizio che si vuole completare.
Il motore conserva potenze, energie e stato di carica. Nel modello di base l’accumulo ha capacità di 10 kWh e limiti di potenza di 3 kW per direzione; il rendimento dichiarato è del 95% in carica e del 95% in scarica. La ricarica EV tiene conto della capacità, dell’obiettivo e dell’energia effettivamente trasferibile nell’intervallo. Questi numeri descrivono la configurazione dimostrativa, non una batteria commerciale specifica.
I riferimenti mensili PVGIS del Joint Research Centre consentono un confronto con rese storiche modellate per Bologna, Roma e Palermo. Il software conserva le risposte e i parametri usati. Questi riferimenti restano separati dalla simulazione istantanea e dalle sue nuvole sintetiche.
Protocolli e interoperabilità
SolarPilot adotta due percorsi con finalità complementari: EEBUS SHIP/SPINE per il coordinamento energetico del banco e SunSpec Modbus TCP per i modelli di dispositivi supportati. Il significato di una misura, l’identità del partner e la validità temporale del controllo rimangono espliciti. Il dettaglio dei telegrammi è sviluppato nell’approfondimento tecnico sui protocolli.
EEBUS: connessione, associazione e discovery
Il banco utilizza SHIP 1.0.1 e SPINE 1.3.0 attraverso lo stack Enbility in Go. La scoperta mDNS/DNS-SD del servizio _ship._tcp, oppure l’indirizzo impostato manualmente, permette di individuare il nodo. TCP, TLS e WebSocket preparano il canale; l’associazione conferma il partner attraverso l’identità conservata.
SKI, fingerprint e SHIP ID sono registrati per il peer scelto. L’indirizzo IP resta una coordinata di rete, non un’autorizzazione. Dopo il collegamento, l’inventario SPINE permette di individuare entità e feature disponibili, evitando di assegnare a un dispositivo generico gli indirizzi fissi del profilo SLX.
Dal messaggio SPINE al cambiamento della potenza
Le misure del percorso MPC arrivano attraverso measurementListData, con scala, unità, timestamp e provenienza. I limiti LPC/LPP utilizzano loadControlLimitListData. msgCounter e msgCounterReference collegano richieste e risultati: una scrittura accettata va poi verificata sulle nuove misure del modello.
Il profilo completo espone rete, casa, PV, batteria, EVSE, lavatrice, lavastoviglie e PV disponibile. Il controllore di riferimento esclude misure più vecchie di tre secondi; nel banco SLX il rinnovo dei comandi è sorvegliato da un watchdog locale. Questi tempi di laboratorio non costituiscono la macchina di stato normativa completa dei casi d’uso EEBUS.
SunSpec: modelli, scale e comandi dichiarati
Nel percorso server, le Unit ID 1, 2 e 3 rappresentano PV, contatore e accumulo. La firma SunS e la sequenza di identificativi e lunghezze dei blocchi permettono al client di scoprire i modelli presenti. Il server parte dalla porta 1502 configurabile; il numero della porta e il mapping delle unità non vanno assunti uguali su tutti i prodotti.
- Fotovoltaico: modelli 1, 101, 120 e 123; misure e limiti percentuali della produzione nei punti implementati.
- Rete: modelli 1 e 201; potenza ed energia importata o esportata secondo le convenzioni dichiarate.
- Accumulo: modelli 1, 101, 120 e 124; SOC, limiti di carica e scarica e riserva.
I tipi dei punti, i fattori di scala con segno e i sentinel di dato non disponibile sono parte della decodifica. La relazione valore = grezzo × 10^SF evita di confondere, per esempio, una potenza quantizzata a 10 W con il valore fisico esatto calcolato dal core. Scritture, rilettura e osservazione delle misure costituiscono passaggi distinti del collaudo.
Monitor applicativo e confini di compatibilità
Il monitor EEBUS osserva il corpo applicativo SHIP ai due estremi dello stack; non è un PCAP del traffico TLS. Consente di correlare messaggi, esiti e stato dell’impianto. Le osservazioni in trasmissione e ricezione possono appartenere allo stesso telegramma e non devono essere sommate come traffico indipendente.
L’estensione opzionale SLX Energy/1, separata dai modelli SunSpec, aggiunge funzioni proprie del banco per EV e consensi dei lavaggi. I percorsi standard dichiarati per PV e accumulo rimangono utilizzabili senza adottarla. Il listener Modbus TCP ordinario e il canale EEBUS sicuro hanno caratteristiche di sicurezza differenti.
La matrice di interoperabilità, il contratto EEBUS del banco e le specifiche SunSpec rendono verificabile il perimetro. L’integrazione di un apparato commerciale richiede commissioning e prove su ruoli, funzioni, limiti e temporizzazioni; il dimostratore non dichiara certificazione o compatibilità universale.
Prove interattive
Una prova rappresentativa parte da una situazione di surplus. L’operatore osserva i flussi, modifica una richiesta di ricarica e accende un carico domestico. Il collegamento trasporta i comandi; il motore ricalcola produzione, consumi, potenza dell’accumulo e scambio con la rete. Il display torna a mostrare l’effetto delle decisioni attraverso le nuove misure.
- Avviare la versione Windows ed esplorare la Panoramica con il controllo locale.
- Se si utilizza la centralina, configurare Wi-Fi e collegamento al banco e verificare le identità dei due estremi.
- Impostare riserva dell’accumulo, modalità EV e richieste dei carichi.
- Cambiare una condizione alla volta: accensione del forno, copertura nuvolosa, passaggio serale o limite di potenza.
- Confrontare misure, eventi e messaggi effettivamente scambiati.
- Registrare la sessione o esportare i dati per ripetere e discutere la prova.
Le prove con protocolli esterni lavorano in tempo reale, a 1×. Il laboratorio locale può accelerare gli scenari per confrontare le policy. Mantenere distinte queste due scale temporali evita di interpretare un’ora simulata come un’ora di osservazione del dispositivo fisico.
Verifiche e disponibilità
La build pubblica Windows viene compilata anche su GitHub Actions. I nove gruppi di test comprendono scenari energetici, oracoli numerici indipendenti, strategie EMS, host asincrono e registrazione, geometria delle scale, conservazione delle release e comunicazione tra processi. La documentazione delle verifiche ne descrive il campo.
Sono state eseguite anche prove su Raspberry Pi fisica, con collegamento EEBUS al PC e variazioni della ricarica osservate nel modello. Le successive revisioni sono state accompagnate da verifiche native e ARM emulate. La qualificazione di un prodotto finale richiede comunque prove ripetute sulla revisione hardware e software scelta, sui dispositivi di campo e sulle condizioni operative previste.
La distribuzione Windows include programma, interfaccia e SDK pubblici; il core e il servizio dei protocolli sono forniti come binari. La licenza è Silicon LogiX Evaluation License 1.0. Firmware della centralina e sorgenti riservati non sono inclusi in quel download.
Adattatori per apparecchi specifici, previsioni operative, tariffe dinamiche, ottimizzazione predittiva, impianti multipli e collaudi hardware dedicati sono attività da definire su richiesta. Il dimostratore offre una base per discutere requisiti e casi critici, senza presentare queste estensioni come già operative.
Le attività di sviluppo su misura comprendono HMI LVGL, Linux embedded, software desktop e integrazione dei protocolli. La richiesta di una valutazione tecnica può indicare apparecchi da collegare, interfacce disponibili, vincoli di potenza, comportamento desiderato e criteri di accettazione.
