Diese Faden richte ich ein, um das Thema Sicherheit bzw. Fehlerfreiheit bzw. Testmethoden dazu diskutieren zu können, ohne dass das in der eigentlichen Diskussion untergeht.
Dazu kann ich ein wenig beitragen, weil ich aus der beruflichen Vergangenheit Berührungspunkte hatte mit dem Thema (Software)-Sicherheit hatte. Vieles davon habe ich bezüglich der Denkmodelle in meine Arbeit einfliessen lassen.
Nur einige Stichworte dazu:
- Schon in den 90ern kam ich mit dem Thema Softwareprüfung in der Luftfahrtindustrie in Kontakt.
- in einem Messgerätekonzept habe ich das Thema Kalibrierung dermassen optimiert, dass in 20 Jahren, in zuletzt 90 Messgeräten nicht einmal eines aus der Kalibrierung gelaufen ist.
(die Geräte machen die Fertigungsendprüfung nach Spezifikation. Wenn ein solches Gerät aus der Kalibrierung läuft, muss unter bestimmten Bedingungen theoretisch die gesamte Produktion seit der vorherigen Kalibrierung zurückgerufen werden. Und DAFÜR wollte ich irgendwie nicht veratwortlich sein... )
- Im Thema Messtechnik habe ich das Konzept der Luftfahrtprüfung geklaut und angepasst.
- Im Thema Software Schnittstellen zwischen Anlagen und/oder Rechnern ebenso.
(Was muss man machen, damit eine neue Software-Schnittstelle zwischen anlagen verschiedener Herstellt nach dem Prinzip zusammenstöpseln - läuft funktioniert?)
- Eine Maschine habe ich als null-Fehler-Maschine geplant. Hat in 10 Jahren nicht ein einziges fehlerhaftes Teil an den Kunden durchgelassen.
Ich weiss das, weil der Kunden jedes Teil einzeln nachmisst. Das wiederum weiss ich, weil nach etwa 3 Jahren nach Inbetriebnahme sich der Kunde mit einer sehr sachlichen und freundlichen Frage an uns wandte: Sie hätten festgestellt, dass seit etwa 6 Monaten der statistische Mittlewert bestimmter elektrischer Messwerte sich um 0,013 % geändert habe. Ob wir irgendeine Erklärung dafür hätten ? das war weit INNERHALB des erlaubten, aber wir haben sie gefunden)
( Ich weiss, dass ein "null fehler" Test das "falsche" Konzept ist. Qualität soll/kann man nicht hineinprüfen, sondern die Fertigung muss die hineinbauen. Wenn die das aber nicht kann, und wenn ich nicht für die Fertigung, sondern für die Anlagen zu Prüfung verantwortlich bin, bleibt das Problem an meinem Schreibtisch hängen)
Soweit, so gut.
Bühne Frei.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Ich möchte versuchen, dem Faden einen Start zu geben.
Kein Streit, sondern Diskussion.
Ein BMS, das in ~99.999 % der Fälle funktioniert, zu entwickeln, ist heute kein wirkliches Kunststück.
Die restlichen ~0.001%, wo mehrere ungünstige Faktoren zusammenkommen sind das Problem.
Ich möchte beiden Aussagen widersprechen.
Zur ersten, die Zahl bedeutet 10 ppm. Was damit gemeint ist, muss man genauer klären: Fehler pro Jahr, pro Einheit, pro erwarteter Lebensdauer oder was weiß ich.
Aber egal, was es ist: 10 ppm ist schon eine Ansage. Was bedeutet, du darfst keine einzige handlötung drin haben. Platinenreparatur geht auch nicht: läuft oder Schrott.
Und es gibt eine erwartete Lebensdauer, die begrenzt ist. Badewannen Kurve.
Die zweite Aussage: ist falsch. Wenn man von der Aufgabe des BMS ausgeht.
Die ist, denn Akku zu schützen, wenn die Verbraucher oder Lader Mist bauen. Und die Wahrscheinlichkeit, dass Beides mit einem BMS defekt zusammenfällt ist undiskutierbar unwahrscheinlich.
Dass die Anlage bei BMS defekt ausfällt, ist bezüglich der Aufgabe des BMS kein Problem: bezüglich des Benutzerwunsches nach einer funktionierenden Anlage schon. Und das sollte man trennen....
Wobei man auch Mal in die Hardware schauen muss: ist der Akku bei Ausfall des BMS
- ausgeschaltet-
- eingeschaltet
- mit Reststrom belastet
usw.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Da ich etwas unsicher bin, welches Interesse es hier an einer detaillierten Diskussion gibt möchte ich mit einigen Fragen meinerseits beginnen:
Was wisst ihr darüber wie euer BMS in folgenden Situationen reagiert bzw. wie das bei eurem BMS umgesetzt ist:
Wie werden die UV, OV, OC, SC Abschaltungen in HW umgesetzt?
- Durch dedizierte Komparatoren?
- Auf Basis von ADC Ergebnissen, die ohne Einwirkungen von SW ausgewertet werden?
- Auf Basis von ADC Ergebnissen, die durch SW ausgewertet werden?
Gibt es HW-technisch Redundanzen?
z.B. Komparatoren und ADCs, so dass es zwei "Datenquellen" gibt auf deren Basis die UV, OV, OC, SC Abschaltungen erfolgen können
Führt die SW Plausibiltätschecks durch?
z.B. Summe der Zellspannungen vs Packspannung,
Spannungsreferenz gegen eine zweite validieren,
kann das BMS seine Messungen mit denen des WR / Ladereglers vergleichen
Was passiert wenn eine Zellspannungsmessleitung unterbrochen wird?
Was passiert wenn der Mikrocontroller sich aufhängt? Gibt es einen Watch Dog?
Was passiert bei eurem BMS wenn das Haupttaktsignal ausfällt?
Wie werden kritische Einstellungen gegen versehentliche Änderungen oder sogar böswillige Manipulation z.B. über ein Funk-Interface geschützt?
Die Einstellungen des BMS sind typischerweise in SRAM oder Flashzellen gespeichert.
Sind diese Einstellungen gegen "kippende Bits" geschützt?
Was basiert wenn der (MOSFET-)Schalter des BMS beschädigt ist, also
a) nicht mehr hochohmig trennt
b) durchlegiert
ist
Was passiert wenn eine Zelle eine deutlich erhöhte Selbstentladung von z.B. 100 mA aufweist, diese Zelle also pro Tag 2.4 Ah an Ladung gegenüber den anderen verliert?
Gibt es dann eine Warnung oder bügelt ein 5 A Balancer das beim täglichen Top-Balancing einfach in 30 min aus?
Was passiert, wenn sich der Übergangswiderstand an einem Zellverbinder deutlich erhöht, z.B. auf 2 mOhm?
Gibt es eine Warnung oder Abschaltung?
Können weiterhin 100 A fließen, also 20 W Verlustleistung entstehen?
Da ich etwas unsicher bin, welches Interesse es hier an einer detaillierten Diskussion gibt möchte ich mit einigen Fragen meinerseits beginnen:
Was wisst ihr darüber wie euer BMS in folgenden Situationen reagiert bzw. wie das bei eurem BMS umgesetzt ist:
Ich könnte wohl keine Frage mit Sicherheit für mein JK-BMS beantworten - ich kann nur Hoffen 😉
Ich werde dir, für die von mir verwendeten kleinen jbd als direkte nachkommen der pedelec, Punkt für Punkt antworten. Aber leider nicht in den nächsten Tagen.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Sind diese Einstellungen gegen "kippende Bits" geschützt?
Da muss ich doch schnell.
Muss man das denn? Ich habe bisher noch keinen solchen Fall gehabt. Die letzten Schaltkreise, mit denen man diesbezüglich experimentieren konnte, waren die 64 kB und 256 kB dynamischen RAMs. Damit kann man ein Strahlenmessgerät bauen. Danach hat man die Gehäuse Materialien verbessert.
Ich hab das danach hier mehr als Thema gesehen. Ist das falsch?
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Ein BMS, das in ~99.999 % der Fälle funktioniert, zu entwickeln, ist heute kein wirkliches Kunststück.
Die restlichen ~0.001%, wo mehrere ungünstige Faktoren zusammenkommen sind das Problem.
Ich möchte beiden Aussagen widersprechen.
Diese Aussagen waren "flapsig" formuliert, wie das halt passiert, wenn man ein komplexes Thema in zwei Sätzen beschreibt.
Die zweite Aussage: ist falsch. Wenn man von der Aufgabe des BMS ausgeht.
Da Carolus und ich uns offensichtlich nicht darauf einigen können, was im Detail zu den Aufgabe eines "idealen" BMS gehört, wird die Diskussion grundsätzlich schwierig sein.
Damit man meine Aussagen zumindest auf innere Konsistenz überprüfen kann, sollte ich also als erstes definieren, was ich von einem "idealen" BMS ( in einer ESS Anwendung ) erwarte:
Ich erwarte ganz schlicht, dass ein "ideales" BMS dafür sorgt, dass mir aufgrund des Verhaltens der Verbraucher und der Energiequellen, die an der Batterie angeschlossen sind, die Batterie nicht "um die Ohren fliegt".
a) Also insbesondere kein Überladen und
b) dass eine Batterie, die Anzeichen für interne Kurzschlüsse zeigt, nicht weiter geladen und vorzugsweise sogar langsam entladen und dann außer Betrieb gesetzt wird.
Unter Anzeichen bzw. Gefahr für interne Kurzschlüsse würde ich auch Tiefentladung ( Korrosion des Kupfer Anoden-Bleches ) und zu hohe Ladeströme bei zu tiefen Temperaturen oder stark gealtertem SEI ( Lithium-Plating) zählen
Darüber hinaus erwarte ich auch, dass das BMS die Batterie im Rahmen der Anforderungen der Anwendnung möglichst schonend behandelt und damit die Nutzungsszeit maximiert, also z.B.
a) Die Zellen nicht unnötig lange bei hohen Spannungen hält,
b) zumindest die Grundfunktion ( wie genaues Coulomb Counting ) dafür zur Verfügung stellt, dass die Batterie in einem SOC-Fenster betrieben werden kann, das im Rahmen des aktuellen Kapazitätsanforderungen möglichst schonend ist
( Dieser zweite Aspekt gehört aber zugegebenerweise nicht direkt zum Thema Sicherheit )
Was ich nicht erwarte:
- Das BMS kann natürlich nicht verhindern, dass ein externer Brand sich auch auf die Batterie ausweitet
- Das BMS hat bei Naturkatastrophen, wie Überflutung, Gebäudeeinsturz durch Erdbeben ... nur begrenzte Chancen etwas auszurichten
-> Also auch ein nach meinem Verständnis "ideales" BMS kann nicht zu 100.0% verhindern, das Batterien "brennen"!
Meiner Überzeugung nach geht einem fatalen Ereignis an einer Batterie ( Brand, Ausgasung schlimmstenfalls mit folgender Explosion ) immer eine Schädigung mindestens einer der Zellen voraus.
Dass eine "gesunde" Zelle von sich aus spontan "in Flammen aufgeht", halte ich für ausgeschlossen.
Anders ausgerückt, eine Zelle, die "in Flammen aufgeht", ist für mich per Definition geschädigt.
Ein "ideales" BMS sollte eine Zellschädigung nach Möglichkeit komplett verhindern und falls das nicht möglich ist ( z.B. Defekt, wie eine Verunreinigung bei der Herstellung ) die Zelle außer Betrieb setzten und in einen sicheren Zustand bringen ( z.B. langsam entladen ).
Ein reales BMS kann nun an verschiedenen Aspekten scheitern:
1.) Das BMS könnte grundsätzlich nicht in der Lage sein den Zelldefekt mit den Messungen, die zur Verfügung stehen ( typ. Spannung, Strom, Temperatur ), zu detektieren.
Niemand wird z.B. ernsthaft fordern wollen, dass ein BMS für jede Zelle eine Röntgenvorrichtung mitbringt.
Die Frage, ob es überhaupt möglich ist jeden Zelldefekt nur mit Spannung-, Strom- und Temperatur-Messung und beliebig komplexer Auswertung zu detektieren, kann ich nicht beantworten.
Senec ist zumindest bei ihren NMC/NCA Packs ( mit vielen direkt parallel geschalteten Zellen ) daran gescheitert.
2.) Die Messungen oder die Auswertungen des BMS sind fehlerhaft oder unzulänglich. Ein vorliegender und grundsätzlich detektierbarer Defekt wird also fälschlicherweise nicht ( früh genug ) als solcher erkannt
3.) Ein Defekt wird zwar erkannt, aber das Abschalten scheitert ( z.B. MOSFET-Schalter stribt mit Kurzschluss )
Mindestens alle paar Monate gibt es Berichte von Bränden oder sogar Explosionen durch/mit ESS-Batteriespeichern.
Da ich dabei praktisch nie etwas von Naturkatastrophen oder externen Bränden, die auf die Batterie übergesprungen sind, lese, und wie gesagt an die spontane Selbstentzündung von gesunden Zellen nicht glaube,
ist ganz offensichtlich das BMS, dessen Existenz ich im überwiegenden Anteil der Fälle schlicht unterstelle, daran gescheitert, einen Zelldefekt früh genug zu detekieren und erfolgreich eine Eskalation zu verhindern.
Wenn wir also einfach mal unterstellen, das von 1000000 Batteriespeichern 10 jedes Jahr "brennen" macht das bei einer angenommenen Einsatzzeit von 10 Jahren 1 von 10000 Speichern, die in ihrer Lebenszeit "brennen".
In 0.01 % der Fälle war nach meiner Definition das BMS also nicht "ideal" <=> "hat nicht funktioniert".
In 99.99 % der Fälle hat das BMS im Speicher während der Lebenszeit offensichtlich keine dramatischen Probleme verursacht <=> "hat funktioniert".
Wenn wir etwas an den Annahmen drehen kommen wir auch auf 0.001% zu 99.999 %
Die ist, denn Akku zu schützen, wenn die Verbraucher oder Lader Mist bauen. Und die Wahrscheinlichkeit, dass Beides mit einem BMS defekt zusammenfällt ist undiskutierbar unwahrscheinlich.
Ich werde jetzt mal kleinlich und beginne damit, dass es für eine Diskussion grundsätzlich nicht förderlich ist, Aspekte als "undiskutierbar" zu bezeichnen.
Wenn ich "undiskutierbar" oder "alternativlos" höre, zucke ich innerlich zusammen.
Mir scheint das große Missverständnis zu sein, dass Carolus unter "nicht funktionieren" nur einen "spontanen" Defekt, wie den Ausfall eines Bauteils auf dem BMS ( also im Sinne von MTBF bzw. FIT ), versteht, während ich darunter genauso verstehe, dass das BMS eine systematische Unzulänglichkeit hat, einen gewissen Zelldefekt früh genug zu detektieren und eine Eskalation zu verhindern.
Nach meiner Definition von "nicht funktioneren des BMS" ist nämlich die Koinzidenz von "nicht funktioneren des BMS" und "ungünstige Faktoren zusammenkommen" nicht nur nicht "undiskutierbar unwahrscheinlich" sondern mit jedem ESS Akkuspeicher, der ohne äußere Einwirkung ( externer Brand, Wasser, ... ) "brennt", ganz objektiv belegt.
Wenn ein BMS es zuläßt, dass eine Batterie in einen Thermal Runaway gelangt, ist mir zunächst völlig egal, ob dies durch ein defektes Bauteil, einen Programmierfehler oder einen Auslegungsfehler verursacht wurde.
Leider kenne ich bis jetzt keinen "Akkubrand" bei dem im Nachhinein rekonstruiert wurde, was im Detail genau passiert ist.
Ich persönlich schätze neben den offensichtlichen Dingen wie Überladen und Tiefentladen, interne Zellkurzschlüsse durch Li-Dendriten als die größte Gefahr ein.
Genau deswegen, ist für mich eine Überwachung der Selbstentladung der Zellen ein so wesentlicher Aspekt bei der Entwicklung meines BMS.
Ein starker aktiver Balancer, der starke Unterschiede in der Selbstentladung der Zellen einfach vor dem Nutzer "versteckt", wäre für mich völlig inakzeptabel.
Und ich werde in meinem Packs nie große Zellen direkt parallel schalten, weil das sowohl die Detektion erschwert als auch das Eskalationpotential erhöht.
Abschließend dazu: Ich möchte niemandem meine Einschätzung aufzwingen. Die Beurteilung dieser Risiken und wie man damit umgeht, sollte jeder für sich durchführen.
Willkommen im Club der BMS Frickler. Die meisten Fragen sind wohl relativ einfach zu beantworten. Die Motivation für ein eigenes BMS ist die, daß alle käuflichen BMS praktisch keine brauchbaren Busprotokolle haben. Das ist vor allem der Marktsituation mit der Kompabilität vieler Wechselrichter geschuldet. Aber ich habe das JK Inverter BMS und das Pylontech MMCB U150.
1) Wesentliche Bauteile die neben den Mosfets richtig ins Geld gehen, sind die Shunts für jeden Mosfet.
2) Üblich ist ein uC Cortex M3 (JK BMS hat einen STM32F103 Clone von Geehy) oder M4 (Pylontech hat einen STM32F4 Clone von Nationtech).
3) Weil die Schnittstellenprotokolle überall fehlkonstruiert sind, braucht man Dipschalter, Master BMS, die Kaskadierung ist begrenzt.
4) Aus 3 resultiert der Verkauf von LV_hubs etwa von Pytes oder Pylontech. Letzterer hat einen Cortex M4 von Texas Instruments mit integrierter MAC & PHY. Das ist praktisch eine integrierte Vorraussetzung für Ethernet bzw. MQTT und / oder Modbus TCP. Leider wird das dort aber nirgends genutzt.
5) Pylontech verwendet einen integrierten Balancer bis 200mA von Analog Devices AD1818, JK hat eigene 1/2Amp Balancer mit Mosfets und Super Cs 2x10Farad@5,4 Volt für die 1 Amp Version
6) Pylontech hat an den einzelnen Mosfets 20 Amp SMD Sicherungen, Darüber hinaus hat Pylontech auch noch SMD Sicherungen mit 4 pins, welche per SW über eine Heizung aktiv und absichtlich ausgelöst werden können (Littlefuse Patent). JK hat an Sicherungen gar nichts und funktioniert auch
7) Beide BMS haben in der Versorgungsleitung einen großformatigen Überspannungsschutz mit PTC welche ab 60Volt zumacht. Dahinter setzt JK auf 100V Elkos und Pylontech auf Varistoren
8) Eine der Schwierigkeiten ist eine genaue Strommessung. Beide BMS verwenden einen externen 16 bit AD Wandler mit differentiellen Eingängen welcher über SPI galvanisch getrennt ist. Dies ermöglicht Messungen in Lade und Entladerichtung unabhängig von der Polarität.
9) Wird ein Mosfet hochohmig, so merkt die Firmware daß der Strom am Shunt nicht passt und stellt den Betrieb mit internem Fehler ab
10) Diffundiert ein Mosfet durch, so merkt die Firmware daß der Strom am Shunt nicht passt und stellt den Betrieb mit internem Fehler ab
Anm: Es sind immer viele N Kanal Mosfets parallel, so daß die Werte auf Plausibilität verglichen werden können.
11) Die Messung der Spannungen erfolgt im JK per SW ohne zusätzliche Komparatoren. Bei Unplausibilitäten (Unterbrechung) wird mit Fehlermeldung abgeschaltet
12) Die Spannungen stehen bei Pylontech seriell isoliert auf I2C zur Verfügung. Siehe Datenblatt Analog Devices
13) Es muß davon ausgegangen werden, daß es mehrere WR, Laderegler und BMS gibt, so daß die Ströme überall anders sind und nicht verglichen werden können
14) Mit Funk bin ich gar nicht glücklich. Wenn BT, dann nur optional zu bestücken
15) Steigt der uC im BMS aus oder liefert auch nur unplausible Werte, so kann dies die übergeordnete Instanz feststellen und den Betrieb einstellen. Das können WR, Ladegeräte, andere BMS, Steuerrechner oder eine Kombination daraus sein. Es gibt hierzu mehrere gute Konzepte (NMEA2000, CanOpen, Sunspec) die in käuflichen BMS aber kaum irgendwo implementiert sind.
16) Den Spannungsabfall an den Zellverbindern könnte man durch zusätzliche AD Messung mit differentiellen Eingängen überwachen, was JK vermutlich aus Kostengründen nicht macht. Der AD1818 misst mit 3 AD Wandlern auf allen Analogmultiplexern gleichzeitig so daß die Resultate verglichen werden können. (Siehe ADOL Kommando)
17) Ein Nachfolger des Analog Device BMS1818 ist der LTC 6813 von Linear Technology welchen Analog Devices zwischenzeitlich aufgekauft hat
Summa Summarum kann sowohl in einem BMS wie auch in der Zellchemie wie auch im Ladegerät jederzeit ein Fehler auftreten. Mit einer Vernüftigen Kommunikation unter allen Beteiligten uCs können aber in der Sicherheit des Gesamtsystems noch einige 9er in der Prozentzahl hinter dem Komma hinzugefügt werden. D.h. ein einfacher Fehler wird auf jeden Fall erkannt und führt zur Abschaltung des Gesamtsystems. Ob das einen Brand verhindern kann ist natürlich eine andere Frage. Momentan sind viele Systeme aber so, daß ein einfacher Fehler aufgrund von mangelhaften Schnitstellenprotokollen meist gar nicht im Gesamtsystem propagiert werden kann und sich dieser dann zu einem Folgefehler weiterentwickeln kann.
Sind diese Einstellungen gegen "kippende Bits" geschützt?
Da muss ich doch schnell.
Muss man das denn? Ich habe bisher noch keinen solchen Fall gehabt. Die letzten Schaltkreise, mit denen man diesbezüglich experimentieren konnte, waren die 64 kB und 256 kB dynamischen RAMs. Damit kann man ein Strahlenmessgerät bauen. Danach hat man die Gehäuse Materialien verbessert.
Ich hab das danach hier mehr als Thema gesehen. Ist das falsch?
Ich arbeite beruflich viel mit FPGAs, die typ. zunächst einmal ein riesiges SRAM-Array ( bis zu mehrere 100 Mbit ) beinhalten .
Da sind "SEUs" (Single Event Upsets) seit Jahrzenten ein im Detail untersuchtes Phänomen.
Die sind unwahrscheinlich aber sicher nicht "undiskutierbar unwahrscheinlich".
Alle aktuellen größeren FPGAs bieten eigentlich die Möglichkeit, dass die Konfiguration in den SRAM Zellen im Hintergrund ständig überprüft werden kann.
Auch wenn man sich z.B. aktuelle STM32 MCUs von ST anschaut, haben die nach meinem Kenntnisstand praktisch alle extra parity bits für den SRAM Bereich.
Wenn es um Functional Safety geht, kommt man da kaum drumherum.
Bezogen auf ein BMS dürfte DRAM praktisch nie von Relevanz sein.
Dominant dürften SRAM und OTP ( one time programmable ), NOR Flash und ROM sein.
Das TI AFE hat z.B. "signature checks" für den OTP, data ROM und instruction ROM Bereich.
Auch bei SPI NOR Flash Bausteine, die heute mehr und mehr als Speicher für MCUs genutzt werden, ist Datenintegrität durchaus ein Thema:
Vielen Dank für deine "Reverse Engineering" Einblicke zu verschiedenen BMS.
Ich hoffe du nimmst mir nicht übel, wenn ich bei einem Punkt den Besserwisser spiele:
- Bei meinem BMS Kosten die Shunts zusammen ~ 0.25 USD, die MOSFETs zusammen > 20 USD. Das ist auch bei anderen nicht dramatisch anders.
Ein paar Anmerkungen und Fragen:
zu
"3) Weil die Schnittstellenprotokolle überall fehlkonstruiert sind, braucht man Dipschalter, Master BMS, die Kaskadierung ist begrenzt."
Ich brauche die nicht. Bei mir läuft die Kommunikation zwischen meinen BMS-Instanzen über den selben CAN-BUS, auf dem auch die Kommunikation mit z.B. Victron Venus stattfindet.
Ein BMS wird manuell zum Master ernannt, und alle anderen BMS am selben Bus ( theoretisch bis zu 16, mangels Möglichkeit aber bis jetzt nur bis 1 Master + 2 Slaves praktisch getestet ) werden automatisch als Slaves adressiert. Keine DIP Switches, keine manuelle Addressvergabe.
Mehr als 16 habe ich nicht vorgesehen, weil ich keine konkret breite Verwendung dafür sehe, und es erfordern würde, dass ich im Master, der die gleiche HW hat wie die Slaves dann "Kontext-Speicher" ( zum Aggregieren ) für bis zu ? Slaves vorsehen müßte.
Gibt es deiner Ansicht nach zwingende Gründe, mehr als ~ 250 kWh Batterien DC zu koppeln, und nicht stattdessen mehrere solcher Gruppen dann AC zu koppeln?
Zu
"7) Beide BMS haben in der Versorgungsleitung einen großformatigen Überspannungsschutz mit PTC welche ab 60Volt zumach"
Bist Du sicher dass dass ein PTC und nicht TVS Dioden sind? kannst Du Photos dazu zeigen?
Zu
"10) Diffundiert ein Mosfet durch, so merkt die Firmware daß der Strom am Shunt nicht passt und stellt den Betrieb mit internem Fehler ab"
Das könnte die Batterie aber nur dann noch schützen, wenn das allen Verbauchern und Energiequellen, die an der Batterie angeschlossen sind, auch mitgeteilt wird und die darauf reagieren. Ansonsten kann das BMS dann nur noch zuschauen bei was auch immer mit der Batterie passiert.
"Anm: Es sind immer viele N Kanal Mosfets parallel, so daß die Werte auf Plausibilität verglichen werden können."
-> aber nur eingeschränkt:
Wenn der MOSFET Schalter hochohmig ist, obwohl er eingeschaltet ist, müßen alle FETs hochohmig ausgefallen sein.
Wenn der MOSFET Schalter durchgängig ist, obwohl er ausgeschaltet ist, muss mindestens ein FET durchlegiert sein.
Mehr kann man so ohne weiteres nicht aussagen, ist halt eine oder-Verknüpfung.
"Momentan sind viele Systeme aber so, daß ein einfacher Fehler aufgrund von mangelhaften Schnitstellenprotokollen meist gar nicht im Gesamtsystem propagiert werden kann und sich dieser dann zu einem Folgefehler weiterentwickeln kann."
Das ist auch meine Befürchtung: Also ein Ignorieren jeglicher Grundprinzipien von Functional Safety.
Das könnte die Batterie aber nur dann noch schützen, wenn das allen Verbauchern und Energiequellen, die an der Batterie angeschlossen sind, auch mitgeteilt wird
Genau aus diesem Grund ist auch eine zuverlässige Kommunikation wichtig. Die Defizite der Protokolle sind besonders auf CAN wo nicht mehr als eine Master Batterie geht. CAN ist aber von der HW her alles Andere als ein Punkt zu Punkt Konzept. Es gibt dazu bewährte Autokonfigurationen für x Teilnehmer auf dem gleichen CAN Bus. Die BMS brauchen bereits einen zweiten CAN Bus für die Slaves und auch die sind dann auf 8 oder 16 begrenzt. Egal wieviele Anwender es gibt die größere Batterien bauen wollen ist das kein gutes Konzept. Das Konzept muß auf dem Bus (Lat Omnibus heisst für Alle) mehr als einen Teilnehmer können. Wenn man dann zwei macht, können es auch n sein.
Das Gefährliche bei den N Kanal Mosfets ist, wenn es einen Kurzschluss von der Masseleitung auf das Gehäuse gibt und dieses auch mit Ubat Minus verbunden ist. Dann kann der Mosfet auch abschalten und er ist auch noch gut, aber der Strom fliesst eben weiter aussenrum am Mosfet vorbei. In solchen Fällen muß eine zweite Instanz abschalten können.
Fotos der JK Platine zum Reverse Engineering im Schwarm folgen noch. Da sieht man auch die PTCs schön drauf. Ist die große stehende gelbe Scheibe am linken Rand. Die blauen Scheiben sind die NTCs. Die braucht man wegen der langen Leitungen die eine ordentliiche Induktivität haben. Bei Unterbrechungen, Schaltvorgängen oder gar Auslösen einer Sicherung gibt das kräftige Spikes welche im BMS aber auf keinen Fall was kaputtmachen dürfen.
Das Gefährliche bei den N Kanal Mosfets ist, wenn es einen Kurzschluss von der Masseleitung auf das Gehäuse gibt und dieses auch mit Ubat Minus verbunden ist. Dann kann der Mosfet auch abschalten und er ist auch noch gut, aber der Strom fliesst eben weiter aussenrum am Mosfet vorbei. In solchen Fällen muß eine zweite Instanz abschalten können.
Das ist aber wieder einmal ein Problem, dass sich nur durch das Abschalten im Minus-Pfad ergibt. Wenn der MOSFEt-Schalter im Plus-Pfad hängt, gibt es das Problem nicht.
Genau aus diesem Grund ist auch eine zuverlässige Kommunikation wichtig. Die Defizite der Protokolle sind besonders auf CAN wo nicht mehr als eine Master Batterie geht.
Kennst Du denn einen WR, der mehr als eine (Master-)Batterie am selben CAN bus unterstützt?
Ich habe bei meinem BMS, die Idee zu mehreren Mastern am selben CAN-Bus sofort verworfen, weil ich kein Gerät kenne, dass das nutzen könnte.
Danke für die Bilder.
Ich muss aber sagen, dass mir nicht ganz klar ist, wie der PTC und die NTCs verschaltet sein sollen, um die genannten Schutzziele zu erreichen.
Als Überspannungschutz kenne ich MOVs ( oft blaue Scheiben), die oft in einer 3er Kombination, also jeweils einer von den Leitungen zu Erde/Gehäuse und einer zwischen den Leitungen, verschaltet werden.
NTCs kenne ich eigentlich nur zur Einschaltstrombegrenzung.
Ganz links oben dürfte auch noch ein GDT ( gas discharge tube ) als weiterer Überspannungschutz sein.
Richtig, das ist eine Funkenstrecke. Halte ich persönlich aber bei DC weniger davon. Einmal ionisiert kann das bei DC nicht mehr gelöscht werden und geht kaputt. Deshalb sind die auch bei WR nur im AC Schutz drin und nicht bei den Strings.
Die PTCs sind ein probates und beliebtes Mittel zum Überspannungsschutz von Niedervolt Elektronik. In Reihe geschaltet lassen sie den normalen Betriebsstrom des uC niederohmig durch. Bei zu hoher Spannung steigt der Strom an. Die Leistung dabei quadratisch was den PTC erhitzt und den Widerstand damit drastisch schnell erhöht. Der Strom wird damit wieder begrenzt so daß nix kaputtgeht. Der Rest wird dann von den Varistoren und Elkos geschluckt.
Von Taco Nauert gibt es Durchgangspiepser mit 9V Batterie und BC547. Der gesamte Durchgangspiepser geht auch beim Anlegen von Netzspannung nicht kaputt. Von jedem Chinesen Multimeter wäre da nur noch ein schwarzer Bollen Plastik übrig. Den PTC siehst du in der Bauanleitung im Schaltbild.
Die Sache mit den WR und den Schnittstellenprotokollen ist leider ein Henne-Ei Problem auf der Marketing Schiene. Vielleicht sind die Käuferschichten hier noch nicht aufgeklärt genug. Es ist kein technisches Problem nachdem es gute und auch öffentliche Konzepte gleich mehrfach auf verschiedensten Schnittstellen gibt. Der Victron Cerbo GX bzw. das Venus (Victron Energy Linux System) ist vielleicht eine Ausnahme. Es unterstützt NMEA2000. Die Bootsleute können ihr Radar von Hersteller X und ihren Windmesser von Hersteller Y einstecken. Es funktioniert dann einfach auf dem gleichen Display wie das BMS und der Webbrowser. Ganz problemlos ohne etwas zu konfigurieren weil das Protokoll eben durchgängig von der physikalischen CAN Schicht bis zur Anwendungsebene der ISO Osi Schichten geht.
Bei USB ist das zwischenzeitlich zumindest in den gebräuchlichen HID und Mass Storage Klassen ebenfalls üblich. Der Spieleentwickler aus USA hat den chinesischen Hersteller des Lenkrads noch nie gesehen. Der Käufer steckt beides aber ahnungslos zusammen und es funktioniert einfach. Genauso muß es bei Batterien und Solarladegeräten bzw. Wechselrichter ebenfalls sein. Es ist dann auch keine Frage mehr ob mehr als ein BMS geht oder ob das irgendjemand braucht. Es ist einfach selbstverständlich dass es funktioniert wenn es jemand einsteckt. Genauso wie wenn man an einem PC zwei USB Tastaturen oder zwei USB Mäuse einsteckt. Sie funktionieren einfach weil das Konzept passt obwohl das die meisten Benutzer gar nicht brauchen.
Mir scheint das große Missverständnis zu sein, dass Carolus unter "nicht funktionieren" nur einen "spontanen" Defekt, wie den Ausfall eines Bauteils auf dem BMS ( also im Sinne von MTBF bzw. FIT ), versteht, während ich darunter genauso verstehe, dass das BMS eine systematische Unzulänglichkeit hat, einen gewissen Zelldefekt früh genug zu detektieren und eine Eskalation zu verhindern.
Das war/ist kein miss Verständnis, sondern eine Unkenntnis über deine Betrachtungsweise deinerseits.
Ich habe die letzten zwei Jahre damit verbracht, Neulingen zu erklären, Dass ein BMS weder dazu gedacht ist, bequemer ein/Ausschalter zu sein, noch dazu, den Ladestrom zu regeln oder abzuschalten, wenn der Akku voll ist. Sondern das das BMS eine Schutzinstanz ist, die den Akku vor Spezifikationsüberschreitung von aussen schützt.
Jetzt gehst du uber dieses urkonzept hinaus und versuchst, den Akku auch vor sich selber zu schützen.
Sorry, wusste ich nicht, hatte ich nicht verstanden. Kann man versuchen, wird schwierig sein. Wenn klappt ist es Nobelpreis verdächtig. Und damit ein Grund, es zu versuchen. Mein Daumendrücken hast du.
Du bist noch viel weiter voraus vor anderen BMS, als ich gedacht habe.hab dich immer noch unterschätzt. Nochmals sorry dafür.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Leider kenne ich bis jetzt keinen "Akkubrand" bei dem im Nachhinein rekonstruiert wurde, was im Detail genau passiert ist
Da erinnere ich mich an einen notstrom Akku, auf einem Hausdach, der komplett hochgegangen ist. Rechenzentrum oder so, was größeres, mehrfach modular aufgebaut. Rundzellen.
In der Untersuchung hat man jede einzelne Zelle auseinandergebaut , bis man zum Schluss die eine mit Schmelzperlen gefunden hat, die den Brand ausgelöst hat.
Das Übergreifen wurde durch unzureichende Abtrennung der Module und blöcke verursacht.
Danach hat man diesbezüglich die Aufbauempfehlungen deutlich verschärft.
Aus der Erinnerung, Quelle kann. Ich nicht mehr nennen.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter