CAN-Bus Analyse

Ohne CAN‑Matrix und Signal‑Definitionen sind die Rohdaten ziemlich nutzlos. Du kannst danach googlen oder selbst rekonstruieren, ersteres geht vermutlich schneller.

Jo, viel zu extrahieren ist da nicht. Wenn es Canopen sein sollte, sollten die IDs über ein EDS zu dekodieren sein - da werden die Dinger eingestellen und welche Funktion sie haben. Ansonsten bist Du auf einer spaßigen Reise des ReverseEngineerings unterwegs, viel Glück dabei.

Marius schrieb:

BMZ_1.jpg ... im Anhang ein Bild einer CAN-Bus Aufzeichnung, welche mit PCAN-View gemacht wurde.

Wichtige Regeln - erst lesen, dann posten! Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.

Das ist doch nicht sooh schwierig zu verstehen.

Guck dir nach ID sortiert an, wie sich die Daten z.B. mit Ladung, Entladung, Temperatur, ... ändern und ob das zu CiA 418 passt. Ohne Referenzdaten oder Doku kann man nichts damit anfangen. Viel Spaß.

https://www.can-cia.org/can-knowledge/cia-418-canopen-device-profile-for-battery-modules

Schon mal die Frames durch eine KI gejagt?

sortier mal nach den IDs und der Zykluszeit

wenn es eine Dasy Chain ist lassen sich meis ähnliche Blöcke finden

zb 181 Spannung Modul 1 182 Spannung Modul 2 183 Spannung Modul 3

381 Temp Modul 1 382 Temp Modul 2 383 Temp Modul 3

(bei dir sehe ich immer 6 Blöcke mit der selben Zykluszeit. da ist wahrscheinlich etwas ähnliches drin.)

log mal einen kompletten Lade / Entlade Zyklus mit und plotte alle byte Werte eines Sets aus je einem "Moduldatensatz".

Dann siehst du sehr schnell, was da los ist, außer die "verschlüsseln" das irgendwie

und setz die daten als csv hier rein

Das sagt der Chat_5.4:

Ja — teilweise. Ich kann aus dem Screenshot einige plausible Strukturen und Felder ableiten, aber nicht belastbar das komplette BMZ-Hyperion-Protokoll rekonstruieren, solange kein DBC/Protokolldokument oder ein längerer Log mit Zustandsänderungen vorliegt. Ich erfinde dir da lieber nichts zusammen.

Was man aus dem Screenshot ziemlich gut erkennen kann

Im Trace sieht man mehrere Gruppen von CAN-IDs:

• 0C2h, 0C3h, 0C1h
• 102h, 103h, 101h
• 142h, 143h, 141h
• 182h, 183h, 181h
• 1C2h, 1C3h, 1C1h
• 382h, 383h, 381h
• 4C3h
• 6C1h, 6C2h, 6C3h
• 085h, 202h, 242h, 282h

Das sieht sehr stark nach einem zyklischen Multi-Frame-Schema pro Batterie-String/Modul aus:

• Suffix 1/2/3 könnte auf drei Slaves / drei Packs / drei Module hindeuten.
• Die Blöcke 0x100, 0x140, 0x180, 0x1C0 scheinen je Pack unterschiedliche Signalgruppen zu übertragen.

Auffällige Muster im Screenshot

Ich lese aus dem Bild u. a. folgende Frames:

Gruppe für „Kanal 2“

• 0C2h: 01 00 00 00 00 00 00 00
• 102h: 00 00 00 00 00 01 1A 59
• 142h: A0 0F A1 0F 03 00 1A 72
• 182h: 12 00 14 00 11 00 1A DA
• 1C2h: FF FF 08 00 59 58 1A 61
• 382h: B7 50 ED 00 00 00 0D E3
• 6C2h: C3 E1 10 40 00 00 00 00

Gruppe für „Kanal 3“

• 0C3h: 01 00 00 00 00 00 00 00
• 103h: 00 00 00 00 00 01 14 FF
• 143h: 99 0F A4 0F 41 00 14 31
• 183h: 12 00 13 00 05 00 14 69
• 1C3h: 00 00 18 00 58 58 14 5A
• 383h: B7 50 ED 00 00 00 0A B0
• 6C3h: C3 E1 10 40 00 00 00 00

