Tre Dispositivi Possono Supportare lo Stesso Protocollo e Ancora Fallire nella Comunicazione
In un BESS commerciale, il BMS riporta lo stato della batteria e i limiti operativi, il PCS converte l'energia ed esegue comandi di carica/scarica, e l'EMS decide quando quell'energia deve muoversi in base agli obiettivi del sito. La comunicazione utilizza comunemente interfacce basate su CAN, RS485, Modbus RTU/TCP o Ethernet. Ma condividere un nome di protocollo non prova la compatibilità: i dispositivi devono anche concordare su mappe dati, scalatura, indirizzi, tempistiche, autorità di controllo, logica di allarme e comportamento di sicurezza.
L'architettura BESS del DOE illustra questi come diversi strati di controllo: il BMS si trova vicino ai moduli della batteria, il PCS controlla la conversione dell'energia, mentre l'EMS opera a livello di controllo del sito.
Quella gerarchia è più facile da comprendere se seguiamo un comando.
L'EMS Dice 100 kW. Il PCS Non Può Semplicemente Obbedire.
Immagina che la domanda della fabbrica si avvicini al suo limite massimo.
L'EMS calcola:
Scarica BESS richiesta = 100 kW
Invia una richiesta di energia verso il PCS.
Ma prima di erogare 100 kW, la catena di controllo ha un'altra opinione.
Il BMS potrebbe attualmente riportare:
SoC: 24%
Scarica massima consentita: 62 kW
forse a causa di SoC, tensione della cella, temperatura, corrente o un altro vincolo della batteria.
Il risultato corretto non è:
Comando EMS = 100 kW → Uscita PCS = 100 kW
Il PCS deve operare all'interno dell'involucro consentito dalla batteria.
Concettualmente:
BMS → “Cosa è consentito fare alla batteria”
EMS → “Cosa vuole il sito che la batteria faccia”
PCS → “Cosa può effettivamente essere eseguito nella conversione dell'energia”
Quella separazione è fondamentale per un controllo sicuro del BESS.
CAN e Modbus Sono Lingue, Non Accordi
È qui che le specifiche di approvvigionamento spesso diventano troppo ottimistiche.
Il fornitore A dice:
Comunicazione BMS: CAN.
Il fornitore B dice:
Il PCS supporta CAN.
L'acquirente scrive:
Compatibile.
Non ancora.
CAN descrive un meccanismo di comunicazione. I dispositivi necessitano ancora di definizioni di messaggi compatibili.
Lo stesso problema si presenta con Modbus.
Due dispositivi possono entrambi supportare Modbus RTU pur non concordando su:
indirizzi dei registri
tipo di dato
ordine dei byte
scalatura
permessi di lettura/scrittura
ID dei dispositivi
frequenze di aggiornamento
codici di allarme
Un valore di registro di500è privo di significato finché tutti non concordano se significa:
500 A
50,0 A
o qualcosa di completamente diverso.
Ecco perché richiederei il protocollo di comunicazione effettivo o la mappa dei registri prima della messa in servizio.
DawniceProdottiMostra perché l'interfaccia dipende dal confine del sistema
Non tutti i prodotti commerciali per batterie espongono la stessa interfaccia.
Quello di DawniceBS09-225-D sistema lato DC da 225,07 kWh, per esempio, pubblicainterfacce CAN/RS485e identifica CAN come metodo di comunicazione BMS.
Il suo sistema integratoBS07-265-ES-X 125 kW/265,3 kWhinvece pubblicaModbus TCP/RTUe la predisposizione per EMS/cloud.
La specifica del contenitore da 1 MW/2.089 MWh di Dawnice elenca la comunicazione EMS tramiteRS485 e TCP/IP.
Queste differenze hanno senso.
Una batteria sul lato DC ha bisogno di un'interfaccia con un PCS esterno.
Un sistema tutto-in-uno contiene già di più della relazione batteria–PCS internamente.
Una pianta containerizzata ha quindi bisogno di una comunicazione di livello superiore con EMS, monitoraggio, contatori e potenzialmente SCADA del sito.
L'architettura di comunicazione segue ilconfine di sistema.
Il misuratore fa parte della conversazione anche
Il peak shaving ci offre un buon esempio.
Il contatore del sito riporta:
Importazione dalla rete = 680 kW
L'obiettivo dell'EMS è:
600 kW
L'EMS calcola approssimativamente:
80 kW di scarica richiesti
e invia il comando.
Il PCS lo esegue.
Il contatore poi riporta la nuova condizione della rete, permettendo all'EMS di adattarsi nuovamente.
Quindi il vero ciclo è più vicino a:
Contatore del sito → EMS → PCS ↔ BMS → PCS → Contatore del sito
Questo è il motivo per cui un CT invertito o una scalatura errata del contatore possono far comportare una batteria perfettamente sana in modo errato.
L'EMS sta prendendo decisioni razionali da informazioni errate.
L'architettura di comunicazione BESS del DOE include similmente contatori, EMS, PCS, BMS, controlli ambientali, HMI, sistemi antincendio e infrastruttura di rete piuttosto che trattare la comunicazione della batteria come un unico cavo CAN.
Il fallimento della comunicazione necessita di uno stato sicuro definito
Ora scollega la rete EMS.
Cosa dovrebbe succedere?
Quella risposta appartiene alla specifica di design.
A seconda dell'applicazione e dell'architettura approvata, il sistema potrebbe:
continuare l'ultimo comando valido per un periodo definito
tornare al controllo locale del PCS
ridurre la potenza
ferma carica/scarica
solleva un allarme
o entra in un altro stato sicuro predefinito.
La stessa domanda si pone quando:
la comunicazione BMS–PCS fallisce
i dati del misuratore scompaiono
la connessione al cloud viene persa
SCADA diventa non disponibile
Questi fallimenti non sono equivalenti.
Un'interruzione del cloud non dovrebbe necessariamente avere la stessa conseguenza della perdita dei limiti BMS richiesti per un funzionamento sicuro della batteria.
La matrice di perdita di comunicazione dovrebbe quindi definire:
link perso → timeout → azione di fallback → allarme → condizione di recupero
prima di SAT.
La matrice di responsabilità è più importante della lista dei protocolli
Metterei questa tabella nell'accordo tecnico:
| Interfaccia | Dati / Funzione | Parte Responsabile |
|---|---|---|
| Batteria ↔ PCS | Limiti, SoC, allarmi, comandi | Fornitore/integratore nominato |
| PCS ↔ EMS | Comando/stato di potenza | Fornitore/integratore nominato |
| Misuratore ↔ EMS | Misurazione rete/carico | Parte EPC / EMS |
| EMS ↔ SCADA | Monitoraggio/controllo | EMS / integratore di sito |
| Piattaforma remota | Accesso ai dati/supporto | Fornitore definito |
| Infrastruttura di rete | IP/VLAN/firewall | Responsabilità sito/EPC |
L'ultima colonna previene una conversazione di commissioning sorprendentemente comune:
Fornitore di batterie:
“Il nostro CAN funziona.”
Fornitore di PCS:
“Il nostro CAN funziona.”
Integratore:
“Allora perché non comunicano?”
La biblioteca di supporto tecnico di Dawnice contiene procedure di comunicazione dedicate per combinazioni comeSolis 50 kW PCS con stoccaggio Dawnice 100/143 kWheMegarevo 500 kW PCS con stoccaggio C&I Dawnice 860 kWh, il che illustra che il pairing effettivo dei dispositivi richiede lavoro di configurazione e integrazione oltre alla semplice elencazione di un protocollo su un datasheet.
Cosa testerei prima di considerare l'interfaccia completa
Non considero la comunicazione commissionata perché ogni dispositivo mostra un'icona verde.
Durante FAT/SAT, voglio dimostrare:
I valori di SoC e temperatura sono correttamente scalati
I limiti di carica/scarica BMS raggiungono il PCS
I comandi di potenza EMS vengono eseguiti correttamente
la direzione e la scala del misuratore sono corrette
gli allarmi si propagano all'HMI/SCADA previsto
i timestamp concordano
il comportamento in caso di perdita di comunicazione corrisponde alle specifiche
il sistema si riprende correttamente dopo il ripristino della comunicazione
Per un progetto Ruibit/Dawnice, tale responsabilità dovrebbe essere congelata prima della spedizione ogni volta che sono coinvolti PCS, EMS, misuratori o sistemi SCADA esterni. Dawnice afferma che il suo C&IProdottisupporta interfacce standard tra cui CAN, RS232 e RS485 e fornisce servizi di integrazione di sistema e messa in servizio per progetti C&I più grandi.
Un elenco di protocolli mi dice quali conversazioni potrebbero essere possibili.
Un BESS messo in servizio dimostra che i dispositivi comprendono gli stessi dati, rispettano la stessa gerarchia di controllo, falliscono in modo sicuro quando la conversazione si interrompe e non lasciano ambiguità su chi è responsabile del funzionamento delle interfacce.
Domande Frequenti
1. Come comunicano BMS, PCS ed EMS in un BESS commerciale?
IlIl BMS fornisce lo stato della batteria, SoC, allarmi e limiti operativi, ilEMS determina la potenza di carica o scarica richiesta, e ilPCS esegue i comandi di conversione di potenza rispettando i limiti della batteria e del sistema.
2. Quali protocolli di comunicazione sono comunemente usati nei BESS commerciali?
Le interfacce comuni includonoCAN, RS485, Modbus RTU/TCP e comunicazione basata su Ethernet. Supportare lo stesso protocollo non garantisce automaticamente la compatibilità tra i dispositivi.
3. Perché due dispositivi BESS possono supportare CAN o Modbus ma fallire comunque nella comunicazione?
Potrebbero utilizzare diversedefinizioni di messaggio, indirizzi di registro, scalatura, ordine dei byte, ID dei dispositivi, tassi di aggiornamento, codici di allarme o logica di controllo. La mappa del protocollo/registro effettiva deve quindi essere verificata.
4. Cosa dovrebbe accadere se la comunicazione BMS, PCS o EMS viene persa?
Il sistema dovrebbe entrare in uno stato predefinito basato sull'interfaccia fallita. La specifica dovrebbe definire iltimeout, l'azione di fallback, il comportamento dell'allarme e le condizioni di recuperoper ogni guasto di comunicazione.
5. Chi è responsabile dell'integrazione BMS–PCS–EMS?
La responsabilità dovrebbe essere esplicitamente assegnata nei documenti di progetto. Gli acquirenti dovrebbero definire chi possiede ciascuna interfaccia tra ilbatteria, PCS, EMS, misuratore, SCADA, piattaforma remota e rete del sitoprima del FAT e della messa in servizio.
