Warum kommuniziert mein BMS nicht? Fehlersuche bei Kommunikationsfehlern in kommerziellen BESS

Die Batterie war gesund. Die Nachricht kam nicht durch.

Ein BMS-Kommunikationsfehler in einem kommerziellen BESS ist normalerweise nicht genügend Beweis, um das BMS zu ersetzen. Beginnen Sie damit, genau zu identifizieren, welcher Kommunikationsweg ausgefallen ist, und überprüfen Sie dann die Stromversorgung und den Betriebszustand, die physikalische Verkabelung, den Schnittstellentyp, die Terminierung, die Knoten-/Adresskonfiguration, die Protokollauswahl, die Firmware-Kompatibilität und den tatsächlichen Nachrichtenverkehr. Ein Kommunikationsalarm und ein Batteriefehler sind zwei verschiedene diagnostische Probleme.

Ich habe gesehen, wie Techniker Stunden verloren haben, weil das HMI zeigteBMS-Kommunikationsfehlerund alle sofort anfingen, über das Batteriefach zu diskutieren.

Meine erste Frage ist einfacher:

Wer hat aufgehört, mit wem zu sprechen?

In einem C&I BESS kann "BMS-Kommunikation" die Kommunikation vom Rack-BMS zum Master-BMS, vom BMS zum PCS, vom BMS zum EMS oder den Weg vom Energiespeichersystem zu SCADA/Cloud-Überwachung beschreiben. Dawnices aktuelles C&IProdukteveranschaulicht die Vielfalt: sein BS09-225-D veröffentlichtCAN/RS485Kommunikation, während das BS07-265-ES-X auflistetModbus TCP/RTUund EMS/Cloud-Bereitschaft.Dawnice BS09-225-D Dawnice BS07-265-ES-X

Das gleiche breite Symptom.

Potenziell sehr unterschiedlicher Fehler.

08:17 — Der PCS sagte "Kein BMS"

Betrachten Sie eine hypothetische kommerzielle Batterie mit 400 kWh, die an ein PCS angeschlossen ist.

Das System wurde am Freitag korrekt in Betrieb genommen.

Montagmorgen:

Batterie HMI:normal
Rackspannungen:vorhanden
Zelltemperaturen:plausibel
PCS:BMS-Kommunikation verloren
EMS:Batterie nicht verfügbar
Kontaktor:offen

Die Versuchung ist zu sagen:

"Das BMS ist ausgefallen."

Das würde ich nicht.

Wenn das lokale Batteriemanagement-Interface (HMI) weiterhin Zellen und Temperaturen korrekt liest, dann erfüllt das BMS offensichtlich zumindest einen Teil seiner Aufgabe. Der Fehler könnte zwischen dem BMS und dem PCS liegen.

Das ändert die Untersuchung sofort.

Ich würde den Alarmzeitstempel aufzeichnen, bevor ich irgendetwas berühre, und ihn dann mit den Ereignisprotokollen von BMS, PCS und EMS vergleichen.

Wenn alle drei Uhren um sechs Minuten voneinander abweichen, behebe ich auch dieses Problem. Die Ursachenanalyse wird überraschend kompliziert, wenn die Chronologie der Ereignisse unzuverlässig ist.

Ich überprüfe die langweiligen Dinge, bevor ich einen Laptop öffne

Ein Ersatzkommunikationskabel hat mehr Fehler behoben als eine elegante Protokollanalyse jemals tun wird.

Bevor ich die Software ändere, möchte ich wissen:

Ist das BMS mit Strom versorgt und vollständig wach?

Wird der richtige Kommunikationsport verwendet?

Ist der Stecker vollständig eingesteckt?

Wurde die Pinbelegung des Kabels überprüft und nicht vom RJ45-Stecker angenommen?

Sind CAN-H/CAN-L oder RS485 A/B korrekt verbunden?

Ist die Abschirmung/Erde konsistent mit dem genehmigten Design?

