La colonnina è potente, l’auto è collegata e la sessione risulta autorizzata. Eppure la ricarica rallenta. La causa può essere nella batteria, nel raffreddamento, nel cavo o nella potenza disponibile per l’intero sito. Per chi sviluppa un BMS, una stazione di ricarica o il software di una flotta, la domanda utile è molto concreta: quale vincolo sta limitando la potenza e il veicolo sarà pronto alla partenza?
Ho realizzato SLX ChargeProof per esplorare questa relazione in un laboratorio desktop: cambiare una condizione, osservare la risposta del sistema e conservare una prova leggibile. Il progetto combina un modello elettrotermico in C++20, una comunicazione locale OCPP 2.0.1 su WebSocket, un campus 3D in OpenGL e strumenti per diagnosi, registrazione e replay. La preview Windows è disponibile su GitHub: batterie e colonnine sono simulate, mentre il software e lo scambio dei messaggi vengono eseguiti sul PC.
Perché la ricarica di un’auto elettrica rallenta
I kilowatt indicati su una colonnina descrivono una capacità dell’infrastruttura, non una potenza garantita per tutta la sessione. Il BMS, Battery Management System, stabilisce quali condizioni di carica sono accettabili per il pacco. La stazione deve rispettare anche i propri limiti elettrici, quelli del collegamento e l’eventuale budget condiviso con altre utenze.
Per interpretare un tempo di ricarica occorre distinguere potenza, in kW, ed energia, in kWh. Un esempio semplificato: una batteria con 75 kWh utilizzabili, dal 20% all’80%, richiede circa 45 kWh aggiuntivi. Con una potenza media effettivamente accumulata di 90 kW servirebbero 30 minuti. Un picco istantaneo di 180 kW, da solo, non permette di dimezzare questa previsione: conta la potenza mantenuta lungo la sessione.
Tempo indicativo [h] = energia da accumulare [kWh] / potenza media accumulata [kW]
È un conto orientativo a capacità utilizzabile costante: se si usa invece la potenza prelevata dalla rete, vanno considerate le perdite di conversione e gli ausiliari. L’Alternative Fuels Data Center del Department of Energy richiama proprio capacità, stato di carica, veicolo e infrastruttura tra i fattori che determinano la durata.
Lo stato di carica, o SOC, e la temperatura cambiano durante il processo. Avvicinandosi ai limiti di tensione delle celle, la corrente deve diminuire; con una batteria troppo fredda o troppo calda, il controllo può ridurre ulteriormente la richiesta. Il passaggio alla fase più lenta non avviene a una percentuale universale: dipende dal pacco e dalla strategia del costruttore. Una curva che scende può quindi descrivere un comportamento previsto, oppure un’anomalia da diagnosticare.
Ricarica AC e DC: dove avviene la conversione
Una batteria si carica in corrente continua. Nella ricarica AC, la conversione dalla corrente alternata è affidata al caricatore a bordo del veicolo, l’On-Board Charger o OBC. Nella ricarica DC, la conversione principale è esterna al veicolo. La documentazione tecnica Texas Instruments su EV ed EVSE illustra questa distinzione e il ruolo delle comunicazioni tra auto e infrastruttura.
| Aspetto | Ricarica AC | Ricarica DC |
|---|---|---|
| Conversione principale AC/DC | Caricatore a bordo del veicolo | Elettronica di potenza esterna al veicolo |
| Un vincolo da verificare | Capacità dell’OBC e alimentazione disponibile | Intervallo di tensione e corrente di stazione, cavo e batteria |
| Contesto applicativo | Soste compatibili con la potenza dell’OBC | Sessioni che richiedono maggiore potenza, entro i limiti del sistema |
Anche la tensione ha conseguenze pratiche. In un confronto ideale a 200 kW, 400 V richiedono 500 A e 800 V richiedono 250 A. A parità di resistenza del tratto considerato, dimezzare la corrente porta le sue perdite resistive I²R a un quarto. Questo confronto non implica che tutte le perdite del veicolo si riducano allo stesso modo: cambiano componenti, conversioni, isolamento e condizioni operative.
Il Combined Charging System, CCS, riguarda l’insieme delle interfacce di ricarica e della loro interoperabilità. OCPP riguarda invece un collegamento software diverso. Riconoscere questi livelli evita di attribuire a un protocollo funzioni che appartengono al caricatore o al veicolo.
BMS e modello elettrotermico: collegare corrente, SOC e temperatura
In un sistema reale, il BMS raccoglie misure di tensione, corrente e temperatura, stima stati come il SOC e applica protezioni e limiti di funzionamento. La temperatura letta da un sensore, però, non descrive automaticamente ogni punto del pacco. Anche una misura formalmente valida può essere poco rappresentativa, avere un offset o restare bloccata.
ChargeProof rende osservabili questi legami con un circuito equivalente di tipo Thevenin: una tensione a circuito aperto dipendente dal SOC, una resistenza e un ramo RC per la risposta transitoria. Il modello aggiorna carica, polarizzazione e comportamento termico con un passo fisso di 0,5 secondi virtuali. La documentazione del modello Thevenin di PyBaMM offre un riferimento sul tipo di formulazione; PyBaMM non è una dipendenza eseguita da ChargeProof.
La preview propone tre profili sintetici: compatta LFP, SUV NMC di classe 800 V e van LFP. Sono ipotesi ingegneristiche dichiarate, utili per confrontare comportamenti e vincoli. Non rappresentano dati di un modello commerciale di automobile. Due aggregati rappresentativi distinguono il comportamento principale del pacco da quello di un blocco debole; le numerose celle visibili nella scena non corrispondono ad altrettanti modelli termici indipendenti.
Questa scelta permette di seguire una catena causale comprensibile: cambia il raffreddamento, cambia la temperatura calcolata, cambia la corrente accettata e cambia l’energia che può essere accumulata prima della partenza. La ricerca sui limiti della ricarica rapida pubblicata dal DOE mostra quanto siano intrecciati trasporto, temperatura e fenomeni elettrochimici. Il modello dimostrativo semplifica questi fenomeni e non calcola il degrado elettrochimico della cella.
OCPP, ISO 15118 e Plug & Charge: protocolli con ruoli diversi
OCPP collega una stazione di ricarica al sistema che la gestisce, il CSMS, Charging Station Management System. La famiglia ISO 15118 riguarda invece la comunicazione tra veicolo ed EVSE, l’apparato che fornisce energia al veicolo. Separare i due collegamenti è essenziale per progettare autorizzazione, controllo e diagnostica.
| Livello | Funzione | Nella preview |
|---|---|---|
| Veicolo / BMS | Richiesta di carica e limiti della batteria | Emulazione numerica con profili sintetici |
| Veicolo ↔ EVSE | Comunicazione di ricarica, anche tramite ISO 15118 | Nessuno stack ISO 15118 |
| EVSE ↔ CSMS | Autorizzazioni, stato e transazioni OCPP | Sottoinsieme OCPP 2.0.1 su WebSocket locale |
| Plug & Charge | Identificazione automatica basata su certificati e infrastruttura di fiducia | Non implementato |
Nel laboratorio, client di stazione e server locale scambiano realmente messaggi JSON: BootNotification, Heartbeat, Authorize, StatusNotification e TransactionEvent, con i valori di misura inclusi negli eventi di transazione. È possibile conservare richieste e risposte e collegarle alla sessione. Un messaggio di autorizzazione OCPP non equivale a una procedura Plug & Charge.
Come spiega CharIN nella descrizione di Plug & Charge, l’automazione dell’identificazione richiede interfacce standard e meccanismi di sicurezza. Un’integrazione concreta deve gestire certificati, catene di fiducia e ciclo di vita delle credenziali. La preview non include questa PKI, né un collegamento TLS a un backend esterno: il CSMS di valutazione ascolta soltanto sull’interfaccia locale del PC.
La Open Charge Alliance documenta OCPP 1.6, 2.0.1 e 2.1 e le rispettive funzioni. ChargeProof usa il sottoinsieme 2.0.1 dichiarato nella propria copertura dei protocolli; non dichiara l’implementazione completa dello standard o una certificazione OCA.
Smart charging: il limite del sito e l’orario di partenza
In un deposito con più veicoli, ogni sessione compete per una risorsa condivisa. La somma delle potenze nominali delle colonnine può superare ciò che l’allacciamento permette di prelevare. Occorre quindi coordinare richieste delle batterie, disponibilità delle stazioni e consumo degli ausiliari.
ChargeProof distingue richiesta EV/BMS, comando alla stazione e potenza effettivamente erogata. Sono tre quantità che possono divergere. Un BMS può accettare molta potenza mentre il sito ne concede poca; una stazione può ricevere un comando elevato mentre un limite del cavo impone una riduzione. Riportando tutti i vincoli allo stesso confine elettrico, la potenza applicata deve restare entro ciascuno di essi.
Il controllore dimostrativo distribuisce la potenza con un criterio max-min fair: ripartisce il budget tra le richieste ammissibili e redistribuisce le quote non utilizzabili. Il calcolo considera conversione e ausiliari prima di assegnare la potenza DC. Non è un ottimizzatore economico di flotta: tariffe, turni reali, fotovoltaico e accumulo attivo richiedono un progetto dedicato.
La previsione alla partenza aggiunge una domanda operativa al valore istantaneo in kW. Usa una copia isolata del modello e mantiene costanti le ipotesi correnti su guasti, autorizzazioni, ambiente e budget del sito. Il risultato descrive che cosa accadrebbe se quelle condizioni restassero valide; non anticipa un intervento di recupero che l’operatore non ha ancora effettuato.
Le tecnologie di ChargeProof: C++20, OCPP e grafica nativa
La pagina iniziale ChargeProof Studio presenta i quattro livelli del software e collega ciascuno a una verifica osservabile. La scena 3D, i messaggi e i report fanno riferimento alla stessa sessione: l’utente può passare dalla domanda «perché sta rallentando?» al vincolo numerico e alla sua registrazione.
- Core C++20 e SDK versionato. Il calcolo viene eseguito in un processo separato, collegato al desktop tramite pipe private. Lo stesso core alimenta le sessioni interattive e gli scenari senza interfaccia grafica.
- GLFW, Dear ImGui docking e OpenGL 3.3. GLFW gestisce finestra e contesto grafico; Dear ImGui compone i pannelli tecnici; OpenGL rappresenta campus, ispezioni e display aggiornati. L’applicazione è un desktop nativo C++.
- OCPP 2.0.1 e WebSocket. Client WinHTTP e server WinSock eseguono lo scambio locale, rendendo disponibili i messaggi effettivamente trasmessi.
- Registrazioni e report. Eventi, ingressi, stati e risultati restano collegati a una sessione, con esportazioni HTML, JSON e CSV per analisi e confronto.
Il campus comprende cinque piazzole ispezionabili. Tre hanno un profilo elettrico operativo; bus e camion sono presenti come geometrie per l’ispezione. La visualizzazione aiuta a localizzare ciò che si sta osservando, mentre la documentazione del modello chiarisce quali stati vengono realmente calcolati.
Un esperimento: dal 72% previsto all’80% osservato
La diagnosi guidata parte da un SUV sintetico al 25% di SOC e a 48 °C, con un obiettivo dell’80% dopo venti minuti virtuali e un limite AC di sito di 500 kW, condiviso dalle sessioni abilitate. Questi valori definiscono un esperimento del dimostratore; non sono indicazioni operative per una batteria reale.
Dopo l’autorizzazione, la previsione nominale indica che il target è raggiungibile. Il percorso introduce poi un degrado del raffreddamento e lo mantiene fino al checkpoint dei dieci minuti. Il modello riduce la potenza accettabile e la previsione scende a circa il 72%. Ripristinando il raffreddamento, il calcolo torna a prevedere l’80%; la simulazione prosegue e conserva anche il SOC effettivamente integrato alla partenza.
| Momento della diagnosi | Indicazione | Come leggerla |
|---|---|---|
| Condizioni nominali | 80,0% previsto | Target raggiungibile mantenendo le condizioni correnti |
| Guasto, al minuto 10 | Circa 72,0% previsto | Stima alla partenza se il raffreddamento resta degradato |
| Dopo il recupero | 80,0% previsto | Nuova stima con il raffreddamento ripristinato |
| Partenza, al minuto 20 | 80,0% osservato nel modello | Risultato della simulazione che ha incluso il recupero |
Il punto interessante è il confronto tra causa, conseguenza e intervento. Il solo valore finale dell’80% nasconderebbe il problema attraversato dalla sessione; il solo allarme di raffreddamento non direbbe quanto pesa sull’obiettivo di partenza. Conservare entrambi permette di discutere il comportamento del controllo e il momento in cui il recupero torna utile.
Guasti, messaggi e bilancio energetico: leggere le evidenze
La preview comprende perdita del backend, offset del sensore, raffreddamento degradato, riduzione del modulo di potenza, blocco batteria debole e riscaldamento del cavo, oltre a una variante con sensore bloccato. Ogni scenario mette in evidenza un confine diverso del sistema.
Il caso del sensore distingue la temperatura fisica calcolata dal valore ricevuto dal controllore: introdurre un offset nella misura non modifica artificialmente lo stato termico. Il caso del backend interrompe il socket locale; le transazioni già autorizzate possono proseguire secondo la politica dimostrativa, mentre nuove autorizzazioni vengono respinte fino al recupero. Gli eventi sono accodati in memoria per il successivo invio; la coda non è uno storage persistente in caso di arresto del programma.
Anche l’energia richiede confini chiari. Il software distingue prelievo AC, energia al terminale DC, energia accumulata, perdite e ausiliari. Il contatore trasportato nei messaggi del dimostratore si riferisce al terminale DC del pacco e non è una misura fiscale dei consumi. La chiusura del bilancio verifica la coerenza dei conti del modello; non dimostra che i parametri descrivano una batteria reale.
La verifica automatica della versione pubblicata ha compilato il desktop Windows ed eseguito sette scenari senza GUI, controllando tra l’altro vincoli di sito, bilanci energetici e ciclo delle transazioni. La documentazione delle verifiche descrive campo e limiti dei controlli.
Il replay rilegge una registrazione senza far avanzare il modello o inviare nuovi messaggi. Una nuova simulazione, invece, ricalcola il comportamento dagli ingressi. Il confronto A/B incluso usa lo stesso controllore e una baseline senza guasti: confrontare due versioni di firmware richiederebbe una campagna distinta con binari e configurazioni conservati.
MCS e V2G: perché richiedono un progetto distinto
La ricarica dei mezzi pesanti porta il problema a una scala diversa: più energia da trasferire, tempi di sosta vincolati e maggiore attenzione a conduttori, contatti e raffreddamento. Il Megawatt Charging System, MCS, descritto da CharIN affronta un sistema di interfacce per queste applicazioni. Non basta aumentare un numero di kW in un simulatore per rappresentarne le caratteristiche.
Il Vehicle-to-Grid, V2G, aggiunge il trasferimento di energia dal veicolo verso la rete. ISO 15118-20:2022 definisce anche messaggi e sequenze per il trasferimento bidirezionale; l’emendamento del 2026 tratta ulteriori servizi, tra cui MCS e un concetto di sicurezza aggiornato. La comunicazione è una parte del progetto: servono anche elettronica bidirezionale, controllo e requisiti dell’interfaccia di rete.
Queste funzioni non sono operative nella preview ChargeProof. Lo stesso vale per ISO 15118, Plug & Charge, OCPP 2.1 e collegamenti a CSMS esterni. Presentarle accanto al dimostratore aiuta a collocare la ricarica nel suo ecosistema, mantenendo chiaro che cosa il programma permette effettivamente di provare.
Come provare SLX ChargeProof su Windows
Per partire, apri la release 0.1.0-preview-r5 e scarica SLX-ChargeProof-0.1.0-preview-r5.zip. Estrai tutto l’archivio e avvia SLX-ChargeProof.exe, mantenendo insieme eseguibile, risorse, core e licenze. Sono richiesti Windows 10/11 x64 e un driver grafico OpenGL 3.3. La release include i checksum SHA-256 ed è una preview di valutazione non firmata.
Scegli Start guided diagnosis per seguire i checkpoint del caso SUV. Dopo il risultato finale puoi aprire il report, consultare i messaggi o passare al laboratorio libero. L’uso del pacchetto portatile non richiede compilatore, Python, account o hardware di ricarica.
Il repository pubblico slx-chargeproof contiene sorgenti dell’interfaccia e degli adattatori, SDK e documentazione. Il motore numerico proprietario è distribuito come binario di valutazione. Le condizioni sono nella Silicon LogiX Evaluation License 1.0; i componenti di terze parti mantengono le rispettive licenze. Per eseguire direttamente il programma serve lo ZIP portatile, mentre l’archivio dei sorgenti serve a ricompilare l’interfaccia.
Dal laboratorio virtuale a un sistema di ricarica reale
ChargeProof permette di discutere architettura, diagnostica e criteri di prova prima di collegare un banco fisico. Per passare a un progetto specifico occorrono dati delle celle e del pacco, curve OCV e resistenze in funzione di SOC e temperatura, caratteristiche del raffreddamento, limiti elettrici e requisiti delle interfacce. Solo il confronto con misure e prove nel campo operativo scelto può qualificare il modello per quell’impiego.
Su questa base si possono definire firmware BMS ed EVSE, adattatori di protocollo, interfacce operatore e campagne di verifica software-in-the-loop o hardware-in-the-loop, specificando target, clock e criteri di accettazione. Un simulatore con parametri sintetici non sostituisce prove elettriche, termiche, di interoperabilità o di sicurezza del prodotto.
Il metodo è affine a quello dei laboratori SLX CellProof per la robotica e SLX GridPilot per OPC UA: rendere esplorabile un comportamento e conservare il collegamento tra ingressi, eventi e risultato. Per una soluzione di ricarica su misura, il primo passo è definire con Silicon LogiX il problema da verificare e i dati disponibili.
Domande frequenti sulla simulazione della ricarica
Perché un’auto non assorbe tutta la potenza della colonnina?
La potenza nominale è un limite dell’infrastruttura. La batteria può richiedere meno corrente per SOC, temperatura o tensione delle celle; possono intervenire anche cavo, stazione e budget del sito. ChargeProof distingue richiesta, comando ed erogazione per rendere osservabile il vincolo attivo nel modello.
OCPP e ISO 15118 sono la stessa cosa?
No. OCPP collega stazione e sistema di gestione; ISO 15118 riguarda la comunicazione tra veicolo e infrastruttura. La preview esegue un sottoinsieme OCPP 2.0.1 tra processi locali e non include uno stack ISO 15118 o Plug & Charge.
Posso usare ChargeProof senza auto o colonnina?
Sì. La preview Windows funziona sul PC con modelli sintetici e un CSMS locale. La diagnosi guidata permette di osservare guasto, previsione e recupero senza dispositivi collegati. Non comanda un veicolo o un caricatore reale.
Una previsione positiva garantisce il risultato su una batteria reale?
No. La previsione vale per il modello e per le ipotesi dichiarate. Profili sintetici e bilanci numericamente coerenti non costituiscono una calibrazione sperimentale. Per un impiego reale occorrono dati rappresentativi, un campo di validità definito e una campagna di verifica dedicata.
Riferimenti tecnici e approfondimenti
Le fonti seguenti approfondiscono le tecnologie trattate; il perimetro eseguito dal software è documentato separatamente nel repository. Riferimenti verificati il 20 ottobre 2026.
La copertina è un’illustrazione editoriale generata; le tre figure nel testo sono schermate reali della preview.
- DOE / AFDC — Electric Vehicle Charging Stations: infrastrutture e fattori che influenzano il tempo di ricarica.
- Texas Instruments — comunicazione e architettura EV/EVSE: conversione AC/DC e collegamento veicolo-stazione.
- Open Charge Alliance — Open Charge Point Protocol: ruoli e versioni di OCPP.
- CharIN — CCS, Plug & Charge e MCS: interfacce e interoperabilità della ricarica.
- ISO 15118-20:2022 e Amd 1:2026: comunicazione di seconda generazione e servizi aggiuntivi.
- DOE — Extreme Fast Charging Technology Gap Assessment: limiti fisici e termici della ricarica rapida.
- PyBaMM — Thevenin Model: riferimento sulla famiglia di modelli equivalenti, non dipendenza del programma.
- GLFW e Dear ImGui: librerie usate per il desktop nativo.
- Modello ChargeProof, copertura dei protocolli e verifiche della preview: formulazione, ipotesi e risultati documentati del progetto.
