Trois dispositifs peuvent prendre en charge le même protocole et échouer à communiquer
Dans un BESS commercial, le BMS rapporte l'état de la batterie et les limites de fonctionnement, le PCS convertit l'énergie et exécute les commandes de charge/décharge, et l'EMS décide quand cette énergie doit être transférée selon les objectifs du site. La communication utilise généralement des interfaces basées sur CAN, RS485, Modbus RTU/TCP ou Ethernet. Mais partager un nom de protocole ne prouve pas la compatibilité : les dispositifs doivent également s'accorder sur les cartes de données, l'échelle, les adresses, le timing, l'autorité de contrôle, la logique d'alarme et le comportement de sécurité.
L'architecture BESS du DOE illustre cela comme différentes couches de contrôle : le BMS est proche des modules de batterie, le PCS contrôle la conversion d'énergie, tandis que l'EMS opère au niveau de contrôle du site.
Cette hiérarchie est plus facile à comprendre si nous suivons un ordre.
L'EMS dit 100 kW. Le PCS ne peut pas simplement obéir.
Imaginez que la demande de l'usine approche de sa limite maximale.
L'EMS calcule :
Décharge BESS requise = 100 kW
Il envoie une demande de puissance vers le PCS.
Mais avant de délivrer 100 kW, la chaîne de contrôle a un autre avis.
Le BMS peut actuellement rapporter :
SoC : 24%
Décharge maximale autorisée : 62 kW
peut-être à cause du SoC, de la tension des cellules, de la température, du courant ou d'une autre contrainte de la batterie.
Le résultat correct n'est pas :
Commande EMS = 100 kW → Sortie PCS = 100 kW
Le PCS doit fonctionner dans l'enveloppe autorisée de la batterie.
Conceptuellement :
BMS → « Ce que la batterie est autorisée à faire »
EMS → « Ce que le site veut que la batterie fasse »
PCS → « Ce que la conversion d'énergie peut réellement exécuter »
Cette séparation est fondamentale pour un contrôle sûr du BESS.
CAN et Modbus sont des langages, pas des accords
C'est ici que les spécifications d'approvisionnement deviennent souvent trop optimistes.
Le fournisseur A dit :
Communication BMS : CAN.
Le fournisseur B dit :
Le PCS prend en charge le CAN.
L'acheteur écrit :
Compatible.
Pas encore.
Le CAN décrit un mécanisme de communication. Les appareils ont toujours besoin de définitions de messages compatibles.
Le même problème apparaît avec Modbus.
Deux appareils peuvent tous deux prendre en charge Modbus RTU tout en étant en désaccord sur :
les adresses de registre
le type de données
l'ordre des octets
le mise à l'échelle
les autorisations de lecture/écriture
les identifiants de périphérique
les taux de mise à jour
les codes d'alarme
Une valeur de registre de500n'a pas de sens tant que tout le monde ne s'accorde pas sur ce qu'elle signifie :
500 A
50,0 A
ou quelque chose de complètement différent.
C'est pourquoi je demanderais le protocole de communication réel ou la carte des registres avant la mise en service.
DawniceProduitsMontre pourquoi l'interface dépend de la limite du système
Tous les produits de batterie commerciaux n'exposent pas la même interface.
Celui de DawniceBS09-225-D 225,07 kWh système côté DC, par exemple, publiecommunication CAN/RS485,des interfaces et identifie le CAN comme méthode de communication BMS.
Son système intégréBS07-265-ES-X 125 kW/265,3 kWhpublie à la placeModbus TCP/RTUet la préparation EMS/cloud.
Et la spécification du conteneur de 1 MW/2,089 MWh de Dawnice liste la communication EMS viaRS485 et TCP/IP.
Ces différences ont du sens.
Une batterie côté DC a besoin d'une interface vers un PCS externe.
Un système tout-en-un contient déjà davantage de la relation batterie–PCS en interne.
Une centrale conteneurisée nécessite alors une communication de niveau supérieur avec l'EMS, la surveillance, les compteurs et potentiellement le SCADA du site.
L'architecture de communication suit lalimite du système.
Le compteur fait aussi partie de la conversation
La réduction de pointe nous donne un bon exemple.
Le compteur du site rapporte :
Importation du réseau = 680 kW
L'objectif de l'EMS est :
600 kW
L'EMS calcule environ :
80 kW de décharge requise
et envoie le commandement.
Le PCS l'exécute.
Le compteur rapporte ensuite la nouvelle condition du réseau, permettant à l'EMS de s'ajuster à nouveau.
Ainsi, la vraie boucle est plus proche de :
Compteur du site → EMS → PCS ↔ BMS → PCS → Compteur du site
C'est pourquoi un CT inversé ou un étalonnage incorrect du compteur peut faire en sorte qu'une batterie parfaitement saine se comporte de manière incorrecte.
L'EMS prend des décisions rationnelles à partir de mauvaises informations.
L'architecture de communication BESS du DOE inclut également des compteurs, EMS, PCS, BMS, contrôles environnementaux, HMI, systèmes d'incendie et infrastructure réseau plutôt que de traiter la communication de la batterie comme un seul câble CAN.
L'échec de communication nécessite un état sûr défini
Débranchez maintenant le réseau EMS.
Que devrait-il se passer ?
Cette réponse appartient à la spécification de conception.
Selon l'application et l'architecture approuvée, le système pourrait :
continuer le dernier commandement valide pendant une période définie
revenir au contrôle local du PCS
réduire la puissance
arrêter la charge/décharge
élever une alarme
ou entrer dans un autre état sûr prédéfini.
La même question s'applique lorsque :
La communication BMS–PCS échoue
les données du compteur disparaissent
la connexion au cloud est perdue
le SCADA devient indisponible
Ces pannes ne sont pas équivalentes.
Une panne du cloud ne devrait pas nécessairement avoir les mêmes conséquences que la perte des limites BMS requises pour un fonctionnement sûr de la batterie.
La matrice de perte de communication devrait donc définir :
lien perdu → délai d'attente → action de secours → alarme → condition de récupération
avant le SAT.
La matrice de responsabilité compte plus que la liste des protocoles
Je mettrais ce tableau dans l'accord technique :
| Interface | Données / Fonction | Partie responsable |
|---|---|---|
| Batterie ↔ PCS | Limites, SoC, alarmes, commandes | Fournisseur/intégrateur nommé |
| PCS ↔ EMS | Commande/statut de puissance | Fournisseur/intégrateur nommé |
| Compteur ↔ EMS | Mesure de réseau/charge | Partie EPC / EMS |
| EMS ↔ SCADA | Surveillance/contrôle | EMS / intégrateur de site |
| Plateforme distante | Accès aux données/support | Fournisseur défini |
| Infrastructure réseau | IP/VLAN/pare-feu | Responsabilité du site/EPC |
La dernière colonne empêche une conversation de mise en service étonnamment courante :
Fournisseur de batteries :
« Notre CAN fonctionne. »
Fournisseur de PCS :
« Notre CAN fonctionne. »
Intégrateur :
« Alors pourquoi ne communiquent-ils pas ? »
La bibliothèque de support technique de Dawnice contient des procédures de communication dédiées pour des combinaisons telles quePCS Solis 50 kW avec stockage Dawnice 100/143 kWhetPCS Megarevo 500 kW avec stockage C&I Dawnice 860 kWh, ce qui illustre que l'apairage réel des appareils nécessite un travail de configuration et d'intégration au-delà de la simple mention d'un protocole sur une fiche technique.
Ce que je testerais avant de considérer l'interface comme complète
Je ne considère pas la communication comme mise en service parce que chaque appareil affiche une icône verte.
Lors du FAT/SAT, je veux prouver :
Les valeurs de SoC et de température sont correctement mises à l'échelle
Les limites de charge/décharge BMS atteignent le PCS
Les commandes de puissance EMS sont exécutées correctement
La direction et l'échelle du compteur sont correctes
les alarmes se propagent vers le HMI/SCADA prévu
les horodatages sont concordants
le comportement en cas de perte de communication correspond à la spécification
le système se rétablit correctement après le retour de la communication
Pour un projet Ruibit/Dawnice, cette responsabilité doit être gelée avant l'expédition chaque fois que des PCS externes, EMS, compteurs ou systèmes SCADA sont impliqués. Dawnice déclare que son C&IProduitsprend en charge des interfaces standard incluant CAN, RS232 et RS485 et fournit des services d'intégration système et de mise en service pour des projets C&I plus importants.
Une liste de protocoles me dit quelles conversations pourraient être possibles.
Un BESS commandé prouve que les dispositifs comprennent les mêmes données, respectent la même hiérarchie de contrôle, échouent en toute sécurité lorsque la conversation s'arrête et ne laissent aucune ambiguïté sur qui est responsable de faire fonctionner les interfaces.
Questions fréquentes
1. Comment le BMS, le PCS et l'EMS communiquent-ils dans un BESS commercial ?
LeLe BMS fournit l'état de la batterie, l'état de charge (SoC), les alarmes et les limites de fonctionnement, leEMS détermine la puissance de charge ou de décharge requise, et lePCS exécute les commandes de conversion de puissance tout en respectant les limites de la batterie et du système.
2. Quels protocoles de communication sont couramment utilisés dans les BESS commerciaux ?
Les interfaces courantes incluentCAN, RS485, Modbus RTU/TCP et communication basée sur Ethernet. Le soutien du même protocole ne garantit pas automatiquement la compatibilité entre les dispositifs.
3. Pourquoi deux dispositifs BESS peuvent-ils supporter CAN ou Modbus mais échouer à communiquer ?
Ils peuvent utiliser différentesdéfinitions de message, adresses de registre, mise à l'échelle, ordre des octets, identifiants de dispositif, taux de mise à jour, codes d'alarme ou logique de contrôle. La carte de protocole/registre réelle doit donc être vérifiée.
4. Que devrait-il se passer si la communication BMS, PCS ou EMS est perdue ?
Le système doit entrer dans un état prédéfini basé sur l'interface défaillante. La spécification doit définir ledélai d'attente, l'action de secours, le comportement d'alarme et les conditions de récupérationpour chaque échec de communication.
5. Qui est responsable de l'intégration BMS–PCS–EMS ?
La responsabilité doit être explicitement assignée dans les documents du projet. Les acheteurs doivent définir qui possède chaque interface entre lebatterie, PCS, EMS, compteur, SCADA, plateforme distante et réseau de siteavant le FAT et la mise en service.
