RS485 vs. CAN für industrielles Batterie-BMS: Wie OEMs die richtige Kommunikationsschnittstelle auswählen

Die Wahl zwischen RS485 und CAN für ein industrielles Batterie-BMS ist nicht nur eine Frage des Vergleichs der Kommunikationsgeschwindigkeit.

Die richtige Wahl hängt von der OEM-Gerätearchitektur, der erforderlichen Aktualisierungsrate, der Netzwerktopologie, der Controller-Unterstützung, der Fehlerbehandlungsstrategie, den Softwareressourcen und dem Diagnose-Workflow ab.

Noch wichtiger ist, dass ein RS485- oder CAN-Anschluss keine Kompatibilität garantiert. Zwei Geräte verwenden möglicherweise dieselbe physische Schnittstelle, kommunizieren aber trotzdem nicht, weil ihre Baudrate, ihr Nachrichtenformat, ihre Adressierung, Skalierung, ihr Timing oder ihr Anwendungsprotokoll unterschiedlich sind.

Für OEM-Ingenieure lautet die eigentliche Frage daher nicht nur „RS485 vs. CAN?“ Es ist:

Welche Kommunikationsarchitektur kann die benötigten Batteriedaten und -befehle über die gesamte Betriebsdauer der Anlage zuverlässig austauschen?

Die kurze Antwort: Wann sollten Sie sich für RS485 oder CAN entscheiden?

RS485 eignet sich häufig, wenn das System ein definiertes Master-Gerät, relativ vorhersehbare Abfragen, moderate Aktualisierungsraten und ein einfaches Punkt-zu-Punkt- oder Multidrop-Netzwerk verwendet.

CAN eignet sich oft dann, wenn mehrere Steuerungen ereignisgesteuerte Kommunikation, Nachrichtenpriorisierung, verteilte Steuerung, schnelle Fehlermeldung oder Integration in ein bestehendes CAN-basiertes Maschinennetzwerk benötigen.

Auswahlfaktor	RS485	DÜRFEN
Typisches Kommunikationsmodell	Master-Slave oder Client-Server	Nachrichtenbasierte Kommunikation mit mehreren Knoten
Gemeinsamer Datenaustausch	Umfrage und Antwort	Broadcast- und ereignisgesteuerte Nachrichten
Netzwerkzugriff	Gesteuert durch das Master- oder Anwendungsprotokoll	Nachrichtenarbitrierung basierend auf der Identifikatorpriorität
Integrationsaufwand	Für die Grundüberwachung oft einfacher	Oft besser geeignet für verteilte Echtzeitsysteme
Protokoll höherer Ebene	Modbus RTU oder proprietäres Protokoll	CANopen, J1939 oder proprietäres Protokoll
Typische Verwendung	Überwachung, Konfiguration und Überwachungskontrolle	Mobile Maschinen, Roboter, AGVs und verteilte Steuerungen
Hauptrisiko	Gleiche RS485-Hardware, aber anderes serielles Protokoll	Gleiche CAN-Hardware, aber inkompatible Nachrichtendefinitionen

Dieser Vergleich ist nur ein Ausgangspunkt. Die endgültige Entscheidung muss auf den vollständigen Kommunikationsanforderungen des Geräts basieren.

RS485 und CAN sind nicht dieselbe Spezifikationsart

Ein Grund dafür, dass Diskussionen zwischen RS485 und CAN verwirrend werden, besteht darin, dass die beiden Begriffe nicht genau denselben Teil eines Kommunikationssystems beschreiben.

RS485 definiert in erster Linie eine elektrische Schnittstelle für eine symmetrische serielle Kommunikation. Es beschreibt, wie elektrische Signale zwischen Treibern und Empfängern übertragen werden, definiert jedoch nicht, was die Daten bedeuten.

Texas Instruments' RS-485-Designhandbuch beschreibt RS485 als einen rein elektrischen Standard, der in industriellen Anwendungen weit verbreitet ist.

Eine vollständige RS485-Batterie-BMS-Implementierung erfordert daher auch ein Anwendungsprotokoll, wie zum Beispiel:

• Modbus RTU.

• Ein herstellerspezifisches Registerprotokoll.

• Ein proprietäres Befehls-und-Antwort-Format.

• Ein weiteres dokumentiertes serielles Protokoll.

CAN umfasst eine Datenverbindungsschicht sowie definierte Optionen für die physikalische Schicht. Der CAN-Controller übernimmt Funktionen wie Frame-Übertragung, Arbitrierung, Fehlererkennung und Quittierung. CAN definiert jedoch immer noch nicht automatisch die Bedeutung von Batteriedaten.

Ein CAN-Bus-Batterie-BMS kann Folgendes verwenden:

• CANopen.

• SAE J1939.

• Das proprietäre Protokoll eines Fahrzeug- oder Geräteherstellers.

• Die proprietäre Nachrichtenkarte eines Batterielieferanten.

Der Übersicht über CAN in der Automatisierung erklärt, dass die unteren Schichten von CAN durch die ISO 11898-Reihe standardisiert sind. Es sind weiterhin Protokolle höherer Schichten erforderlich, um zu definieren, wie Geräte Anwendungsdaten austauschen.

Daher:

RS485 oder CAN definiert, wie Daten übertragen werden können. Das BMS-Kommunikationsprotokoll definiert, was die Daten bedeuten und wie das Gerät reagieren soll.

Welche Informationen sollte das Batterie-BMS austauschen?

Definieren Sie vor der Auswahl einer Schnittstelle, welche Informationen der OEM-Controller tatsächlich benötigt.

Zu den allgemeinen BMS-Daten können gehören:

• Packspannung.

• Lade- und Entladestrom.

• Ladezustand.

• Gesundheitszustand, sofern unterstützt.

• Minimale und maximale Zellspannung.

• Daten zur Batterie- und Zelltemperatur.

• Lade- und Entladeerlaubnis.

• Empfohlene Strom- oder Leistungsgrenzen.

• Alarm- und Schutzstatus.

• Schütz- oder Relaisstatus.

• Verbindungsstatus des Ladegeräts.

• Firmware- und Hardwareversion.

• Fehlerhistorie oder Diagnoseinformationen.

• Schätzung der verbleibenden Energie oder Laufzeit.

Einige Systeme erfordern auch Befehle vom Host-Controller, wie zum Beispiel:

• Aufforderung zum Aufwachen oder Schlafen.

• Schützsteuerung.

• Fehler-Reset.

• Auswahl der Betriebsart.

• Laden aktivieren oder deaktivieren.

• Anfrage zur Strombegrenzung.

• Service- oder Kalibrierungsbefehle.

Gehen Sie nicht davon aus, dass jedes BMS alle diese Funktionen unterstützt. Jedes erforderliche Signal sollte als obligatorisch, optional oder nur für die Diagnose klassifiziert werden.

So funktioniert die RS485-Batterie-BMS-Kommunikation

RS485 verwendet üblicherweise ein Differenzpaar zur Übertragung serieller Daten. Abhängig vom Design kann eine Zweidraht-Halbduplex- oder eine Vierdraht-Vollduplex-Konfiguration verwendet werden.

Bei vielen Batterieanwendungen fungiert ein Host-Controller, ein Display, ein Gateway oder ein Ladegerät als Master. Es sendet eine Anfrage an eine definierte Batterieadresse und die Batterie sendet die angeforderten Daten zurück.

Eine typische Reihenfolge könnte sein:

1. Der Host fordert Packspannung an.

2. Das BMS validiert die Adresse und den Befehl.

3. Das BMS gibt die Wert- und Fehlerprüfdaten zurück.

4. Der Host fragt den aktuellen, Temperatur- oder Alarmstatus ab.

5. Der Abfragezyklus wiederholt sich.

Vorteile von RS485 für die Batterie-BMS-Integration

RS485 kann eine praktische Wahl sein, wenn:

• Der OEM-Controller verfügt bereits über einen RS485-Anschluss.

• Das System hat einen eindeutigen Master.

• Batterieinformationen können durch regelmäßige Abfragen gesammelt werden.

• Die erforderliche Aktualisierungsrate ist moderat.

• Ein einfaches Multidrop-Netzwerk reicht aus.

• Modbus RTU oder ein anderes dokumentiertes Protokoll wird bereits verwendet.

• Das Engineering-Team verfügt über Erfahrung in der seriellen Kommunikation.

Der Beamte Modbus-Spezifikationsseite Bietet das aktuelle Modbus-Anwendungsprotokoll und eine Anleitung zur Implementierung einer seriellen Leitung. Die Modbus Organization empfiehlt für neue serielle Implementierungen ihr Serial Line Protocol and Implementation Guide V1.02.

Einschränkungen und Risiken von RS485

RS485 definiert nicht:

• Geräteadressen.

• Standorte registrieren.

• Datenskalierung.

• Bytereihenfolge.

• Befehlsbedeutungen.

• Abfrageintervalle.

• Timeout-Verhalten.

• Fehlerbehebung.

• Sicherheit oder Authentifizierung.

Diese Elemente gehören zum Anwendungsprotokoll.

Durch Abfragen kann es auch zu Latenz kommen. Wenn ein Controller mehrere Batterien und viele Register nacheinander abfragt, muss die wichtigste Fehlermeldung möglicherweise bis zur nächsten geplanten Anforderung warten.

Diese Verzögerung mag für ein Überwachungssystem akzeptabel sein, für einen schnellen Regelkreis jedoch ungeeignet. Der Bedarf muss quantifiziert und nicht angenommen werden.

So funktioniert die CAN-Bus-Batterie-BMS-Kommunikation

CAN verwendet Nachrichtenkennungen anstelle eines einfachen Zieladressenmodells. Geräte überwachen den gemeinsamen Bus und verarbeiten die für sie relevanten Nachrichten.

Wenn mehr als ein Knoten versucht zu übertragen, ermöglicht die CAN-Arbitrierung, dass die Nachricht mit höherer Priorität fortgesetzt wird, ohne dass der Gewinnerrahmen beschädigt wird. Dadurch eignet sich CAN für Systeme, in denen mehrere Controller zeitkritische Daten gemeinsam nutzen müssen.

Der CAN-Controller bietet außerdem eine integrierte Fehlererkennung und -signalisierung auf Frame-Ebene. Diese Funktionen verbessern die Robustheit der Kommunikation, ersetzen jedoch nicht die Notwendigkeit eines korrekten Systemdesigns, einer korrekten Verkabelung und einer Fehlerbehandlung auf Anwendungsebene.

Vorteile von CAN für die Batterie-BMS-Integration

CAN kann eine gute Wahl sein, wenn:

• Die Maschine verfügt bereits über ein CAN-Netzwerk.

• Mehrere Controller benötigen Batterieinformationen.

• Störungen müssen ohne Abwarten eines Abfragezyklus gemeldet werden.

• Unterschiedliche Botschaften erfordern unterschiedliche Prioritäten.

• Das System nutzt eine verteilte Echtzeitsteuerung.

• Der OEM unterstützt bereits CANopen, J1939 oder ein definiertes proprietäres Protokoll.

• Busanalysatoren, DBC-Dateien oder CAN-Diagnosetools sind Teil des Entwicklungsprozesses.

CAN in Automation listet standardisierte Ansätze höherer Ebenen auf, einschließlich CANopen- und J1939-basierte Profile . Die Auswahl der CAN-Hardware allein bestimmt nicht, welches dieser Protokolle verwendet wird.

Einschränkungen und Risiken von CAN

Ein CAN-Port garantiert keine Kompatibilität mit einem anderen CAN-Gerät.

Der OEM muss noch Folgendes bestätigen:

• Klassisches CAN, CAN FD oder eine andere Variante.

• Nominale Bitrate.

• Bezeichnerformat.

• Standard- oder erweiterte Bezeichner.

• Nachrichten-IDs.

• Datenlänge.

• Bytereihenfolge.

• Skalierung und Offset.

• Übertragungszeitraum.

• Durch Ereignisse ausgelöste Bedingungen.

• Timeout-Grenzwerte.

• Startverhalten des Knotens.

• Fehlerbehebung.

• Erforderliches Protokoll einer höheren Schicht.

Eine Batterie, die proprietäre CAN-Nachrichten verwendet, kommuniziert nicht automatisch mit einem Controller, der für CANopen oder J1939 entwickelt wurde.