Wurde das Kabel beschädigt, zerdrückt, verlängert oder neben lauten Stromleitern umgeleitet?

RJ45 ist psychologisch besonders gefährlich. Zwei Geräte können identische Stecker verwenden und völlig unterschiedliche Pinbelegungen haben.

Das eigene Batteriemanual von Dawnice definiert beispielsweise die Kommunikationspins für CAN und RS485 separat, anstatt zu implizieren, dass jedes gewöhnliche Netzwerkkabel austauschbar ist.Dawnice Batteriemanual

Eine Steckerform ist kein Protokoll.

Es ist nicht einmal eine Verdrahtungsdefinition.

Wenn mehrere Racks gleichzeitig verschwinden, höre ich auf, einzelne Racks zu beschuldigen

Das Ausfallmuster sagt mir, wo ich suchen soll.

Diese Tabelle ist kein Ersatz für das Systemhandbuch.

Es ist eine Möglichkeit, den Austausch von vier gesunden Batteriemodulen zu vermeiden, weil eine gemeinsame Kommunikationsverbindung ausgefallen ist.

CAN und RS485 fallen unterschiedlich aus

Ich behandle "Kommunikationskabel" nicht als eine Kategorie.

In einem CAN-Netzwerk möchte ich die Topologie, die Polarität von CAN-H/CAN-L, die Bitrate, die Knotenkonfiguration, die Terminierung und ob die erwarteten Frames tatsächlich vorhanden sind, überprüfen.

In einem RS485/Modbus RTU-Netzwerk beginne ich, über A/B-Polarität, Slave-Adressen, Baudrate, Parität, Stoppbits, Registerzuordnung und Terminierung nachzudenken.

DerModbus-Organisationpflegt die aktuellen Protokoll- und seriellen Implementierungsspezifikationen. Ihre Anleitung zur seriellen Linie behandelt Terminierung und Polarisation als Eigenschaften des Netzwerkdesigns, nicht als willkürliche Widerstände, die hinzugefügt werden, wann immer die Kommunikation unzuverlässig wird.

Hier werde ich vorsichtig bei dem Vertrauten:

"Miss 60 Ohm und du bist fertig."

Zwei 120-Ohm-Abschlüsse in Parallel können ungefähr 60 Ohm an einem unpowered Bus erzeugen, aber diese Messung ist nur sinnvoll für eine Topologie, die so gestaltet und unter geeigneten Bedingungen gemessen wurde.

Es beweist nicht, dass Adressen, Baudrate, Protokoll oder Datenzuordnung korrekt sind.

Eine nützliche Zahl. Keine Diagnose.

Eine grüne Kommunikations-LED kann trotzdem lügen

Angenommen, die physische Verbindung sieht gesund aus.

Frames bewegen sich.

Der PCS weigert sich weiterhin zu arbeiten.

Jetzt gehe ich nach oben durch den Stack.

Ein BMS und ein PCS müssen sich über mehr als nur elektrische Signalisierung einig sein. Je nach Architektur benötigen sie möglicherweise kompatible Definitionen für:

SoC

SoH

Packspannung/Strom

maximaler Ladestrom

maximaler Entladestrom

Lade-/Entladefreigabe

Alarmzustände

Schützstatus

Temperaturgrenzen

Heartbeat/Watchdog

Ein CAN-Bus kann elektrisch perfekt sein, während der PCS auf einen anderen Nachrichtenstamm hört.

Ebenso kann ein Modbus-Master erfolgreich mit einem Slave kommunizieren, während er die falschen Register liest.

Deshalb ist "unterstützt CAN" oder "unterstützt Modbus" keine Kompatibilitätsaussage.

Es sagt mir die Sprachfamilie.

Nicht, ob die beiden Geräte dasselbe Gespräch verstehen.

Die Protokollauswahl ist ein echter Fehler, kein Einrichtung Detail

Das ist ein Grund, warum ich es mag, die Konfiguration zu überprüfen, bevor ich Hardware austausche.

