Open Source BMS?

Hallo Zusammen,

ich bin Elektronik- bzw. Messtechnikingeneur und plane in den nächsten zwei Jahren ein Haus zu bauen und dort ca. 26 kWp an PV zu installieren.
Hinsichtlich einer möglichen Speicherlösung finde ich nen selbstbau recht interessant, insbesondere da die reinen Zellkosten inzwischen bei um die 60€/kWh liegen.
Beim Durchrechnen eines solchen Projekts mit nem vernünftigen BMS, fallen die Kosten eines solchen aber eben nicht unerheblich ins Gewicht. Man landet z.B. mit 8 x 52V 16S Modulen (OMG HV :scream: - diese Diskussion bitte an anderer Stelle) Akku Modulen bei kosten von fast 1500€ wenn man das Batrium einsetzen würde.

Ich hab mal grob durchgerechnet, dass man ein Balancer Modul für 16S welches spannungen der Zellen misst (Ziel wäre genauigkeit besser 1mV) und passives Balancing macht für etwa 20-30€ Materialkosten machbar sein sollte. Schön wäre auch die Möglichkeit die Zellinnenwiderstände kontinuierlich zu überwachen, man also (sehr kurzzeitig) nen genauen Balancerstrom anlegen kann und den Spannungsabfall über die Zelle misst.

Was für mich allerdings noch ein Buch mit sieben Siegeln ist, ist die Kommunikation mit dem Wechselrichter. Hier müsste man ja ein bestehendes Protokoll implementiern. Sehr ihr das als realistisch an (Ich glaub zum Pylontech gibts ja n bissle was an Dokumentation)?
Da ich meine Stärken eher auf der Hardware Seite sehe, wäre es natürlich auch cool wenn sich jemand finden würde, der da vielleicht ein bisschen fitter ist. Ich könnte dann auch erst einmal Hardware zum experimentieren bereitstellen.

Ziel wäre es, daraus ein Open Source Projekt zu machen. Was meint ihr dazu?

Für die Kommunikation mit den Wechselrichtern gibt es fertige Lösungen, wie z.B. die Solaranzeige. (Open Source) Die kann auch verschiedene BMS auslesen und darstellen.


Ulrich
Admin der Solaranzeige.de

Hallo Funkboje,

so wie ich es verstanden habe ist Solaranzeige mehr zum Darstellen der Daten. Mir geht es in erster Linie um die Kommunikation über den CAN bus zum WR, der ja die Daten des BMS braucht um den Akku zu Akzeptieren und das Laden zu steuern.


So hätte ich mir die Balancer Endstufe vorgestellt, die eben auch Linear nen Strom aufprägen kann für die Innenwiderstandsmessung (Ohne hier jetzt schon konkrete Mosfets oder OPV ausgesucht zu haben)

Den Strom für das Signal das man treibt kann man dann bei GND Level auch über nen OPV mit erzeugen.
Für den Aufgeprägten Strom hätte ich gesagt reicht eine Genauigkeit von 2-5%

Bauteilkosten sind ca. 30 cent (@1k), je nach verwendeten Mosfets und OPVs, die ersten 5 Euro wären da also schon weg :grimacing:

Das ist realistisch.
Der größe Kostenpunkt bei einem 16s BMS für > 100 A ist typischerweise der MOSFET-Schalter. Hier eine Einschätzung zu meinem BMS.
Das Mess- und Testequipment, um so einen MOSFET-Schalter auf Herz und Nieren testen zu können, kostet allerdings einige 10er-Potenzen mehr als das BMS.

Die elegantere Lösung ist typischerweise den Strom-Ripple des WR zu nutzen.
Das ermöglicht solche Schätzungen der DC-Zell(verbinder)-Widerstände

Wenn einmal die CAN-Kommunikationsschnittstelle auf dem MCU läuft, ist das Pylontech Protokoll ziemlich harmlos. Das sind nur ein paar hundert Zeilen Code. Das Aggegieren von mehreren parallelen Batterien zu einer gemeinsamen virtuellen Batterie, die dann dem WR präsentiert wird, ist aber eine ganz andere Hausnummer.

Chris, wenn du diesen faden in die entwicklungsecke verschoben haben willst.... Du bist da in guter Gesellschaft.