RS485 vs. CAN-Architektur

Abbildung 1. RS485 verwendet üblicherweise eine kontrollierte Anfrage-Antwort-Kommunikation, während CAN die verteilte Nachrichtenübertragung und die auf Kennungen basierende Arbitrierung unterstützt. Für beide muss noch das genaue Anwendungsprotokoll definiert werden.

RS485 vs. CAN: Detaillierter OEM-Vergleich

Netzwerktopologie

RS485 verwendet üblicherweise eine Trunk- oder Daisy-Chain-Anordnung mit kurzen Gerätezweigen. CAN verwendet ebenfalls eine lineare Bustopologie mit Abschluss an beiden Enden.

Eine Sternverkabelung sollte für keine der beiden Schnittstellen als sicher angesehen werden. Lange Abzweigungen und eine unkontrollierte Kabelführung können zu Reflexionen und Signalintegritätsproblemen führen.

Die zulässige Topologie ist abhängig von:

• Kabellänge.

• Bit- oder Baudrate.

• Stub-Länge.

• Eigenschaften des Transceivers.

• Beendigung.

• Kabelimpedanz.

• Elektromagnetische Umgebung.

Kommunikations-Timing

Das RS485-Timing wird oft durch den Polling-Zeitplan des Masters gesteuert. Ingenieure können das Datenalter im schlimmsten Fall abschätzen, indem sie Folgendes berechnen:

• Anzahl der Geräte.

• Anzahl der Anfragen pro Gerät.

• Rahmenlänge.

• Baudrate.

• Reaktionsverzögerung.

• Anzahl der Wiederholungen.

• Timeout-Zeitraum.

CAN verwendet üblicherweise eine periodische oder ereignisgesteuerte Übertragung. Ingenieure müssen stattdessen Folgendes bewerten:

• Busauslastung.

• Nachrichtenpriorität.

• Übertragungsintervall.

• Im schlimmsten Fall verzögert sich die Schiedsgerichtsbarkeit.

• Fehlerrahmenverhalten.

• Timeout-Überwachung.

Keine der beiden Architekturen ist in jedem realen System automatisch schneller. Ein gut konzipiertes RS485-Protokoll kann ein überlastetes CAN-Netzwerk übertreffen, während ein richtig priorisiertes CAN-System kritische Fehler schneller melden kann als ein langer Abfragezyklus.

Fehlerbehandlung

Bei RS485 muss die Anwendung normalerweise fehlende Antworten, ungültige Prüfsummen, doppelte Adressen und Kommunikations-Timeouts erkennen.

Für CAN stellt der Controller Fehlermechanismen auf Frame-Ebene bereit, aber die Anwendung muss dennoch entscheiden, was zu tun ist, wenn:

• Eine erforderliche Nachricht kommt nicht mehr an.

• Ein Knoten startet neu.

• Daten werden veraltet.

• Der Bus geht in einen Fehlerzustand über.

• Eine Batterie meldet einen Schutzalarm.

• Zwei Geräte verwenden widersprüchliche Kennungen.

Der Zustand der Kommunikation muss in eine sichere Reaktion der Ausrüstung umgewandelt werden.

Diagnose

Die RS485-Diagnose kann Folgendes verwenden:

• Serielle Terminalsoftware.

• Protokollanalysatoren.

• Tools zum Lesen von Registern.

• Oszilloskope.

• USB-zu-RS485-Adapter.

• Kommunikationszähler und Protokolle.

Die CAN-Diagnose kann Folgendes verwenden:

• CAN-Bus-Analysatoren.

• DBC- oder EDS-Dateien.

• CANopen- oder J1939-Diagnosetools.

• Oszilloskope.

• Buslastanalyse.

• Fehlerzähler und Nachrichtenprotokolle.

Das Serviceteam muss Werkzeuge und Dokumentation erhalten, die zum ausgewählten Protokoll passen.

Die wichtigsten Kompatibilitätsdokumente

Fordern Sie vor der Zulassung einer RS485- oder CAN-Batterie ein Kommunikationspaket mit den folgenden Artikeln an.

1. Schnittstellendefinition

• RS485, klassisches CAN oder CAN FD.

• Gegebenenfalls Halbduplex- oder Vollduplex-Konfiguration.

• Isolierte oder nicht isolierte Schnittstelle.

• Steckerhersteller und Teilenummer.

• Pinbelegung.

• Anforderungen an Kabel und Abschirmung.

• Anforderungen an Bezugsflächen.

2. Netzwerkkonfiguration

• Baudrate oder CAN-Bitrate.

• Geräte- oder Knotenadresse.

• Bezeichnerformat.

• Kündigungsvoraussetzungen.

• Vorspannungsanforderungen für RS485.

• Maximale Knotenanzahl.

• Empfohlene Kabellänge und Topologie.

• Start- und Erkennungsverfahren.

3. Nachrichtenwörterbuch

Dokumentieren Sie für jede Nachricht oder jedes Register Folgendes:

• Name.

• Kennung oder Registeradresse.

• Datentyp.

• Bytereihenfolge.

• Skalierung.

• Versatz.

• Einheit.

• Gültiger Bereich.

• Aktualisierungsintervall.

• Lese- oder Schreibberechtigungen.

• Verhalten, wenn der Wert nicht verfügbar ist.

4. Alarm- und Schutzzuordnung

Definieren Sie, wie das BMS berichtet:

• Überspannung.

• Unterspannung.

• Überstrom.

• Kurzschluss.

• Hohe oder niedrige Temperatur.

• Kommunikationsfehler.

• Schützfehler.

• Sensorfehler.

• Zellungleichgewicht, sofern unterstützt.

• Lade- und Entladebeschränkungen.

5. Timeout- und Wiederherstellungsregeln

Angeben:

• Wenn Daten veraltet sind.

• Wie viele Wiederholungen sind zulässig.

• Was der Host nach einer Zeitüberschreitung tun soll.

• Wie das BMS aus dem Schlaf erwacht.

• Was passiert nach dem Ein- und Ausschalten?

• Ob Fehler automatisch behoben werden oder ein Befehl erforderlich ist.

• Wie sich Firmware-Versionen auf die Kompatibilität auswirken.

Öffentliche Dailymag-Energiekommunikationsoptionen

Die öffentlichen Produktinformationen von Dailymag Energy zeigen, dass die Kommunikationsanforderungen je nach Batteriekonfiguration variieren.

Die veröffentlichten 25,2V 10,2Ah Batterieseite listet die RS485-Kommunikation auf.

Die veröffentlichten 51,2V 108Ah Batterieseite listet RS485- und CAN-Kommunikation auf.

Diese Auflistungen bestätigen, dass die physischen Kommunikationsoptionen in den veröffentlichten Konfigurationen enthalten sind. Sie bestätigen nicht, dass ein bestimmtes Modbus-, CANopen-, J1939- oder proprietäres Protokoll mit der Steuerung eines Kunden funktioniert.

Protokollkompatibilität, Nachrichtendokumentation, Connector-Definition und Softwareverhalten müssen projektspezifisch bestätigt werden.

Käufer können die breitere Bewertung vornehmen Dailymag Energy-Produktpalette , aber die endgültige Schnittstelle sollte erst nach technischer Überprüfung eingefroren werden.

Acht Fragen, die die richtige Schnittstelle bestimmen

1. Welche Schnittstelle unterstützt der vorhandene Controller?

Durch die Verwendung einer vorhandenen Controller-Schnittstelle können Hardware- und Softwareänderungen reduziert werden. Die Protokollkompatibilität muss jedoch noch bestätigt werden.

2. Tritt die Batterie in ein bestehendes Netzwerk ein?

Wenn die Maschine bereits CANopen, J1939 oder ein proprietäres CAN-Netzwerk verwendet, kann die Hinzufügung eines weiteren CAN-Geräts sinnvoll sein. Wenn die Batterie nur mit einem Display oder Gateway verbunden ist, kann RS485 ausreichend sein.

3. Wie schnell müssen kritische Daten eintreffen?

Definieren Sie tatsächliche Zeitanforderungen für Stromgrenzen, Temperaturalarme, niedrigen Ladezustand und Schutzereignisse.