Ein Dawnice-Wechselrichterhandbuch identifiziert beispielsweiseBMS-Kommunikationsfehler [58]und weist den Techniker an, sowohl das Kommunikationskabel als auch zu überprüfen, ob das konfigurierte Lithium-Batterie-Kommunikationsprotokoll mit der Batterie übereinstimmt.Dawnice Wechselrichterhandbuch

Diese Fehlersuche-Logik skaliert über ein Produkt hinaus.

Angenommen, ein Inbetriebnahmeingenieur wählt:

Batterieprotokoll 03

anstatt:

Batterieprotokoll 08

Das Kabel ist perfekt.

Das BMS ist gesund.

Das PCS ist gesund.

Das System funktioniert immer noch nicht.

Nichts ist "kaputt."

Die Konfiguration ist falsch.

Für Ruibit/Dawnice gewerbliche Projekte würde ich daher die genehmigte BMS–PCS-Kommunikationskombination zusammen mit der elektrischen Stückliste einfrieren: genaue Batterie/BMS-Version, PCS-Modell, Protokoll, Schnittstelle, Parametersatz und Firmware-Versionen.

Eine Änderung der Firmware kann einen Komponentenwechsel darstellen, auch wenn kein Schraubendreher das Gehäuse berührt.

Intermittierende Kommunikation ist der Fehler, den ich ernster nehme

Eine völlig tote Verbindung ist oft einfacher.

Eine intermittierende Verbindung kann FAT bestehen, die Inbetriebnahme überstehen und dann fehlschlagen, wenn der Standort heiß, stark belastet oder elektrisch störend ist.

Stellen Sie sich vor, dass Kommunikationsabbrüche nur auftreten, wenn das PCS 80 % Leistung überschreitet.

Das Timing ist entscheidend.

Ich würde Routing und elektromagnetische Störungen untersuchen, bevor ich zufällige Software beschuldige.

Wenn das Problem alle 20 Sekunden unabhängig von der Leistung auftritt, könnte ich die Herzschlag-/Watchdog-Timings überprüfen.

Wenn es nach dem Hinzufügen des fünften Racks auftritt, würde ich die Topologie, Adressierung und Terminierung überprüfen.

Wenn es sofort nach der Firmware-Revision 3.12 beginnt, möchte ich die vorherige Versionsnummer, bevor jemand ein weiteres Update durchführt.

Die Bedingung, die den Fehler auftreten lässt, ist ein Beweis.

Löschen Sie es nicht, indem Sie zuerst alles neu starten.

Meine Diagnosereihenfolge ist darauf ausgelegt, teures Raten zu verhindern

Ich arbeite normalerweise von außen nach innen:

1. Definieren Sie die Grenze der fehlgeschlagenen Kommunikation

BMS–Rack? BMS–PCS? PCS–EMS? EMS–SCADA?

2. Bewahren Sie Beweise auf

Alarmcodes, Zeitstempel, Screenshots, Firmware-Versionen und kürzliche Änderungen.

3. Überprüfen Sie den Betriebszustand

Stromversorgungen, BMS-Zustand, Schütze, lokale Alarme.

4. Überprüfen Sie die physikalische Schicht

Kabel, Pinbelegung, Polarität, Anschlüsse, Topologie, Abschluss, Abschirmung.

5. Überprüfen Sie die Kommunikationseinstellungen

Schnittstelle, Knoten-ID, Baudrate, Bitrate, Parität und Protokollauswahl.

6. Überprüfen Sie die Datenschicht

Rahmen, Registerkarte, Skalierung, Herzschlag und Befehl-/Statusaustausch.

7. Überprüfen Sie die Änderungsverlauf

Firmware, Ersatzkomponenten, Parameteränderungen und Netzwerkmodifikationen.

Ich springe nicht direkt zu Schritt 6, da die Protokollanalyse einen lockeren Anschluss nicht reparieren kann.