Hi Nimbus,

dein BMS hab ich schon gesehen das sieht schon echt gut aus (sowas in die Richtung fände ich ja nett - ist das open source?)

Dadurch dass ich gerne mehr Richtung HV eignung gehen würde dachte ich beim Schalter an ein fertiges Schütz das dann die anfallende Spannungen <=600-800V sicher abschaltet. Das ist natürlich auch kein Unerheblicher Kostenpunkt aber das wird ja dann nur einmal benötigt, also nicht für jedes 16S Modul. Für die 60V Max ist das mit den Mosfets echt ne elegante Lösung.

Das mit dem Stromripple stimmt natürlich, das macht es dann einfach, jedoch muss man den dann genau kennen, was eine entsprechend gute Strommessung voraussetzt oder? Der Stromripple düfte ja einigermaßen Hochfrequent sein, bei den Zellen ist die Parallelkapazität dabei vermutlich schon signifikant oder?
Perspektivisch daran auch ein Impedanzspektrum aufnhemen zu können, also die Impedanz gegen die Frequent, so ließe sich die parasitäre Zellkapazität und Zellinduktivität vielleicht noch bestimmen.

Das zusammenfassen der einzelnen Zellen hätte ich mir durch ein Zentralmodul vorgestellt, was über eine galvanisch getrennte Schnittstelle die einzelnen BMS der Modulblöcke ausliest. Dieses Zentralmodul hätte dann auch die Strommessung und den Leistungsschalter integriert. Nur dieses Modul würde dann mit dem WR reden, so in etwa ist das ja glaub auch beim Batrium.

@carolus, Ja gerne

Erledigt. Viel spass beim Entwickeln!

Nein, ist es nicht. Wenn du dich aber bei Texas Instruments umschaust und hier dazu liest, findest du alle relevanten Informationen dazu.

Grundsätzlich gibt es schon konzeptionelle Unterschiede zu einem HV Design wo man optimieren kann wenn man sich für HV oder LV entscheidet. Victron hat ja schon vor 3 Jahren ihr modulares HV Konzept auf der Messe ausgestellt wo ich sehr neugierig bin wenn man das mal kaufen kann.

Falls du es noch nicht kennst: Es gibt von Fraunhofer bereits das Fox BMS was schon in der x-ten Version Open Source ist. An vielen Stellen für meine Verhältnisse überdimensioniert. Aber das ist auch ein erkenntisorientiertes und kein Produktorientiertes Projekt welches aus Steuermitteln des BMWK finanziert wurde. Reinschauen lohnt sich allemal.

Und bevor du mit einer FOSS Idee anfängst - für den Fall daß du es noch nicht kennst: Guck dir bitte Kicad an damit andere auch was davon haben.

Es gibt ja Hifi Freaks welche ihr Haus um die Lautsprecher-Boxen drumrum bauen und nicht umgekehrt. Wenn du aber ein Haus baust, kannst du vermutlich trotz zwischenzeitlicher PV-Pflicht deutlich mehr sparen, wenn du den Handwerkern etwas auf die Finger klopfst damit sie nicht allzu viel Murks abliefern oder vielleicht auch gleich das Eine oder Andere selbst machst. Wenn mal das Dach dicht ist und die Fenster drin sind kannst du an die PV denken und erst dann kommt das BMS. Ansonten an Dinge denken wo die Architekten etwas dusselig sind. Kabelschächte und Wege in allen relevanten Richtungen groß genug einplanen. Nicht nur einen belüftbaren Batterieraum, sondern vor allem Plätze zum Abstellen von Kinderwagen, Fahrrädern usw. sind Dinge die eigentlich immer eine Fehlplanung sind weshalb dann die Garagen zu einem all in one Raum herhalten müssen.

Hi,

Ja die Hausplanung läuft selbstverständlich auch nebenher. Wenn der Akku drei Jahre nach dem Haus fertig wäre, wär das auch in Ordnung. Wenn das ganze eben mal zurückstecken muss wäre ok, eben wie gesagt wenn sich ne kleine Community findet. Zur zeit wäre zwar wieder mehr Luft nachdem Hobby-EEG/EKG und meine CNC Fräse fertig sind, aber ganz allein will ich das Insbesondere wegen den o.g. Software-Teilen nicht durchziehen. :see_no_evil: (Da würds dann halt ein Batrium werden o.Ä.)