„Echtzeit“ ist keine messbare Anforderung. Geben Sie eine maximal akzeptable Verzögerung an.

4. Wie viele Geräte teilen sich den Bus?

Berücksichtigen Sie Batterien, Ladegeräte, Displays, Wechselrichter, Controller, Gateways und Servicetools. Das Netzwerk sollte als Gesamtsystem betrachtet werden.

5. Wer kontrolliert die Kommunikation?

Ein einfaches Überwachungssystem kann mit einer vom Master gesteuerten RS485-Abfrage gut funktionieren. Eine verteilte Maschine kann von der ereignisgesteuerten Kommunikation von CAN profitieren.

6. Welche Diagnosetools nutzt das Team bereits?

Entwicklungs- und Serviceteams verfügen möglicherweise bereits über Modbus-Tools, CAN-Analysatoren, DBC-Workflows oder Controller-Bibliotheken. Die Wiederverwendung bewährter Tools kann das Integrationsrisiko verringern.

7. Wie werden zukünftige Versionen verwaltet?

Durch das Hinzufügen neuer Datenfelder sollte die vorhandene Ausrüstung nicht beschädigt werden. Definieren Sie reservierte Register, Nachrichtenversionierung, Kompatibilitätsregeln und Firmware-Identifikation.

8. Was passiert, wenn die Kommunikation fehlschlägt?

Das Gerät benötigt eine sichere Reaktion, wenn Batteriedaten fehlen, verzögert, unplausibel oder inkonsistent sind.

Warten Sie nicht bis zu Feldtests, um dieses Verhalten zu definieren.

Ein sechsstufiger BMS-Kommunikationsvalidierungsprozess

Eine zuverlässige Integration sollte kontrollierte Engineering-Phasen durchlaufen.

Stufe 1: Erforderliche Daten und Befehle definieren

Identifizieren Sie jedes Signal, das die Ausrüstung benötigt. Klassifizieren Sie jedes als obligatorisch, optional oder diagnostisch.

Stufe 2: Bestätigen Sie die physische Schnittstelle

Überprüfen Sie Transceiver, Anschlussstifte, Isolierung, Bezugserde, Abschirmung, Terminierung und Kabelanforderungen.

Stufe 3: Bauen Sie das Netzwerk auf

Erstellen Sie die gewünschte Topologie mit der tatsächlichen Kabellänge, Geräteanzahl, Terminierung und Zweiganordnung.

Stufe 4: Ordnen Sie das Protokoll zu

Implementieren Sie Bezeichner, Register, Skalierung, Bytereihenfolge, Nachrichten-Timing, Befehle, Alarme und Timeout-Regeln.

Stufe 5: Normal- und Fehlerbedingungen im Prüfstandtest

Prüfen:

• Normaler Start.

• Akku schlafen und aufwachen.

• Neustart des Controllers.

• Fehlende Nachrichten.

• Beschädigte oder ungültige Frames.

• Falsche Adresse oder Kennung.

• Kabel abgezogen.

• Buskurzschluss oder Unterbrechung.

• Wiederholte Wiederholungsversuche.

• Hoher Busverkehr.

• BMS-Schutzereignisse.

Stufe 6: Validierung der gesamten Maschine

Testen Sie Akku, Controller, Ladegerät und Ausrüstung gemeinsam unter repräsentativen Last-, Temperatur- und elektromagnetischen Bedingungen.

Abbildung 2. Die Kommunikationsvalidierung sollte von den Anforderungen und der Verkabelung über die Protokollzuordnung, die Labordiagnose und das Testen der kompletten Maschine reichen.

Häufige BMS-Kommunikationsfehler

Richtiger Stecker, falsche Pinbelegung

Zwei Produkte verwenden möglicherweise das gleiche Anschlussgehäuse, weisen jedoch die Strom-, Erdungs- und Kommunikationspins unterschiedlich zu. Eine visuelle Übereinstimmung ist kein Beweis für die Kompatibilität.

Richtige Schnittstelle, falsches Protokoll

Ein RS485-BMS, das proprietäre Befehle verwendet, funktioniert nicht automatisch mit einem Modbus-Controller. Ein CAN-BMS, das proprietäre Frames verwendet, funktioniert nicht automatisch mit CANopen- oder J1939-Geräten.

Fehlende oder falsche Kündigung

Eine unsachgemäße Terminierung kann zu Reflexionen, Kommunikationsfehlern oder zeitweiligen Fehlern führen. Überprüfen Sie den Abschluss auf Netzwerkebene, anstatt jedem Gerät Widerstände hinzuzufügen.

Falsche Datenskalierung

Ein Rohwert von 512 kann je nach Skalierung 51,2 V, 5,12 V oder etwas anderes bedeuten. Einheiten, vorzeichenbehaftete Werte, Bytereihenfolge und Offsets müssen dokumentiert werden.

Timeout-Konflikt

Der Host kann Daten vor der nächsten geplanten Nachricht des BMS als ungültig markieren. Alternativ verwendet der Host möglicherweise zu lange veraltete Daten.

Wach- und Schlafkonflikt

Das BMS wechselt möglicherweise in den Energiesparmodus, während der Controller eine kontinuierliche Kommunikation erwartet. Weckquellen und Zeitpunkt müssen vereinbart werden.

Erdung und elektromagnetisches Rauschen

Eine unsachgemäße Referenzerdung, Abschirmung oder Isolierung kann zu Fehlern führen, selbst wenn die Tischkommunikation stabil erscheint. Testen Sie es mit der tatsächlichen Maschine, dem Ladegerät, dem Motorantrieb und der Kabelführung.

Sicherheit sollte über der Schnittstelle definiert werden

Gehen Sie nicht davon aus, dass RS485 oder CAN automatisch Authentifizierung, Verschlüsselung oder Zugriffskontrolle bereitstellen.

CAN in Automation weist darauf hin, dass die standardisierten CAN-Datenverbindungsprotokolle grundsätzlich keine Sicherheitsmaßnahmen bieten. Ebenso sollte eine einfache serielle Modbus-Implementierung nicht nur deshalb als sicherer Kommunikationskanal betrachtet werden, weil sie RS485 verwendet.

Wenn unbefugter Zugriff oder Nachrichtenmanipulation Teil des Bedrohungsmodells des Projekts ist, definieren Sie die Sicherheit auf der entsprechenden Systemebene. Zu den möglichen Kontrollen können gehören:

• Authentifizierte Gateways.

• Netzwerksegmentierung.

• Sicherer Servicezugang.

• Befehlsberechtigung.

• Firmware-Signierung.

• Sicherer Start.

• Überprüfung der Nachrichtenaktualität.

• Authentifizierung auf Anwendungsebene.

• Physische Zugangskontrolle.

Sicherheitsanforderungen sollten in der Gerätearchitektur enthalten sein und nicht nach der Protokollintegration hinzugefügt werden.

Was in einer RS485- oder CAN-Batterie-Anfrage enthalten sein sollte

Stellen Sie dem Batterielieferanten Folgendes zur Verfügung:

1. Gerätetyp und Controller-Modell.

2. Erforderliche physische Schnittstelle.

3. Vorhandenes Netzwerkprotokoll.

4. Baudrate oder CAN-Bitrate.

5. Standard- oder erweiterte CAN-Identifier-Anforderung.

6. Erforderliche Batteriesignale und Aktualisierungsintervalle.

7. Befehle, die der Host senden muss.

8. Stecker und Pinbelegung.

9. Kabellänge, Topologie und Knotenanzahl.

10. Anforderungen an Isolierung, Erdung und Abschirmung.

11. Alarm-, Timeout- und Safe-State-Verhalten.

12. Erforderliche Protokolldateien, Testtools und Validierungsunterstützung.

Wenn das Protokoll noch nicht ausgewählt wurde, stellen Sie die Steuerungsarchitektur und die Timing-Anforderungen bereit, anstatt eine Schnittstelle aus Gewohnheit auszuwählen.

Häufig gestellte Fragen

1. Ist CAN für ein Batterie-BMS immer besser als RS485?

Nein. CAN bietet nützliche Arbitrierungs-, Fehlerbehandlungs- und verteilte Kommunikationsfunktionen, aber RS485 ist möglicherweise einfacher und für ein Master-gesteuertes Überwachungssystem völlig ausreichend. Die richtige Wahl hängt von der Ausstattung ab.

