La batterie était en bonne santé. Le message ne passait pas.
Un échec de communication BMS dans un BESS commercial n'est généralement pas une preuve suffisante pour remplacer le BMS. Commencez par identifier exactement quel chemin de communication a échoué, puis vérifiez l'alimentation et l'état de fonctionnement, le câblage physique, le type d'interface, la terminaison, les paramètres de nœud/adresse, la sélection du protocole, la compatibilité du firmware et le trafic de messages réel. Une alarme de communication et un défaut de batterie sont deux problèmes de diagnostic différents.
J'ai vu des techniciens perdre des heures parce que l'HMI montraitDéfaillance de communication BMSet tout le monde a immédiatement commencé à discuter du rack de batteries.
Ma première question est plus simple :
Qui a arrêté de parler à qui ?
Dans un BESS C&I, "communication BMS" peut décrire BMS de rack à BMS maître, BMS à PCS, BMS à EMS, ou le chemin du système de stockage d'énergie vers la surveillance SCADA/cloud. Les C&I actuels de DawniceProduitsillustrent la variété : son BS09-225-D publiecommunication CAN/RS485,tandis que le BS07-265-ES-X listeModbus TCP/RTUet la préparation EMS/cloud.Dawnice BS09-225-D Dawnice BS07-265-ES-X
Même symptôme général.
Défaillance potentiellement très différente.
08:17 — Le PCS a dit "Pas de BMS"
Considérez une batterie commerciale hypothétique de 400 kWh connectée à un PCS.
Le système a été mis en service correctement vendredi.
Lundi matin :
HMI de la batterie :normal
Tensions de rack :présentes
Températures des cellules :plausibles
PCS :communication BMS perdue
EMS :batterie indisponible
Contacteur :ouvert
La tentation est de dire :
"Le BMS a échoué."
Je ne le ferais pas.
Si l'HMI de la batterie locale lit encore correctement les cellules et les températures, le BMS fait clairement au moins une partie de son travail. La défaillance peut se situer entre le BMS et le PCS.
Cela change immédiatement l'enquête.
Je noterais l'horodatage de l'alarme avant de toucher quoi que ce soit, puis je le comparerais avec les journaux d'événements du BMS, du PCS et de l'EMS.
Si les trois horloges ne sont pas d'accord sur six minutes, je résous également ce problème. L'analyse des causes profondes devient étonnamment désordonnée lorsque la chronologie des événements est peu fiable.
Je vérifie les choses ennuyeuses avant d'ouvrir un ordinateur portable
Un câble de communication de remplacement a résolu plus de pannes qu'une analyse de protocole élégante ne le fera jamais.
Avant de changer de logiciel, je veux savoir :
Le BMS est-il alimenté et complètement éveillé ?
Le port de communication correct est-il utilisé ?
Le connecteur est-il complètement en place ?
La configuration des broches du câble a-t-elle été vérifiée, et non supposée à partir du connecteur RJ45 ?
Les connexions CAN-H/CAN-L ou RS485 A/B sont-elles correctement connectées ?
Le blindage/la mise à la terre est-il conforme au design approuvé ?
Le câble a-t-il été endommagé, écrasé, prolongé ou détourné à côté de conducteurs d'alimentation bruyants ?
Le RJ45 est particulièrement dangereux psychologiquement. Deux appareils peuvent utiliser des connecteurs identiques et des affectations de broches complètement différentes.
Le manuel de la batterie de Dawnice, par exemple, définit séparément les broches de communication CAN et RS485 plutôt que d'impliquer qu'un câble réseau ordinaire est interchangeable.Manuel de la batterie Dawnice
Une forme de connecteur n'est pas un protocole.
Ce n'est même pas une définition de câblage.
Si plusieurs racks disparaissent en même temps, j'arrête de blâmer des racks individuels
Le schéma de défaillance me dit où chercher.
| Symptôme | Première zone que je voudrais examiner |
|---|---|
| Un rack disparaît | Alimentation du rack, câble, adresse, BMS local |
| Tous les racks disparaissent | BMS maître, bus commun, alimentation |
| L'interface HMI BMS fonctionne mais le PCS perd la batterie | Lien / protocole BMS–PCS |
| Le PCS voit la batterie mais l'EMS ne la voit pas | Réseau PCS/EMS ou mappage des registres |
| La communication échoue par intermittence | Terminaison, bruit, connecteur, topologie |
| La défaillance suit une mise à jour du firmware | Protocole/firmware/configuration |
| Valeurs incorrectes mais le lien reste en ligne | Carte des registres, mise à l'échelle, ordre des octets, mappage |
Ce tableau ne remplace pas le manuel du système.
C'est une façon d'éviter de remplacer quatre modules de batterie sains parce qu'un lien de communication partagé a échoué.
CAN et RS485 échouent différemment
Je ne considère pas "câble de communication" comme une seule catégorie.
Sur un réseau CAN, je veux vérifier la topologie, la polarité CAN-H/CAN-L, le débit binaire, la configuration des nœuds, la terminaison et si les trames attendues sont réellement présentes.
Sur un réseau RS485/Modbus RTU, je commence à penser à la polarité A/B, aux adresses esclaves, au débit en bauds, à la parité, aux bits d'arrêt, à la cartographie des registres et à la terminaison.
LeOrganisation Modbusmaintient les spécifications actuelles du protocole et de l'implémentation sur ligne série. Ses recommandations sur la ligne série traitent la terminaison et la polarisation comme des propriétés de la conception du réseau, et non comme des résistances arbitraires à ajouter chaque fois que la communication devient peu fiable.
C'est là que je deviens prudent par rapport à ce qui est familier :
"Mesurez 60 ohms et c'est bon."
Deux terminaisons de 120 ohms en parallèle peuvent produire environ 60 ohms sur un bus non alimenté, mais cette mesure n'a de sens que pour une topologie conçue de cette manière et mesurée dans des conditions appropriées.
Cela ne prouve pas que les adresses, le débit en bauds, le protocole ou la cartographie des données sont corrects.
Un chiffre utile. Pas un diagnostic.
Une LED de communication verte peut toujours vous mentir
Supposons que le lien physique semble sain.
Les trames circulent.
Le PCS refuse toujours de fonctionner.
Maintenant, je monte dans la pile.
Un BMS et un PCS doivent s'accorder sur plus que le signal électrique. En fonction de l'architecture, ils peuvent avoir besoin de définitions compatibles pour :
SoC
SoH
tension/courant de pack
courant de charge maximum
courant de décharge maximum
activation de charge/décharge
états d'alarme
état du contacteur
limites de température
battement de cœur/chien de garde
Un bus CAN peut être électriquement parfait tandis que le PCS écoute un ensemble de messages différent.
De même, un maître Modbus peut communiquer avec succès avec un esclave tout en lisant les mauvais registres.
C'est pourquoi "supporte CAN" ou "supporte Modbus" n'est pas une déclaration de compatibilité.
Cela me dit la famille de langages.
Pas si les deux appareils comprennent la même conversation.
La sélection de protocole est un vrai défaut, pas un détail de configuration
C'est une des raisons pour lesquelles j'aime vérifier la configuration avant de remplacer le matériel.
Un manuel d'onduleur Dawnice, par exemple, identifieErreur de communication BMS [58]et dirige le technicien à vérifier à la fois le câble de communication et si le protocole de communication de la batterie lithium configuré correspond à la batterie.Manuel de l'onduleur Dawnice
Cette logique de dépannage s'applique au-delà d'un produit.
Supposons qu'un ingénieur de mise en service sélectionne :
Protocole de batterie 03
au lieu de :
Protocole de batterie 08
Le câble est parfait.
Le BMS est en bonne santé.
Le PCS est en bonne santé.
Le système ne fonctionne toujours pas.
Rien n'est "cassé."
La configuration est incorrecte.
Pour les projets commerciaux Ruibit/Dawnice, je gèlerais donc la combinaison de communication BMS–PCS approuvée avec le BOM électrique : version exacte de la batterie/BMS, modèle de PCS, protocole, interface, ensemble de paramètres et versions de firmware.
Changer le firmware peut être un changement de composant même lorsque aucun tournevis ne touche le cabinet.
La communication intermittente est le défaut que je prends plus au sérieux
Un lien complètement mort est souvent plus facile.
Un lien intermittent peut passer le FAT, survivre à la mise en service puis échouer lorsque le site est chaud, fortement chargé ou électriquement bruyant.
Imaginez que les chutes de communication n'apparaissent que lorsque le PCS dépasse 80 % de puissance.
Ce timing est important.
J'examinerais le routage et les interférences électromagnétiques avant de blâmer un logiciel aléatoire.
Si le problème apparaît toutes les 20 secondes, peu importe la puissance, je pourrais examiner le timing du heartbeat/watchdog.
S'il apparaît après l'ajout du cinquième rack, je passerais en revue la topologie, l'adressage et la terminaison.
S'il commence immédiatement après la révision du firmware 3.12, je veux le numéro de version précédent avant que quiconque effectue une autre mise à jour.
La condition qui fait apparaître la faute est une preuve.
Ne l'effacez pas en redémarrant tout d'abord.
Mon ordre de diagnostic est conçu pour éviter des suppositions coûteuses
Je travaille normalement de l'extérieur vers l'intérieur :
1. Définir la limite de communication échouée
BMS–rack ? BMS–PCS ? PCS–EMS ? EMS–SCADA ?
2. Préserver les preuves
Codes d'alarme, horodatages, captures d'écran, versions du firmware et changements récents.
3. Vérifier l'état de fonctionnement
Alimentations, état du BMS, contacteurs, alarmes locales.
4. Vérifier la couche physique
Câble, brochage, polarité, connecteurs, topologie, terminaison, blindage.
5. Vérifier les paramètres de communication
Interface, ID de nœud, débit en bauds, débit binaire, parité et sélection du protocole.
6. Vérifier la couche de données
Trames, carte des registres, mise à l'échelle, échange de signaux de vie et de commandes/statuts.
7. Examiner l'historique des changements
Firmware, composants de remplacement, changements de paramètres et modifications du réseau.
Je ne passe pas directement à l'étape 6 car l'analyse du protocole ne peut pas réparer un connecteur lâche.
Je ne m'arrête pas à l'étape 4 car la continuité ne prouve pas la compatibilité.
Le défaut est corrigé lorsque le comportement du système est corrigé
Faire disparaître l'alarme de communication n'est pas mon critère d'acceptation.
Après réparation, je veux confirmer que le PCS reçoit des données de batterie plausibles et respecte les limites du BMS.
Si le BMS réduit le courant de charge autorisé en raison de l'augmentation de la température de la batterie, le PCS suit-il cela ?
Si l'autorisation de décharge est retirée, l'alimentation s'arrête-t-elle réellement ?
Le SoC atteint-il correctement l'EMS ?
Les alarmes apparaissent-elles à distance ?
La communication se rétablit-elle correctement après un redémarrage contrôlé ?
Les horodatages sont-ils alignés ?
Dawnice déclare actuellement que ses systèmes C&I prennent en charge la surveillance et le diagnostic à distance via des interfaces incluant CAN, RS485 et des plateformes de surveillance connexes, et elle publie des tutoriels spécifiques sur les connexions de communication pour les combinaisons de batteries/PCS C&I.FAQ de Dawnice Support technique de Dawnice
Pour un acheteur B2B, ce dernier point compte plus qu'il n'y paraît.
N'achetez pas seulement une batterie et un PCS.
Achetez unrapport de communication vérifiéentre eux, avec versions, paramètres et responsabilité de support enregistrés.
Car lorsque un BESS dit "échec de communication BMS", l'erreur coûteuse est de supposer que le premier composant nommé dans l'alarme est celui qui a échoué.
Trouvez d'abord la conversation rompue. Remplacez le matériel ensuite.
Questions fréquentes
1. Pourquoi mon BMS ne communique-t-il pas avec le PCS ?
Les causes courantes incluentun câblage ou un brochage incorrect, la polarité CAN/RS485, une sélection de protocole incorrecte, des paramètres d'adresse, une terminaison, une incompatibilité de firmware, des câbles endommagés ou une configuration du port de communication.
2. Une alarme de communication BMS signifie-t-elle que le BMS a échoué ?
Non. Le BMS peut toujours surveiller correctement les cellules pendant que la communication échoue entre le BMS et le PCS, l'EMS, le BMS maître ou le SCADA. Identifiez la limite de communication échouée avant de remplacer le matériel.
3. Deux appareils peuvent-ils supporter CAN ou RS485 et être néanmoins incompatibles ?
Oui. Partager la même interface physique ne garantit pas la compatibilité. Les appareils doivent également s'accorder surle protocole, le débit binaire ou la vitesse en bauds, les définitions de message/enregistrement, l'adressage, l'échelle des données et la logique de contrôle.
4. Pourquoi la communication BMS échoue-t-elle de manière intermittente ?
Des défauts intermittents peuvent résulter de connecteurs desserrés, d'une mauvaise terminaison, de bruit électrique, de routage de câbles, d'alimentations instables, de topologie réseau, de temporisation de watchdog ou de problèmes de firmware. Enregistrez quand le défaut se produit avant de redémarrer le système.
5. Que doit-on vérifier après avoir corrigé un défaut de communication BMS ?
Confirmez que le PCS reçoit correctementl'état de charge, la tension, le courant, la température, les alarmes et les limites de charge/décharge, suit les commandes de protection du BMS, rapporte correctement à l'EMS et récupère la communication après un redémarrage contrôlé.