KiCad kenne ich selbstverständlich, würde mich auch als Power-User bezeichnen :grin:. Im moment in der Ideensammlungs-Phase bietet LTSpice noch ein par mehr features als der KiCad interne Simulator. Falls es wirklicj richtung Hardware geht würd ich dann ein Repo aufsetzen für die KiCad Boards und die Firmware

FoxBMS schau ich mir auf jeden Fall mal an. Mal sehen was meine Kollegen aus Erlangen da so designed haben :grin:

So macht es fast jedes HV-BMS. Theoretisch kann aber auch mit lokalen MOSFET-Schalter pro BMS arbeiten. Hier habe ich einen Teilaspekt davon beschrieben.

Der Stromripple hat typischerweise 100 Hz. Hier mal ein Beispiel.
Wenn Du im Betrieb messen möchtest, muss du diesen Ripple sowieso berücksichtigen, weil er deine Messung überlagert und ansonsten eine massive Störgröße darstellt. Um eine synchronisierte Zellspannungs- und Strommessung kommt man kaum herum.

Das wäre sicher interressant. Bedeutet aber quasi ein LCR-Meter in das BMS einzubauen. Das dürfte teurer und anfwändiger sein, als das eigentliche BMS.

So sieht die übliche Topologie aus.
Bei meinem BMS ernenne ich eines zum Master und das übernimmt dann das Aggregieren. Das kann man grundsätzlich z.B. mit isolierten CAN-Interfaces auch auf seriell verschaltete Batteriepacks ausdehnen. Für größere Lasten ( wie Relais ) sollte man dann aber eine zusätzliche Versorgung aus der Stack-Spannung haben, weil der Master-Pack ansonsten durch die erhöhte Stromaufnahme in Imbalance zu den anderen geraten würde.

Noch ein paar Surftipps um deine HV Motivation zu untersützen:

Es gibt einen Martin Jäger der die Seite Libresolar betreibt. Er blickt ziemlich gut durch und hat auf seiner Seite excellente MPPT Designs als Open Source für die er sogar noch Support macht. Vielleicht kannst du aus dessen Dunstkreis noch jemand für ein HV Design begeistern. Würde ich dann aber auf gitlab machen, denn github gehört zwischenzeitlich Micro$oft.

An die CAN Protokolle würde ich nicht zuviel Erwartungen stellen. Die LV Sachen basieren alle auf dem SMA Sunny Island. Das ist eigentlich eine Punkt zu Punkt Protokoll das gar nix taugt, aber fast alle im LV Bereich mehr oder weniger kompatibel kopieren.

Hier gibt es ein Open Source Projekt welche versucht die CAN Protokolle unter einen Hut zu kriegen

Es gibt dazu auch gleich mehrere Aggregatoren als Open Source. Sie laufen als Skript unter Venus-OS und erlauben auch den gleichzeitigen Anschluss verschiedener Batterien.

Im HV Bereich sind die Protokolle schlecht bis gar nicht dokumentiert. Wenn Victron mit ihren HV Racks endlich auf den Markt geht, wird das vermutlich anders. Sie nutzen in ihren eigenen Produkten NMEA2000. Es gibt aber einige BEV Projekte die dort am Reverse Engineering rumdoktern um mit ihrer Fahrzeugbatterie direktes V2H machen zu können. Wirst du sicher auch selbst finden. Viel Spaß.

Falls du es noch nicht kennst: Es gibt von Fraunhofer bereits das Fox BMS was schon in der x-ten Version Open Source ist. An vielen Stellen für meine Verhältnisse überdimensioniert. Aber das ist auch ein erkenntisorientiertes und kein Produktorientiertes Projekt welches aus Steuermitteln des BMWK finanziert wurde. Reinschauen lohnt sich allemal.