2. Können zwei RS485-Geräte automatisch kommunizieren?

Nein. Sie müssen kompatible Baudraten, Verkabelungen und Anwendungsprotokolle verwenden. Das Vorhandensein von RS485-Anschlüssen an beiden Geräten garantiert keine kompatiblen Befehle oder Register.

3. Kann jede CAN-Batterie mit einem CAN-Controller funktionieren?

Nein. Die Geräte müssen kompatible Bitraten, Kennungen, Nachrichtendefinitionen, Timing und Protokolle höherer Schichten verwenden.

4. Bedeutet RS485 Modbus RTU?

Nein. Modbus RTU verwendet üblicherweise RS485, RS485 kann jedoch auch proprietäre oder andere serielle Protokolle übertragen.

5. Bedeutet CAN CANopen?

Nein. CANopen ist ein übergeordnetes Protokoll, das auf CAN basiert. Andere Systeme verwenden möglicherweise J1939 oder proprietäre CAN-Nachrichten.

6. Welche Schnittstelle ist besser für AGVs und Industrieroboter?

CAN ist in verteilten mobilen Maschinen weit verbreitet, die Antwort hängt jedoch vom vorhandenen Steuerungsnetzwerk, der Latenz, den Diagnose- und Integrationsressourcen ab. RS485 ist möglicherweise weiterhin für eine separate Überwachungsbatterieverbindung geeignet.

7. Was ist eine DBC-Datei?

Eine DBC-Datei beschreibt CAN-Nachrichten, Identifier, Signale, Skalierung und zugehörige Informationen. Es kann Software und Diagnosetools dabei helfen, CAN-Daten zu interpretieren, aber nicht jedes proprietäre CAN-Projekt bietet eines.

8. Ist eine Terminierung sowohl für RS485 als auch für CAN erforderlich?

Beide erfordern im Allgemeinen eine kontrollierte Terminierung basierend auf dem Netzwerkdesign. Der richtige Widerstand und die richtige Platzierung hängen von der Schnittstelle, der Topologie und der Transceiver-Implementierung ab.

9. Sollte die Kommunikationsschnittstelle isoliert sein?

Die Isolierung hängt von der Erdung, der Kabellänge, den Spannungsunterschieden, den EMV-Bedingungen und der Sicherheitsarchitektur des Systems ab. Der Lieferant und der Anlagentechniker sollten es gemeinsam bewerten.

10. Was sollte vor der Zulassung der Batterie geprüft werden?

Testen Sie normale Daten, Timing, Alarme, Befehle, Start, Ruhezustand und Wachzustand, Zeitüberschreitungen, Neustart des Controllers, Kabelfehler, hohen Datenverkehr, Ladegerätbetrieb und repräsentative Maschinenlasten.

Wählen Sie die Kommunikationsarchitektur, bevor Sie die Batterie einfrieren

Der beste Zeitpunkt zum Definieren der RS485- oder CAN-Kommunikation ist, bevor das Batteriegehäuse, der Stecker und die Steuerungssoftware eingefroren sind.

Beginnen Sie mit den Daten-, Zeit- und Fehlerreaktionsanforderungen. Wählen Sie dann die physische Schnittstelle, die Netzwerktopologie und das übergeordnete Protokoll aus, die zur Gerätearchitektur passen.

Dokumentieren Sie jedes Register oder jede Nachricht, testen Sie das gesamte Netzwerk und definieren Sie, was die Maschine tun soll, wenn die Kommunikation unzuverlässig wird.

Dailymag Energy unterstützt die maßgeschneiderte Anpassung von Lithium-Batteriepaketen an Industrieanlagen. Wenn Ihr Projekt RS485, CAN oder eine andere BMS-Kommunikationsschnittstelle erfordert, bereiten Sie die Controller-Informationen, Protokollanforderungen, Pinbelegung und die Liste der erforderlichen Daten vor, bevor Sie ein Angebot anfordern.

Kontaktieren Sie das Engineering- und Vertriebsteam von Dailymag Energy um eine projektspezifische Kommunikationsüberprüfung zu beginnen.