Ich halte nicht bei Schritt 4 an, da Kontinuität nicht die Kompatibilität beweist.

Der Fehler ist behoben, wenn das Systemverhalten behoben ist

Das Verschwinden des Kommunikationsalarms ist nicht mein Akzeptanzkriterium.

Nach der Reparatur möchte ich bestätigen, dass das PCS plausible Batteriedaten erhält und die BMS-Grenzen respektiert.

Wenn das BMS den zulässigen Ladestrom reduziert, weil die Batterietemperatur steigt, folgt das PCS dem?

Wenn die Entladeerlaubnis entzogen wird, stoppt die Leistung tatsächlich?

Erreicht der SoC korrekt das EMS?

Erscheinen Alarme aus der Ferne?

Erholt sich die Kommunikation nach einem kontrollierten Neustart korrekt?

Sind die Zeitstempel synchronisiert?

Dawnice gibt derzeit an, dass seine C&I-Systeme die Fernüberwachung und -diagnose über Schnittstellen wie CAN, RS485 und verwandte Überwachungsplattformen unterstützen und spezifische Kommunikationstutorials für C&I-Batterie/PCS-Kombinationen veröffentlicht.Dawnice FAQ Dawnice Technischer Support

Für einen B2B-Käufer ist dieser letzte Punkt wichtiger, als es klingt.

Kaufen Sie nicht nur eine Batterie und ein PCS.

Kaufen Sie eineverifizierte Kommunikationsbeziehungzwischen ihnen, mit Versionen, Einstellungen und Verantwortlichkeiten für den Support dokumentiert.

Denn wenn ein BESS "BMS-Kommunikationsfehler" sagt, ist der teure Fehler anzunehmen, dass das erste im Alarm genannte Bauteil das fehlerhafte Bauteil ist.

Finden Sie zuerst das unterbrochene Gespräch. Ersetzen Sie die Hardware zweitens.

Häufig gestellte Fragen

1. Warum kommuniziert mein BMS nicht mit dem PCS?

Häufige Ursachen sindfalsche Verkabelung oder Pinbelegung, CAN/RS485-Polarität, falsche Protokollauswahl, Adresseneinstellungen, Abschluss, Firmware-Inkompatibilität, beschädigte Kabel oder Konfiguration des Kommunikationsports..

2. Bedeutet ein BMS-Kommunikationsalarm, dass das BMS ausgefallen ist?

Nein. Das BMS kann die Zellen weiterhin korrekt überwachen, während die Kommunikation zwischen dem BMS und PCS, EMS, Master-BMS oder SCADA fehlschlägt. Identifizieren Sie die fehlerhafte Kommunikationsgrenze, bevor Sie die Hardware ersetzen.

3. Können zwei Geräte CAN oder RS485 unterstützen und trotzdem inkompatibel sein?

Ja. Das Teilen derselben physischen Schnittstelle garantiert keine Kompatibilität. Geräte müssen sich auch aufProtokoll, Bitrate oder Baudrate, Nachrichten-/Registerdefinitionen, Adressierung, Datenskalierung und Steuerlogik.

4. Warum schlägt die BMS-Kommunikation intermittierend fehl?

Intermittierende Fehler können durch lose Verbindungen, schlechte Terminierung, elektrische Störungen, Kabelverlegung, instabile Stromversorgungen, Netzwerktopologie, Watchdog-Timing oder Firmware-Probleme verursacht werden. Notieren Sie, wann der Fehler auftritt, bevor Sie das System neu starten.

5. Was sollte nach der Behebung eines BMS-Kommunikationsfehlers überprüft werden?

Bestätigen Sie, dass der PCS korrekt empfängtSoC, Spannung, Strom, Temperatur, Alarme und Lade-/Entladegrenzen, die BMS-Schutzbefehle befolgt, korrekt an das EMS meldet und die Kommunikation nach einem kontrollierten Neustart wiederherstellt.