Gruppe für „Kanal 1“

• 0C1h: 01 00 00 00 00 00 00 00
• 101h: 00 01 00 00 00 01 1F 76
• 141h: 98 0F 9C 0F 81 00 1F 5B
• 181h: 12 00 13 00 03 00 1F A3
• 1C1h: 00 00 10 00 56 56 1F 04
• 381h: B7 50 ED 00 00 00 10 AF
• 6C1h: C3 E1 10 40 00 00 00 00

Sehr wahrscheinliche Interpretation

1) 0C1h/0C2h/0C3h

01 00 00 00 00 00 00 00

Das wirkt wie:

• Heartbeat / Alive / Status gültig
• Byte 0 = 01 = Gerät online / Daten gültig / Freigabe vorhanden

Mehr kann man daraus ohne Vergleichsdaten nicht seriös sagen.

2) 141h/142h/143h → sieht stark nach Zellspannungen-Min/Max + Zellnummer aus

Beispiel 142h: A0 0F A1 0F 03 00 1A 72

Wenn man Little-Endian 16-bit liest:

• Byte0..1 = 0x0FA0 = 4000
• Byte2..3 = 0x0FA1 = 4001
• Byte4..5 = 0x0003 = 3
• Byte6..7 = 0x721A oder CRC/Counter?
  Vorsicht: im CAN sind das einfach zwei weitere Bytes 1A 72; je nach Endianness 0x721A = 29210.

Das ist extrem typisch für:

• U_cell_min = 4000 mV
• U_cell_max = 4001 mV
• cell_index = 3

Weitere Beispiele passen ebenfalls:

• 141h: 98 0F 9C 0F 81 00 1F 5B

  • 0x0F98 = 3992 mV
  • 0x0F9C = 3996 mV
  • 0x0081 = 129 → das wirkt nicht wie einfache Zellnummer, eher:
    • obere Bits = Flags
    • untere Bits = Zellindex
    • oder zwei 8-bit Felder

• 143h: 99 0F A4 0F 41 00 14 31

  • 0x0F99 = 3993 mV
  • 0x0FA4 = 4004 mV
  • 0x0041 = 65

Fazit:
Die ersten 4 Bytes sind sehr wahrscheinlich Spannungswerte in mV. Byte 4/5 enthalten wahrscheinlich Index/Flags zu min/max-Zelle.

3) 181h/182h/183h → vermutlich Temperaturen oder weitere Extremwerte

Beispiel 182h: 12 00 14 00 11 00 1A DA

Als 16-bit little-endian:

• 0x0012 = 18
• 0x0014 = 20
• 0x0011 = 17

Das sieht stark nach:

• T_min = 18 °C
• T_max = 20 °C
• Sensor-ID = 17

Andere Beispiele:

• 181h: 12 00 13 00 03 00 ... → 18 °C / 19 °C / Sensor 3
• 183h: 12 00 13 00 05 00 ... → 18 °C / 19 °C / Sensor 5

Das ist sehr plausibel.

4) 1C1h/1C2h/1C3h → wahrscheinlich Strom / SoC / SoH / Statusbits, aber nicht eindeutig

Beispiel 1C2h: FF FF 08 00 59 58 1A 61

Mögliche Zerlegung:

• 0xFFFF = ungültig / nicht verwendet / signed = -1
• 0x0008 = Status oder Zähler
• 0x59 = 89
• 0x58 = 88

Die beiden Bytes 59 58, 58 58, 56 56 sind auffällig. Das könnte sein:

• SoC / SoH in Prozent
• zwei gleiche oder fast gleiche Kennwerte
• Durchschnitts-/Grenzwerte

Aber: nicht belastbar.

5) 381h/382h/383h → sehr wahrscheinlich Packspannung oder Energie-/Leistungswert

Beispiel:

• 381h: B7 50 ED 00 00 00 10 AF
• 382h: B7 50 ED 00 00 00 0D E3
• 383h: B7 50 ED 00 00 00 0A B0

Die ersten 3 Bytes sind bei allen gleich:

• B7 50 ED

Als 24-bit little-endian:

• 0xED50B7 = 15,552,695 → roh wenig intuitiv
• oder als andere Skalierung / Seriennummer / Kapazität / Energiezähler

Da nur die letzten zwei Bytes variieren, könnte das Frame sein:

• 32-bit Wert + 16-bit Prüfsumme
• oder 48-bit Datenstruktur mit Counter

Ohne mehr Daten nicht sicher dekodierbar.

6) 6C1h/6C2h/6C3h → möglicherweise Float-Wert im IEEE754

Alle drei: C3 E1 10 40 00 00 00 00

Die ersten vier Bytes little-endian gelesen:

• 0x4010E1C3

Das sieht sehr nach IEEE754-Float aus. Ich habe den Wert nicht blind geraten, aber er liegt ungefähr im Bereich 2.x. Das könnte sein:

• Strom in A
• Spannung pro Zelle in V
• Innenwiderstand
• Kalibrierwert

Da für alle drei identisch, könnte es auch ein Konfigurationsparameter sein.

7) 202h, 242h, 282h → sieht nach langen Bitfeldern / Zell-Balancing / Fehlerbitmap aus

• 202h: A1 0F A1 0F A1 0F A1 0F
• 242h: A0 0F A1 0F A1 0F 9F 0F
• 282h: A1 0F A1 0F A0 0F A1 0F

Das sind je vier 16-bit Werte um 3999–4001 mV.
Das könnte sehr gut sein:

• vier Einzelzellspannungen
• also z. B. Zellen 1–4 eines Blocks

Dann wären 242h/282h evtl. weitere Zellgruppen.
Das ist eine der stärksten Hypothesen im ganzen Bild.

Meine beste Arbeits-Hypothese für die Telegramme

Was ich nicht belastbar behaupten würde

Ich würde nicht ohne weitere Daten sagen:

• welches Byte exakt SoC, SoH, Strom, Leistung, Spannung, Fehlercode ist
• ob die letzten 1–2 Bytes eine CRC, ein Rolling Counter oder Timestamp/Alive-Counter sind
• ob die IDs proprietär BMZ sind oder nur auf einer Drittgeräte-Schnittstelle gespiegelt werden

Dafür bräuchte ich mehr als einen Screenshot.

Was du mir geben müsstest, damit ich es sauber dekodiere

Am besten eines davon:

1. Rohlog als Text
   • z. B. aus PCAN-View exportiert (.trc, .txt, .asc)
2. Messung bei bekannten Zustandsänderungen
   • Laden EIN/AUS
   • Entladen EIN/AUS
   • SoC bekannt
   • Packspannung bekannt
   • Temperaturen bekannt
3. Längerer Mitschnitt
   • mindestens 30–60 Sekunden
4. Falls vorhanden:
   • DBC
   • BMZ-Dokumentation
   • Wechselrichter-/BMS-Protokollbeschreibung

Dann kann ich dir typischerweise:

• Signal für Signal mappen,
• Endianness prüfen,
• Skalierung ableiten,
• eine Tabelle aller CAN-IDs erstellen,
• und bei Bedarf sogar eine DBC-Datei daraus bauen.

Vorläufige Dekodierung der sichtbarsten Frames

Wahrscheinlichste Kandidaten

Konkretes Beispiel dekodiert

142h = A0 0F A1 0F 03 00 1A 72

Wenn Little-Endian 16-bit:

• Wert 1: 0x0FA0 = 4000
• Wert 2: 0x0FA1 = 4001
• Wert 3: 0x0003 = 3

Plausibel:

• minimale Zellspannung: 4000 mV
• maximale Zellspannung: 4001 mV
• betroffene Zelle / Gruppe: 3

182h = 12 00 14 00 11 00 1A DA

• 0x0012 = 18
• 0x0014 = 20
• 0x0011 = 17

Plausibel:

• minimale Temperatur: 18 °C
• maximale Temperatur: 20 °C
• Sensor/Index: 17

Kurzfazit

Ja, grob dekodieren kann man das schon.
Belastbar erkennbar sind vor allem:

• Zellspannungswerte um 4.0 V
• Temperaturwerte um 18–20 °C
• zyklische Telegrammgruppen für mehrere Batteriemodule

Nicht belastbar ist aus nur diesem Screenshot:

• vollständige Signalzuordnung aller Bytes
• SoC/SoH/Strom/Leistung/Faultbits im Detail

Wenn du willst

Lade mir den PCAN-Export als .trc, .txt oder .asc hoch, dann mache ich dir daraus:

1. eine ID-für-ID-Dekodiertabelle
2. die wahrscheinlichen Skalierungen
3. auf Wunsch sogar eine erste DBC-Datei.

Alexander schrieb:

Schon mal die Frames durch eine KI gejagt?

Ja habe ich.

Es kommt das ähnliche Ergebnis raus wie bei Karls Q seinem Post.

Leider passt hier z.B. nicht die Modulspannung. Diese müsste bei ca. 56,1V liegen. Diese Spannung hatten die Module als der Trace erstellt wurde.

Hallo,

hat ein bisschen gedauert. Musste mir erst noch ein Adapter etc. bauen um ein BMZ Helios Batteriemodul direkt anzusprechen ohne dass die BMU mit aktiv ist.

Im Anhang habe ich mal die Log-Datei angehangen.

Gruß Jusch

Marius schrieb:

Leider passt hier z.B. nicht die Modulspannung. Diese müsste bei ca. 56,1V liegen.

Die könnte sich aus der Summe der Zellspannungen ergeben. Wie ist dein BMZ Hyperion Batteriespeicher aufgebaut? Falls die Zellen als 14S verschaltet sind, könnte sich der von dir angegebene Wert ergeben - das Aufaddieren überlasse ich dir. Wo ist "hier"?

Kurzes Update:

Ich habe einen Adapter gebaut, womit ich die CAN-Kommunikation von einem Modul aufzeichnen / anschauen kann.

Das Protokoll müsste / ist ähnlich wie CiA 454 (EnergyBus) Battery Device Profile.

Die CAN-ID 201, 241, 281, 2C1 ist die Zellspannung (max. 16 Zellen), Lesart sind jeweils 2 Byte als Little-Endian-Format, in HEX-Zahlenformat. Die Spannung ist in Volt mit drei Nachkommastellen.

Die letzte Zahl der CAN-ID gibt das jeweilige Batteriemodul an, hierbei das Batteriemodul 1.

Die CAN-ID 301 sind die Temperaturfühler des Moduls (max. 8 Stück), verbaut pro Modul sind 6 Stück. Temperatur wird in °C angeben, jedes Byte ist ein Temperaturfühler in HEX-Zahlenformat.

Für weitere CAN-IDs sind auch Informationen vorhanden.

In der CAN-ID 0C1 ist der werden Fehler / Warnungen dargestellt, hierbei ist mir aufgefallen, dass einzelne Batteriemodule sich in dieser ID unterscheiden, bzw. das unterschiedliche Werte drin stehen.

Ein Befehl an 082 Byte 0: 01 = Erzeugt eine Antwort des BMS, eigentlich sollte damit eine Fehlermeldung quittiert werden, nur leider macht das BMS dies nicht.

Vielleicht habt jemand noch eine Idee, wie die Fehler weiter quittiert werden können.

Marius schrieb:

Alexander schrieb:

Schon mal die Frames durch eine KI gejagt?

Ja habe ich.

Es kommt das ähnliche Ergebnis raus wie bei Karls Q seinem Post.

Leider passt hier z.B. nicht die Modulspannung. Diese müsste bei ca. 56,1V liegen. Diese Spannung hatten die Module als der Trace erstellt wurde.

Wenn du die Zellspannung weißt und davon ausgehst, dass die wahrscheinlich irgendwo in den Daten vorkommt, kann man gezielt danach suchen. Man weiß natürlich nicht, wie die codiert ist, aber man kann ja mal verschiedene einfache Möglichkeiten durchprobieren. Ansonsten Traces aufnehmen, auf denen die Werte unterschiedlich sind und dann schauen, ob irgendwo im Trace eine Änderung auftritt, die dazu passen könnte.