Das Fox BMS hab ich mir mal angesehen, ist ganz interessant, auch weil die die Galvanisch getretten Versorgung quasi selbst machen und nicht über nen Baustein. Ebenfalls die Überwachung der Balancer FETs ist ganz interessant, wobei ich bei dem Design fast die Befürchtung hätte dass die Widerstände gefährdeter sind. Dickes CON ist natürlich der Preis. alle die Optos pro Zelle und der BMS chip für 26 Öcken vermiesen einem n bissle die Laune. Die Genauigkeit ist aber in nem Bereich die ich gut finde

Der Stromripple hat typischerweise 100 Hz. Hier mal ein Beispiel.
Wenn Du im Betrieb messen möchtest, muss du diesen Ripple sowieso berücksichtigen, weil er deine Messung überlagert und ansonsten eine massive Störgröße darstellt. Um eine synchronisierte Zellspannungs- und Strommessung kommt man kaum herum.

Vielen Dank, den mit 100 Hz hatte ich nicht auf dem Schirm aber natürlich, sobald Leistung abgegeben wird, dann ist der intrisischerweise vorhanden. Wird ja doch ne ganz spannende Messaufgabe. Bei dreiphasigen WRs sollte der dann aber wesentlich geringer ausfallen, dafür aber n ganz anderes Frequenzfpektrum aufmachen.
Für die Zellspannungs-Messungen würd ich dann Windowed Sinc FIR Filter in Software vorsehen, die sollten den Ripple gut Dämpfen. Allerdings muss dazu dann natürlich dann entsprechnd lange (Vielleicht ne Sekunde) gesampled werden. Falls man nen künstlichen Strom an die Zelle für die Impedanzmessung anlegt muss man hier dann auch entsprechend lange messen um mit dem Lock-In die Offband-Noise auf den Vielfachen von 50 Hz gut zu unterdrücken. Nutzbar sind dann nur die Frequenzen die dazwischen liegen. Den Ripple vom Schaltwandler im WR muss man dann auch umgehen, das könnte bei Frequenz auch schon analog mit nem AA Filter gefiltert werden, falls man die Impedanzmessungen vielleicht nur bis 5 oder 10 kHz betrieben möche.

Das wäre sicher interressant. Bedeutet aber quasi ein LCR-Meter in das BMS einzubauen. Das dürfte teurer und anfwändiger sein, als das eigentliche BMS.

das LCR Meter ist tatsächlich nur ein Sweep der Impedanzmessung über mehrere Frequenzen. Ich kann das bei so großen Akkus nicht genau sagen, aber für nen 3Ah LiPo hba ich das mal gemessen. Man hat typischerweise ein Plateau im Niederfrequenten was dem Widerstand entspricht, bei Steigender Frequenz kommt dann die parasitäre Kapazität zum tragen und die Impedanz fällt mit 20db/dekade. Irgendwann fängt dann an die Induktivität zu dominiern und die Impedanz steigt wieder mit 20dB/dekade.

So macht es fast jedes HV-BMS. Theoretisch kann aber auch mit lokalen MOSFET-Schalter pro BMS arbeiten. Hier habe ich einen Teilaspekt davon beschrieben.

Die Mosfets müssen aber die komplette Spannung abkönnen oder relativ synchronisiert schalten, korrekt? Sonst würde bei dem Pack dazu erst abschaltet die komplette Packspannung -16S anliegen und das halten die dann durchbrechenden FETs nur äußerst kurz aus, oder?

Es gibt einen Martin Jäger der die Seite Libresolar betreibt. Er blickt ziemlich gut durch und hat auf seiner Seite excellente MPPT Designs als Open Source für die er sogar noch Support macht. Vielleicht kannst du aus dessen Dunstkreis noch jemand für ein HV Design begeistern. Würde ich dann aber auf gitlab machen, denn github gehört zwischenzeitlich Micro$oft.

Ja das klingt interessant, mal sehen ob ich da jemanden kontaktiert bekomme, insbesondere da das mit den Protokollen wie du es beschreibst, schon wieder stark nicht in meinen Neigungsbereich zu fallen scheint :see_no_evil: Vielleicht könnte aber wenn es schon auf Aggregatoren-Seite da überlegungen gibt, auch schon ein gut Dokumentiertes BMS Modul etwas bringen, wo auf seiten der Aggregatoren dann die Kommunikation implementiert wird

In dem verlinkten Beitrag habe ich ja aufgezeigt, dass für den Entladefall die sowieso notwendigen Schutzdioden die Spannung über dem MOSFET-Schalter automatisch begrenzen.
Für den Ladefall benötigt man aber ( wenn man das Verhalten des WR dabei nicht selber definieren kann ) einen zusätzlichen Überbrückungs-Schalter um die Spannung zu begrenzen. Mit einem solchen Schalter wird ein getrennter Pack dann automatisch aus dem Stack genommen und man hat eine gewisse Fehlertoleranz des Gesamtsystems.

Wenn du eine HW mit STM32 hast, kann ich dir das Pylon CAN Protokoll in C dazu machen. CanOpen habe ich schon in 3 verschiedenen 8 bit Assemblern gemacht. Allerdings gibt es auch von Texas ganz interessante Cortex welche den Ethernet PHY komplett drin haben. Wenn man aufs Geld guckt, muß es ja auch nicht gerade einer aus der R-Familie wie bei Fraunhofer sein.

Wenn du eine HW mit STM32 hast, kann ich dir das Pylon CAN Protokoll in C dazu machen. CanOpen habe ich schon in 3 verschiedenen 8 bit Assemblern gemacht. Allerdings gibt es auch von Texas ganz interessante Cortex welche den Ethernet PHY komplett drin haben. Wenn man aufs Geld guckt, muß es ja auch nicht gerade einer aus der R-Familie wie bei Fraunhofer sein.

Ich hab gedacht dass der Zentralteil vermutlich ein Controller mit hardware CAN interface wird. Bin da absolut nicht festgelegt, aber an sich find ich den STM32H725 recht cool. Ansonsten für die Balancer Module hätt ich entweder auch den oder nen CY8C6137BZI-F34 vorgesehen, den kenne ich ziemlich gut und ein par Sicherheitsrelevante sanity checks könnte man da nebenher in Hardware auf einer FPGA ähnlichen Struktur implementiern. Wenn man das mit dem Impedanzspektrum machen will käm einem aber auch die Rechenleistung vom H7 entgegen. Wenn du dir da software vorstellen könntest, gerne!

In dem verlinkten Beitrag habe ich ja aufgezeigt, dass für den Entladefall die sowieso notwendigen Schutzdioden die Spannung über dem MOSFET-Schalter automatisch begrenzen.
Für den Ladefall benötigt man aber ( wenn man das Verhalten des WR dabei nicht selber definieren kann ) einen zusätzlichen Überbrückungs-Schalter um die Spannung zu begrenzen. Mit einem solchen Schalter wird ein getrennter Pack dann automatisch aus dem Stack genommen und man hat eine gewisse Fehlertoleranz des Gesamtsystems.

Das mit der Fehlertoleranz ist natürlich auch interessant, kommt es in der realität oft vor, dass ne Zelle so aussteigt und man den Akku vom WR trennen muss?dann wäre, dass der Akku mit verminderter Kapazität weiterläuft ja evtl durchaus ein feature.

Wenn das BMS mit dem WR kommuniziert, sollte das unter normalen Umständen nie passieren.

Ok dann würde ich nen zentral gesteuerten Disconnect bevorzugen und zwar einen der recht ausfallsicher ist. Und mit Ausfall mein ich dass der Akku nicht getrennt werden weil sich der Master aufgehängt hat o.Ä. deswegen vielleicht eine getrennte Leitung vorsehen die in Reihe alle slaves ankoppelt. Vielleicht sogar mit einer Schaltung die regemäßig Pulse bekommen muss um den Stromfluss in der Reihenschaltung aufrecht zu erhalten. Die pulse werden dann im Mainloop generiert. Sobald also irgendwas schiefläuft bei auch nur einem slave -> disconnect.

@nimbus4 Da du schonmal die Kurvenform des Stromrippkles aufgenommen hast, hast du da auch ne FFT gemacht? Würde gern mal das reale Stromspektrium durch den Akku sehen. Hab das hier mal simuliert (bei 30A Strom aus dem Akku + 3 Ampere pp mit 40kHz vom Schaltripple), aber grad bei sowas spucken einem dann gern andere Effekte mit in die Suppe: