Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
BIG DATA FOR FAULT IDENTIFICATION IN BATTERY SYSTEMS
Document Type and Number:
WIPO Patent Application WO/2022/162060
Kind Code:
A1
Abstract:
A plurality of state data (41, 551-556) which relate to different components (511-516) of a battery system (91-96, 501) are received. A machine-learned algorithm (560, 651, 652, 653) is applied to the plurality of state data (41, 551-556) in order to determine in this way a state indicator (99, 601, 602, 603) which is indicative of a component (511-516) of the multiplicity of components (511-516) that is the original cause of a fault state of the respective battery system (91-96, 501).

Inventors:
ATUKALP DEVIN (DE)
BERG PHILIPP (DE)
KEIL JONAS (DE)
SINGER JAN (DE)
WANISCH MANUEL (DE)
Application Number:
PCT/EP2022/051887
Publication Date:
August 04, 2022
Filing Date:
January 27, 2022
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
TWAICE TECH GMBH (DE)
International Classes:
G01R31/367; G01R31/392; G01R31/396
Domestic Patent References:
WO2020137914A12020-07-02
WO2019127231A12019-07-04
Foreign References:
US20200202643A12020-06-25
CN111157898A2020-05-15
US20170126027A12017-05-04
CN111222584A2020-06-02
CN111090050A2020-05-01
Other References:
SCHMALSTIEG, JOHANNES ET AL.: "A holistic aging model for Li (NiMnCo) 02 based 18650 lithium-ion batteries", JOURNAL OF POWER SOURCES, vol. 257, 2014, pages 325 - 334, XP028636618, DOI: 10.1016/j.jpowsour.2014.02.012
ECKER, MADELEINE ET AL.: "Development of a lifetime prediction model for lithium-ion batteries based on extended accelerated aging test data", JOURNAL OF POWER SOURCES, vol. 215, 2012, pages 248 - 257, XP028433063, DOI: 10.1016/j.jpowsour.2012.05.012
Attorney, Agent or Firm:
NEUSSER, Sebastian (DE)
Download PDF:
Claims:
36

PATENTANSPRÜCHE

1 . Verfahren zum Überwachen (3060) mindestens eines Batteriesystems (91 -96, 501 ), wobei jedes Batteriesystem (91 -96, 501 ) des mindestens einen Batteriesystems (91 -96, 501 ) eine Vielzahl von Komponenten (511 -516) aufweist, wobei die Vielzahl von Komponenten (511-516) zumindest eine Energiespeicher-Komponente (511 ) umfasst, wobei das Verfahren jeweils für jedes des mindestens einen Batteriesystems (91 -96, 501 ) umfasst:

- Empfangen (3070) von mehreren Zustandsdaten (41 , 551 -556), die unterschiedliche Komponenten (511 -516) der Vielzahl von Komponenten (511 -516) des jeweiligen Batteriesystems (91 -96, 501 ) betreffen, und

- Anwenden (3075) eines maschinengelernten Algorithmus (560, 651 , 652, 653) auf die mehreren Zustandsdaten (41 , 551 -556), um derart einen Zustandsindikator (99, 601 , 602, 603) zu bestimmen, der indikativ für eine einen Fehlerzustand des jeweiligen Batteriesystems (91 -96, 501 ) originär verursachende Komponente (511 -516) der Vielzahl von Komponenten (511 -516) ist.

2. Verfahren nach Anspruch 1 , wobei der maschinengelernte Algorithmus (560, 651 , 652, 653) basierend auf ersten Zustandsdaten (41 , 551 -556) der mehreren Zustandsdaten (41 , 551 -556) eine Vorhersage für zweite Zustandsdaten (41 , 551 -556) der mehreren Zustandsdaten (41 , 551 -556) bestimmt, wobei das Verfahren weiterhin umfasst:

- Vergleichen der Vorhersage der zweiten Zustandsdaten (41 , 551-556) mit den zweiten Zustandsdaten (41 , 551-556), die empfangen wurden, um derart den Fehlerzustand bei einer die ersten Zustandsdaten (41 , 551-556) betreffenden ersten Komponente (511 -516) der Vielzahl von Komponenten (511 -516) und/oder einer die zweiten Zustandsdaten (41 , 551 -556) betreffenden zweiten Komponente (511 -516) der Vielzahl von Komponenten (511-516) zu bestimmen.

3. Verfahren nach Anspruch 2, wobei das Vergleichen eine Schwellenwertanalyse einer Abweichung zwischen den zweiten Zustandsdaten (41 , 551 -556) und der Vorhersage der zweiten Zustandsdaten (41 , 551-556) umfasst, 37 wobei in Abhängigkeit eines Ergebnisses der Schwellenwertanalyse der Zustandsindikator (99, 601 , 602, 603) erhalten wird, der indikativ für eine quantitative Schwere des Fehlerzustands ist.

4. Verfahren nach einem der voranstehenden Ansprüche, wobei der maschinengelernte Algorithmus (560, 651 , 652, 653) Anomalien in Korrelationen zwischen den mehreren Zustandsdaten (41 , 551-556) als den Fehlerzustand bestimmt.

5. Verfahren nach einem der voranstehenden Ansprüche, wobei der Zustandsindikator (99, 601 , 602, 603) ferner indikativ für eine quantitative Betriebseinschränkung des Batteriesystems (91-96, 501 ) aufgrund des Fehlerzustands ist.

6. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine Kühlsystem-Komponente (513) zur Kühlung der Energiespeicher-Komponente (511 ) umfassen, wobei die mehreren Zustandsdaten (41 , 551-556) Kühlsystem-Zustandsdaten umfassen, die zumindest eines von einem Strom eines Kühlmittels der Kühlmittel- Komponente (513), einen Druck des Kühlmittels in einem Kühlmittel-Kreislauf oder eine Fluiddichte des Kühlmittels betreffen.

7. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine lastseitige Ausgangs- Komponente (514) umfasst, wobei die mehreren Zustandsdaten (41 , 551-556) Last-Zustandsdaten umfassen, die indikativ für eine Latenzzeit zwischen einer Leistungsbeaufschlagung der Energiespeicher-Komponente (511) und einer Leistungsabgabe über die Ausgangs- Komponente (514) sind.

8. Verfahren nach einem der voranstehenden Ansprüche, wobei die Vielzahl von Komponenten (511-516) eine Gehäuse-Komponente (512) umfasst, wobei die mehreren Zustandsdaten (41 , 551-556) Gehäuse-Zustandsdaten umfassen, die indikativ für Temperatur und/oder Druck und/oder Feuchtigkeit im Gehäuse sind.

9. Verfahren nach einem der voranstehenden Ansprüche, wobei mehrere Batteriesysteme Cloud-basiert überwacht werden.

10. Verfahren nach einem der voranstehenden Ansprüche, wobei der Fehlerzustand die originär verursachende Komponente (511-516) und ein oder mehrere weitere Komponenten der Vielzahl von Komponenten (511- 516) entlang eines Fehler-Propagationspfads betrifft.

11 . Verfahren nach Anspruch 10, wobei der Zustandsindikator indikativ für den Fehler-Propagationspfad ist.

12. Verfahren zum Trainieren (3055) eines maschinengelernten Algorithmus (560, 651 , 652, 653), der basierend auf mehreren Zustandsdaten (41 , 551-556), die unterschiedliche Komponenten (511-516) einer Vielzahl von Komponenten (511-516) eines Batteriesystems (91-96, 501 ) betreffen, einen Zustandsindikator (99, 601 , 602, 603) bestimmt, der indikativ für einen Fehlerzustand des Batteriesystems (91-96, 501) ist, wobei das Verfahren umfasst:

- Erhalten von Trainings-Zustandsdaten, die unterschiedliche Komponenten (511-516) der Vielzahl von Komponenten (511-516) betreffen,

- basierend auf ein oder mehreren vordefinierten Modellen, die einen Betrieb der Vielzahl von Komponenten (511-516) unter Berücksichtigung von Fehlerzuständen simulieren, und ferner basierend auf den Trainings-Zustandsdaten, Ermitteln von weiteren Trainings-Zustandsdaten und zugehörigen Label-Zustandsindikatoren, und

- Trainieren des maschinengelernten Algorithmus (560, 651 , 652, 653) basierend auf den weiteren Trainings-Zustandsdaten und den zugehören Label-Zu- standsindikatoren.

13. Verfahren nach Anspruch 12, wobei die Trainings-Zustandsdaten für eine Vielzahl von Batteriesystemen (91-96, 501 ) erhalten werden, wobei das Verfahren weiterhin umfasst:

- Clustern der Trainings-Zustandsdaten, um Gruppen von Trainings-Zustandsdaten zu bestimmen, und

- Annotieren von Label-Zustandsindikatoren für die Gruppen von Trainings-Zustandsdaten.

14. Verfahren nach Anspruch 12 oder 13, wobei die Trainings-Zustandsdaten für eine Vielzahl von Batteriesystemen erhalten werden, wobei das Verfahren weiterhin umfasst:

- regelbasiertes Filtern und/oder Clustern der Trainings-Zustandsdaten, um Trainings-Zustandsdaten aufzufinden, welche die Fehlerzustände und/oder weitere Fehlerzustände beschreiben.

15. Verfahren nach einem der Ansprüche 12 bis 14, wobei die ein oder mehreren vordefinierten Modelle mehrere Modelle umfassen, wobei mindestens ein erstes Modell der mehreren Modelle den Betrieb individueller Komponenten der Vielzahl Komponenten simuliert, wobei mindestens ein zweites Modell der mehreren Modelle eine Wechselwirkung des Betriebs zwischen mehreren Komponenten der Vielzahl von Komponenten simuliert.

16. Verfahren nach einem der Ansprüche 12 bis 15, wobei die ein oder mehreren vordefinierten Modelle ein oder mehrere Zeitreihen von entsprechenden Messgrößen für die weiteren Trainings-Zustandsdaten ermitteln, wobei die ein oder mehreren Zeitreihen eine Ausbreitung des Fehlerzustands von Komponente zu Komponente der Vielzahl von Komponenten beschreiben.

Description:
Big-Data für Fehlererkennunq in Batteriesystemen

TECHNISCHES GEBIET

Verschiedene Beispiele betreffen die Überwachung eines Batteriesystems mit einer Vielzahl von Komponenten. Gemäß verschiedenen Beispielen wird dazu ein maschinengelernten Algorithmus verwendet, der basierend auf Zustandsdaten, die von mehreren der Vielzahl von Komponenten erhalten werden, einen Zustandsindikator bestimmt, der indikativ für einen Fehlerzustand ist.

HINTERGRUND

Wiederaufladbare Batterien werden in verschiedenen Anwendungen eingesetzt. Beispielsweise werden wiederaufladbare Batterien als Traktions-Batterien in Elektrofahrzeugen verwendet oder auch als stationäre Energiespeicher, etwa um mittels Fotovoltaik gewonnene elektrische Energie in einem Mikrostromnetz zu speichern.

Die wiederaufladbaren Batterien werden typischerweise durch komplexe Batteriesysteme implementiert. Ein Batteriesystem umfasst eine Vielzahl von Komponenten, das heißt die eigentliche Energiespeicher-Komponente in der durch chemische Vorgänge die Speicherung der elektrischen Energie stattfindet, sowie weitere periphere Komponenten, die zum Betreiben der Energiespeicher-Komponente verwendet werden. Zur Überwachung des Betriebs der Energiespeicher-Komponente werden beispielsweise Batteriemanagementsystem (BMS)-Komponenten verwendet. Eine BMS-Kom- ponente ist typischerweise eingerichtet, um bestimmte lokale Eigenschaften der Energiespeicher-Komponente zu überwachen. Typischerweise erfolgt eine entsprechende Überwachung anhand einer Schwellenwertanalyse, das heißt es wird überprüft, ob Zustandsdaten den Wert einer Observablen indizieren, der kleiner oder größer ist, als ein bestimmter vorgegebenen Schwellenwert.

Eine solche Technik weist verschiedene Nachteile auf. Beispielsweise können manche Fehler nicht oder nur in einem fortgeschrittenen Stadium erkannt werden. Außerdem kann es oftmals nur schwer möglich sein, eine Fehlerursache zu ermitteln. KURZE ZUSAMMENFASSUNG DER ERFINDUNG

Es besteht ein Bedarf für verbesserte Techniken, um den Betrieb von Batteriesystemen zu überwachen.

Diese Aufgabe wird gelöst von den Merkmalen der unabhängigen Patentansprüche. Die Merkmale der abhängigen Patentansprüche definieren Ausführungsformen.

Nachfolgend werden Techniken beschrieben, um mittels Techniken, die auch als „Big Data“ bezeichnet werden, zuverlässig den Betrieb von Batteriesystemen zu überwachen. Dazu können Zustandsdaten für mehrere Komponenten einer Vielzahl von Komponenten eines Batteriesystems empfangen werden und basierend auf den Zustandsdaten können dann Fehlerzustände erkannt werden. In den verschiedenen hierin beschriebenen Beispielen können dazu maschinengelernte Algorithmen eingesetzt werden. Diese können insbesondere basierend auf Trainings-Zustandsdaten trainiert werden, die von einem Ensemble von Batteriesystemen erhalten werden. Dadurch können auch seltene Fehlerzustände erkannt werden. Durch die vielen verfügbaren und verwendeten Daten können solche Techniken auch als „big data“- Techniken bezeichnet werden.

Ein Verfahren zum Überwachen mindestens einen Batteriesystems wird beschrieben. Jedes Batteriesystem des mindestens einen Batteriesystems kann dabei eine Vielzahl von Komponenten aufweisen. Die Vielzahl von Komponenten umfasst dabei zumindest eine Energiespeicher-Komponente.

Das Verfahren kann jeweils für jedes des mindestens einen Batteriesystems umfassen: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen; und ferner Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten, um derart einen Zustandsindikator zu bestimmen, der indikativ für den Fehlerzustand des jeweiligen Batteriesystems ist.

Beispielsweise könnte der Zustandsindikator indikativ für eine Komponente der Vielzahl von Komponenten des jeweiligen Batteriesystem sein, die den Fehlerzustand originär verursacht. In den verschiedenen hierin beschriebenen Beispielen können unterschiedliche Typen von Fehlerzuständen erkannt werden. Manche Fehlerzustände können einen Fehler im Betrieb des Batteriesystems beschreiben, der zum Beispiel den ordnungsgemäßen Betrieb ausschließt oder verhindert. Fehlerzustände könnten auch sich anbahnende Fehler beschreiben, zum Beispiel eine Vorstufe von Fehlem. Bei der Vorstufe von Fehler können bestimmte Betriebsparameter des Batteriesystems bereits außerhalb des Normbereichs liegen, wobei aber der Betrieb des Batteriesystems grundsätzlich noch möglich ist, möglicherweise mit eingeschränkten Leistungscharakteristiken.

Fehlerzustände können in den verschiedenen hierin beschriebenen Beispielen ein o- der mehrere Komponenten des Batteriesystems betreffen. Manche Fehlerzustände können sich entlang eines Fehler-Propagationspfads durch das Batteriesystem ausbreiten. Das bedeutet also in anderen Worten, dass mehrere Komponenten der Vielzahl von Komponenten vom Fehlerzustand betroffen sein können und jeweils zum Beispiel im Betrieb eingeschränkt oder nicht funktional sein können. Beispielsweise wäre es denkbar, dass der Zustandsindikator indikativ für diese betroffenen Komponenten des Batteriesystems entlang des Fehler-Propagationspfads ist. Eine Hierarchie zwischen den Komponenten kann angezeigt werden.

Beispielsweise wäre es denkbar, mittels des Zustandsindikators Abhängigkeiten zwischen Fehlem für individuelle Komponenten, die zum Fehlerzustand beitragen, zu indizieren. Wird zum Beispiel mittels des Zustandsindikators eine den Fehlerzustand originär verursachende Komponente indiziert, so könnte ferner indiziert werden, welche mindestens eine Komponente unmittelbar vom fehlerhaften Betrieb der den Fehlerzustand originär verursachenden Komponente betroffen ist (1 . Stufe), welche weitere mindestens eine Komponente durch den fehlerhaften Betrieb der mindestens einen Komponente der ersten Stufe betroffen ist (2. Stufe), usw.

Auf Grundlage von solchen und anderen Informationen, die mittels des Zustandsindikators angezeigt werden, kann zum Beispiel eine geeignete Gegenmaßnahme eingeleitet werden, beispielsweise um zu vermeiden, dass der Fehlerzustand in einer irreversiblen Beschädigung der Batterie resultiert und/oder um im Rahmen eines abgesicherten Zustands eine Restreichweite eines von dem Batteriesystem angetriebenen Elektrofahrzeugs sicherzustellen. Ein Verfahren zum Überwachen mindestens eines Batteriesystems wird bereitgestellt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.

Ein Computerprogramm oder ein Computerprogramm-Produkt oder ein computerlesbares Speichermedium umfasst Programmcode. Der Programmcode kann von einem Prozessor geladen und ausgeführt werden. Dies bewirkt, dass der Prozessor ein Verfahren zum Überwachen mindestens eines Batteriesystems ausführt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.

Eine Vorrichtung umfasst einem Prozessor. Der Prozessor kann Programmcode laden und ausführen. Dies bewirkt, dass der Prozessor ein Verfahren zum Überwachen mindestens eines Batteriesystems ausführt. Jedes Batteriesystem des mindestens einen Batteriesystems weist eine Vielzahl von Komponenten auf. Die Vielzahl von Komponenten umfasst zumindest eine Energiespeicher-Komponente. Das Verfahren umfasst jeweils für jedes des mindestens einen Batteriesystems: Empfangen von mehreren Zustandsdaten, die unterschiedliche Komponenten der Vielzahl von Komponenten des jeweiligen Batteriesystems betreffen, sowie Anwenden eines maschinengelernten Algorithmus auf die mehreren Zustandsdaten. Derart wird ein Zustandsindikator bestimmt, welcher indikativ für eine Komponente der Vielzahl von Komponenten ist, die einen Fehlerzustand des jeweiligen Batteriesystems originär verursacht.

Die oben dargelegten Merkmale und Merkmale, die nachfolgend beschrieben werden, können nicht nur in den entsprechenden explizit dargelegten Kombinationen verwendet werden, sondern auch in weiteren Kombinationen oder isoliert, ohne den Schutzumfang der vorliegenden Erfindung zu verlassen.

KURZE BESCHREIBUNG DER FIGUREN

FIG. 1 illustriert schematisch ein System umfassend einen Server und ein Ensemble von Batteriesystemen gemäß verschiedenen Beispielen.

FIG. 2 illustriert schematisch ein Batteriesystem gemäß verschiedenen Beispielen.

FIG. 3 illustriert schematisch einen Server gemäß verschiedenen Beispielen.

FIG. 4 ist ein Flussdiagramm eines beispielhaften Verfahrens.

FIG. 5 ist ein Flussdiagramm eines beispielhaften Verfahrens.

FIG. 6 illustriert schematisch einen maschinengelernten Algorithmus, der basierend auf mehreren Zustandsdaten einen Zustandsindikator gemäß verschiedenen Beispielen bestimmt.

FIG. 7 illustriert schematisch einen Regression-basierten maschinengelernten Algorithmus gemäß verschiedenen Beispielen.

FIG. 8 illustriert schematisch einen maschinengelernten Algorithmus, der eine Vorhersage für Zustandsdaten gemäß verschiedenen Beispielen bereitstellt.

FIG. 9 illustriert schematisch einen maschinengelernten Algorithmus, der gemäß verschiedenen Beispielen mehrere Zustände eines Batteriesystems klassifiziert.

FIG. 10 ist ein Flussdiagramm eines beispielhaften Verfahrens.

DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSFORMEN Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen näher erläutert werden.

Nachfolgend wird die vorliegende Erfindung anhand bevorzugter Ausführungsformen unter Bezugnahme auf die Zeichnungen näher erläutert. In den Figuren bezeichnen gleiche Bezugszeichen gleiche oder ähnliche Elemente. Die Figuren sind schematische Repräsentationen verschiedener Ausführungsformen der Erfindung. In den Figuren dargestellte Elemente sind nicht notwendigerweise maßstabsgetreu dargestellt. Vielmehr sind die verschiedenen in den Figuren dargestellten Elemente derart wiedergegeben, dass ihre Funktion und genereller Zweck dem Fachmann verständlich werden. In den Figuren dargestellte Verbindungen und Kopplungen zwischen funktionellen Einheiten und Elementen können auch als indirekte Verbindung oder Kopplung implementiert werden. Eine Verbindung oder Kopplung kann drahtgebunden oder drahtlos implementiert sein. Funktionale Einheiten können als Hardware, Software oder eine Kombination aus Hardware und Software implementiert werden.

Verschiedene Beispiele der Erfindung betreffen Überwachung eines Batteriesystems. Das Batteriesystem umfasst eine Vielzahl von Komponenten. Verschiedene Komponenten sind nachfolgend in TAB. 1 aufgeführt, aber es können auch andere oder weitere Komponenten verwendet werden.

TAB. 1 : Verschiedene Komponenten eines Batteriesystems, sowie beispielhafte Fehlerzustände, die originär in der jeweiligen Komponente auftreten können. In den verschiedenen hierin beschriebenen Beispielen ist es möglich, Zustandsdaten betreffend diese und weitere Komponenten eines Betriebssystems zu erhalten. Darauf ba- sierend können dann Fehlerzustände, wie sie obenstehend beschrieben wurden, erkannt werden.

In den verschiedenen Beispielen können von den Komponenten Zustandsdaten erhalten werden. Die Zustandsdaten können, allgemein formuliert, indikativ für den Betrieb der verschiedenen Komponenten sein. Die Zustandsdaten könnten z.B. einen Fehlerzustand oder einen Normalbetrieb indizieren.

Beispielsweise wäre es denkbar, dass die Zustandsdaten Messdaten beinhalten. Die Messdaten können von ein oder mehreren Sensoren einer entsprechenden Komponente erfasst werden. Es könnten zum Beispiel Roh-Messdaten beinhaltet werden, ohne besondere Nachbearbeitung. In verschiedenen Fällen wäre es denkbar, dass Zustandsdaten den Fehlerzustand oder den Normalbetrieb nicht ausdrücklich indizieren. Das bedeutet, dass der Betriebszustand der jeweiligen Komponente eine sogenannte versteckte Variable sein kann, die erst durch Inferenz auf Grundlage der Zustandsdaten ermittelt werden kann. Es wäre aber auch denkbar, dass die Zustandsdaten zwar basierend auf Messdaten bestimmt werden, aber bereits einer Nachbearbeitung unterzogen wurden - z.B. durch ein lokales Logikelement der Batterie, etwa ein Überwachungssystem. So wäre es zum Beispiel denkbar, dass die Zustandsdaten einen Indikator umfassen, der indiziert, ob in der jeweiligen Komponente ein Normalbetrieb oder ein Fehlerzustand festgestellt wird. Der Indikator könnte z.B. ein 1- Bit-Indikator sein, also „1“ für Normalbetrieb und „0“ für Fehlerzustand. Es könnten auch vorgegebene Fehlercodes eines entsprechenden Fehlercode-Wörterbuchs verwendet werden und von den Zustandsdaten indiziert werden; derart kann zwischen verschiedenen Fehlerzuständen unterschieden werden. In allen solchen Fällen könnte der Indikator also einen Fehlerzustand ausdrücklich anzeigen. Der Indikator könnte auch einen Fehler-Propagationspfad indizieren; das heißt indizieren, wie sich ausgehend von einer den Fehlerzustand originär verursachenden Komponente der fehlerhafte Betrieb durch das Batteriesystem ausbreitet. Beispielsweise könnte der Zustandsindikator eine Sequenz von Komponenten angeben, die vom entsprechenden Fehlerzustand erfasst werden, in einer hierarchischen Reihenfolge gemäß dem Fehler-Propagationspfad. Das bedeutet, dass am Anfang der entsprechenden Reihenfolge die Komponente des Batteriesystems stehen kann, welche den Fehlerzustand originär verursacht.

Eine solche Ausbreitung des Fehlerzustands durch die Komponenten des Batteriesystems kann durch das Berücksichtigen der Korrelationen zwischen Zustandsdaten, die für die verschiedenen Komponenten gewonnen werden, ermittelt werden. Beispielsweise könnte das relative zeitliche Verhalten von Merkmalen, die Abnormalitäten beschreiben, dazu verwendet werden, um die Ausbreitung des Fehlerzustands durch die verschiedenen Komponenten des Batteriesystems zu ermitteln. Werden zum Beispiel Abnormalitäten zunächst in einer ersten Komponente, beispielsweise dem Kühlsystem, erkannt, und anschließend in einer zweiten Komponente, beispielsweise den Batteriezellen, so könnte dieser Zeitoffset als charakteristischer Fingerabdruck für eine Ausbreitung des Fehlerzustands vom Kühlsystem zu den Batteriezellen dienen. In den verschiedenen hierin beschriebenen Beispielen ist es möglich, dass die Zustandsdaten einer bestimmten Komponente erst im Zusammenwirken mit Zustandsdaten einer weiteren Komponente einen Rückschluss auf das Vorliegen eines bestimmten Fehlerzustands ermöglichen. Dies kann also in anderen Worten bedeuten, dass die Zustandsdaten der bestimmten Komponente und/oder der weiteren Komponente für sich genommen keine oder nur eine wenig belastbare Inferenz zur Bestimmung des Fehlerzustands ermöglichen; der entsprechende Rückschluss wird erst belastbar, in dem die Kombination der Zustandsdaten beider Komponenten verfügbar ist. Es wird also die Wechselwirkung zwischen den beiden Komponenten ausgenutzt, um einen Fehlerzustand zuverlässig zu erkennen.

So wäre es zum Beispiel denkbar, dass die Zustandsdaten verschiedener Komponenten Weils eine Zeitreihe unterschiedlicher Messgrößen indizieren. Beispielsweise könnten die Zustandsdaten für Batteriezellen Messgrößen wie Strom oder Spannung oder Temperatur angeben, jeweils als Funktion der Zeit. Entsprechend könnten die Zustandsdaten für ein Kühlsystem zum Beispiel einen Druck in einer Kühlmittel-Leitung angeben oder eine Temperatur des Kühlmittels an einem Wärmetauscher oder einem Kompressor. Beispielsweise wäre es denkbar, dass Zustandsdaten für ein elektrisches Betriebsnetzwerk Widerstände an bestimmten Widerstands-Messpunkten angeben und/oder Stromflüsse an entsprechenden Messpunkten im Betriebsnetzwerk, jeweils als Funktion der Zeit. Es wäre denkbar, dass Luftdruck oder Temperatur oder Feuchtigkeit im Gehäuse des Batteriesystems als Funktion der Zeit gemessen werden. Um die Vergleichbarkeit der Zustandsdaten, die solche oder andere Zeitreihen beinhalten, zu gewährleisten, ist es denkbar, dass eine Transformation zwischen den unterschiedlichen Zeitreferenzen, in denen die Zeitreihen definiert sind, erfolgt, in eine gemeinsame Zeitreferenz.

Je nach Komponenten-Typ können die Zustandsdaten unterschiedlichen Informationsgehalt aufweisen. Einige beispielhafte Zustandsdaten sind nachfolgend im Zusammenhang mit TAB. 2 beschrieben.

TAB. 2: Verschiedene Beispiele für Zustandsdaten. Die Zustandsdaten können basierend auf Messungen bestimmt werden. Zumindest einige der Zustandsdaten könnten als Zeitreihen erhalten werden, d.h. die Entwicklung einer entsprechenden Messgröße als Funktion der zeit beschreiben. Die Zustandsdaten können Rohdaten beinhalten, die aus der Messung erhalten werden. Die Zustandsdaten könnten aber auch abgeleitete Werte beinhalten. In den verschiedenen hierin beschriebenen Beispielen können Zustandsdaten von unterschiedlichen Komponenten des Batteriesystems empfangen werden und gemeinsam in einem maschinengelernten Algorithmus verarbeitet werden, um erweiterte Informationen betreffend ein oder mehrere Fehlerzustände des Batteriesystems zu erhalten. TAB. 2 beinhaltet nicht alle Beispiele und es wäre in verschiedenen Szenarien denkbar, dass weitere andere Zustandsdaten berücksichtigt werden.

Verschiedene hierin beschriebene Beispiele beruhen auf der Erkenntnis, dass unterschiedliche Zustandsdaten - beispielsweise gemäß TAB. 2 - miteinander korrelieren können, obschon sie zum Beispiel basierend auf unterschiedlichen Messdaten, die unterschiedliche Observablen betreffen, und/oder im Zusammenhang mit unterschiedlichen Komponenten einer Vielzahl von Komponenten eines entsprechenden Batteriesystems bestimmt sind. Durch die Berücksichtigung solcher Korrelationen können Fehlerzustände erkannt werden. Dieser Effekt wird in den verschiedenen hierin beschriebenen Techniken ausgenutzt.

Gemäß verschiedenen Beispielen können Fehlerzustände im Zusammenhang mit den verschiedenen Komponenten des Batteriesystems bestimmt werden. Beispiele für Komponenten und zugehörige Fehlerzustände wurden im Zusammenhang mit TAB. 1 beschrieben.

Dazu können maschinengelernte Algorithmen verwendet werden. Als allgemeine Regel könnten maschinengelernte Algorithmen verwendet werden, die eine Regression oder eine Klassifikation bereitstellen. Es können in den verschiedenen hierin beschriebenen Beispielen unterschiedliche Varianten von maschinengelernten Algorithmen verwendet werden. Einige Varianten sind in TAB. 3 erläutert.

TAB. 3: Verschiedene Beispiele für Implementierungen von maschinengelernten Algorithmen, die gemäß den verschiedenen Beispielen mehrere Zustandsdaten verarbeiten können. Die maschinengelernten Algorithmen können geeignet trainiert werden, um Korrelationen zwischen Zustandsdaten aus unterschiedlichen Komponenten zur Bestimmung von verborgenen Merkmalen zu verwenden. Die verschiedenen Varianten für die Implementierung eines maschinengelernten Algorithmus können dabei im Allgemeinen sowohl als Klassifikator konfiguriert werden, das heißt zum Beispiel erkennen, ob ein oder mehrere bestimmte vorher definierte Fehlerzustände auftreten (vgl. FIG. 9); oder auch zur Regression, etwa um Anomalien zu erkennen (vgl. FIG. 7 oder FIG. 8).

Durch die Verwendung eines maschinengelernten Algorithmus zum Erkennen eines Fehlerzustands kann insbesondere im Vergleich zu herkömmlichen Techniken Überwachung des Betriebs eines Batteriesystems durch ein lokales BMS eine Reihe von Vorteilen erzielt werden. Beispielsweise können mehr Fehler erkannt werden bzw. es können auch vorher unbekannte Fehler erkannt werden, im Rahmen einer Anomalie-

Detektion. In den verschiedenen hierin beschriebenen Beispielen können insbeson- dere Zustandsdaten von mehreren unterschiedlichen Komponenten des Batteriesystems verwendet werden, um den Betrieb des Batteriesystems zu überwachen. Dadurch kann es möglich sein, den Fehlerzustand umfassender zu erkennen. Beispielsweise wäre es möglich, auch Fehlerzustände in peripheren Komponenten zu erkennen. Die Ausbreitung von Fehlern zwischen Komponenten des Batteriesystems kann überwacht werden. Ferner wäre es denkbar, dass bereits Fehlerzustände als Vorstufe von tatsächlich auftretenden Fehlern erkannt werden, das heißt sich anbahnende Fehler erkannt werden. Derart könnte prospektiv eine Wartungsmaßnahme eingeleitet werden, oder es könnte ein sicherer Zustand aktiviert werden.

Die verschiedenen hierin beschriebenen Techniken zur Überwachung eines Batteriesystems können außerdem zentral für mehrere Batteriesysteme implementiert werden. Das bedeutet, dass entsprechende Algorithmen zur Überwachung eines Batteriesystems nicht lokal auf einer Komponente des Batteriesystems ausgeführt werden, sondern zentral auf einem Server, beispielsweise basierend auf Zustandsdaten, die von den Batteriesystemen dem Server übertragen werden. Eine Cloud-basierte Überwachung von Batteriesystemen wird ermöglicht.

Dadurch kann es insbesondere möglich sein, dass Fehler in einem Batteriesystem erkannt werden, basierend auf Information, die für ein anderes Batteriesystem gewonnen wird. Derart können Fehler besonders zuverlässig erkannt werden. Es können Zustandsdaten von einem Ensemble von Batteriesystemen berücksichtigt werden.

Außerdem kann es möglich sein, mittels des maschinengelernten Algorithmus einen Zustandsindikator zu bestimmen, der indikativ für eine bestimmte Komponente ist, die einen Fehlerzustand des Batteriesystems originär verursacht. Dies bedeutet, dass der sog. „root cause“ des Fehlerzustands bestimmt werden kann. Solchen Techniken liegt die Überlegung zugrunde, dass es Fehlerzustände geben kann, die mehrere Komponenten des Batteriesystems betreffen bzw. die sich entlang von Feh- ler-Propagationspfaden (kurz Fehlerpfaden) auf mehrere Komponenten des Batteriesystems erstrecken. Das bedeutet, dass ein Fehler in einer bestimmten Komponente auch andere Komponenten des Betriebssystems beeinflussen kann bzw. den allgemeinen Betrieb des Batteriesystems einschränken kann. Durch das Erkennen der den Fehlerzustand originär verursachenden Komponente kann die Schwere des Fehlerzustands zuverlässig eingeschätzt werden und es kann eine zielgerichtete Wartung ermöglicht werden. Mittels konventioneller Techniken der Überwachung des Betriebs durch eine BMS-Komponente kann es oftmals nicht möglich sein oder nur eingeschränkt möglich sein, diese den Fehlerzustand originär verursachende Komponente zu identifizieren. Dies liegt daran, dass der eingeschränkte Betrieb von verschiedenen Komponenten ursächlich durch den Fehler der den Fehlerzustand originär verursachenden Komponente sein kann. Eine genaue Diagnose kann dann oft schwierig sein.

Beispielsweise kann es bei einem originären Fehler im Kühlsystem zu Folgefehlern in ein oder mehreren gekühlten Komponenten, beispielsweise den Batteriezellen selbst, kommen. Beispielsweise wäre es denkbar, dass eine Not-Abschaltung einer Batteriezelle aufgrund einer Leckage in einer Kühlmittel-Zuleitung erfolgt. Zum Beispiel könnten die Zustandsdaten den Druck einer Kühlflüssigkeit in der Kühlmittel-Zuleitung indizieren; durch Erkennen einer Abnormität im Druck der Kühlflüssigkeit im zeitlichen Kontext mit einer Not-Abschaltung könnte so ein entsprechender Rückschluss auf das Kühlsystem als die den Fehlerzustand originär verursachende Komponente gezogen werden.

Es werden auch Techniken zum Trainieren des maschinengelernten Algorithmus beschrieben. Dabei können Trainings-Zustandsdaten verwendet werden, um den maschinengelernten Algorithmus zu trainieren. Als allgemeine Regel können solche Trainings-Zustandsdaten unterschiedliche Zustände als Funktion der zeit und/oder als Funktion der Batteriesystemen-Instanzen eines Ensembles darstellen (englisch „across time“ und „across space“). Das bedeutet also, dass die Trainings-Zustandsdaten unterschiedliche Zustände beschreiben können, die bei einem einzelnen Batteriesystemen zu unterschiedlichen Zeitpunkten auftreten; alternativ oder zusätzlich können auch unterschiedliche Zustände betrachtet werden, die bei verschiedenen Batteriesystemen auftreten.

Verschiedene Beispiele beruhen auf der Erkenntnis, dass es oftmals schwierig sein kann, Trainings-Zustandsdaten zu erhalten, die Fehlerzustände abbilden. Dies kann zum einen daran liegen, dass Fehlerzustände vergleichsweise selten auftreten und es deshalb zum Erhalten von den entsprechenden Trainings-Zustandsdaten zu- gründe liegenden Messdaten notwendig sein kann, ein besonders langes Beobachtungsintervall zu wählen, bis ein entsprechender Fehlerzustand tatsächlich auftritt. Weiterhin kann es oftmals schwierig sein, einen Fehlerzustand zu trennen von einem Normalzustand. Das bedeutet, dass es im Zusammenhang mit dem Annotieren beim Training oftmals schwierig sein kann, solche Trainings-Zustandsdaten in einer Menge von Kandidaten-Trennung-Zustandsdaten aufzufinden, die tatsächlich einen Fehlerzustand beschreiben.

Insbesondere aufgrund der System komplexität bei Berücksichtigung mehrerer Komponenten des Batteriesystems gibt es eine große Anzahl von potentiellen Fehlerzuständen. Dies liegt daran, dass jeweils unterschiedliche einzelne Komponenten im Betrieb eingeschränkt sein können und auch unterschiedliche Fehler-Propagations- pfade von einem originären Fehler durch das Batteriesystem beobachtet werden können. Oftmals ist es nicht oder nur mit unzulässigem Aufwand möglich, Trainings- Zustands Daten für die Vielfalt unterschiedlicher Fehlerzustände messtechnisch zu erfassen.

Um ein solches Problem zu beheben, kann es in verschiedenen Beispielen möglich sein, die Trainings-Zustandsdaten synthetisch zu erstellen. Das bedeutet, dass es unter Verwendung von ein oder mehreren vordefinierten Modellen, die einem Betrieb der Vielzahl von Komponenten des Batteriesystems unter Berücksichtigung von möglichen Fehlerzuständen simulieren (bzw. zu modellieren), möglich sein kann, Trainings-Zustandsdaten und zugehörige Label-Zustandsindikatoren - die indikativ einen entsprechenden synthetisiert Fehlerzustand sind - zu bestimmen. Dann kann darauf basierend ein Training des maschinengelernten Algorithmus stattfinden.

FIG. 1 illustriert Aspekte im Zusammenhang mit einem System 80. Das System 80 umfasst einen Server 81 , der mit einer Datenbank 82 verbunden ist. Außerdem umfasst das System 80 Kommunikationsverbindungen 49 zwischen dem Server 81 und jedem von mehreren Batteriesystemen 91-96. Die Kommunikationsverbindungen 49 könnten z.B. über ein Mobilfunknetzwerk implementiert werden. Beispielsweise können die Batteriesysteme 91-96 ein Ensemble bilden, d.h. , alle vom gleichen Typ sein. Deshalb können die Batteriesysteme 91-96 gemeinsam überwacht werden, d.h. unter Verwendung derselben Algorithmen. In FIG. 1 ist beispielhaft illustriert, dass die Batteriesysteme 91 -96 über die Kommunikationsverbindungen 49 Zustandsdaten 41 an den Server 81 senden können. Beispiele für Zustandsdaten wurden bereits obenstehend in TAB. 2 beschrieben.

Als konkretes Beispiel könnten zum Beispiel Zustandsdaten empfangen werden, die indikativ sind für physikalische Messwerte der BMS-Funktionalität der BMS-Kompo- nente, zum Beispiel Stromfluss in den Batteriezellen der Energiespeicher-Komponente sowie Spannungen in den Batteriezellen. Ferner könnten weitere Zustandsdaten empfangen werden, die indikativ sind für abgeleitete Betriebswerte der Energiespeicher-Komponente, wie sie von der BMS-Funktionalität der BMS-Komponente bereitgestellt werden, etwa der Ladungszustand, der Alterungszustand oder der DC-Wi- derstand.

In FIG. 1 ist auch beispielhaft illustriert, dass der Server 81 über die Kommunikationsverbindungen 49 Steuerdaten 42 an die Batterien 91 -96 senden kann. Mittels der Steuerdaten wäre es möglich, dass der Server 81 auf Fehlerzustände reagiert, die auf Grundlage der Zustandsdaten 41 bestimmt wurden. Beispielsweise wäre es möglich, dass die Steuerdaten 42 eine oder mehrere Betriebsgrenzen für den zukünftigen Betrieb der jeweiligen Batterie 91-96 indizieren. Z.B. könnten die Steuerdaten einen oder mehrere Steuerparameter für ein Thermomanagement der jeweiligen Batterie 91 -96 und/oder ein Lademanagement der jeweiligen Batterie 91 -96 indizieren. Durch Verwendung der Steuerdaten 42 kann der Server 81 also den Betrieb der Batterien 91 -96 beeinflussen bzw. steuern. Dies könnte z.B. basieren auf einem Zustandswert 99, der vom Server 81 für die jeweilige Batterie ermittelt wird.

In FIG. 1 ist für jedes der Batteriesysteme 91 -96 schematisch ein Zustandsindikator 99 illustriert. Der Zustandsindikator 99 kann angeben, ob ein Fehlerzustand im entsprechenden Batteriesystem 91 -96 vorliegt. Der Zustandsindikator 99 könnte zum Beispiel eine Schwere des Fehlerzustands angeben. Der Zustandsindikator 99 könnte auch einen Typ des Fehlerzustands angeben. Beispielsweise wäre es in den verschiedenen hierin beschriebenen Beispielen möglich, dass der Zustandsindikator indikativ für eine den entsprechenden Fehlerzustand originär verursachende Komponente des Batteriesystems 91 -96 ist („root cause“). Nachfolgend werden Techniken beschrieben, wie ein solcher Zustandsindikator 99 für die verschiedenen Batteriesysteme 91 -96 bestimmt werden kann, unter Verwendung eines maschinengelernten Algorithmus. Der maschinengelernte Algorithmus kann auf dem Server 81 ausgeführt werden und kann als Eingabe die Zustandsdaten 41 verwenden, die von den verschiedenen Batteriesystemen 91 -96 empfangen werden.

FIG. 2 illustriert Aspekte im Zusammenhang mit einem Batteriesystem 501. Das Batteriesystem 501 kann jedes der Batteriesysteme 91 -96 aus FIG. 1 implementieren. Das Batteriesystem 501 umfasst eine Vielzahl von Komponenten 511 -516. Insbesondere umfasst das Batteriesystem 501 im dargestellten Beispiel eine Energiespeicher- Komponente 511 , eine Gehäuse-Komponente 512, eine Kühlsystem-Komponente 513, eine Ausgangs-Komponente 514, eine BMS-Komponente 515, sowie eine Steuerungs-Komponente. Diese Konfiguration ist nur ein Beispiel.

Obenstehend wurden bereits verschiedene mögliche Komponenten im Zusammenhang mit der TAB. 1 beschrieben. Verschiedene Batteriesysteme können variieren im Zusammenhang mit der Art und der Anzahl der verwendeten Komponenten. Insoweit ist FIG. 2 lediglich als Beispiel gedacht.

Aus FIG. 2 ist außerdem ersichtlich, dass die verschiedenen Komponenten 511-516 des Batteriesystems 501 jeweilige Zustandsdaten 551-556 bereitstellen. Das bedeutet, dass die Zustandsdaten 551 -556 jeweils die Zustandsdaten 41 aus FIG. 1 implementieren können. Die verschiedenen Zustandsdaten 551 -556 beinhalten jeweils Information, die die jeweilige Komponente 511-516 betrifft. Verschiedene Beispiele für Zustandsdaten 551 -556 wurden bereits obenstehend im Zusammenhang mit TAB. 2 beschrieben.

Zum Beispiel kann die Steuerung-Komponente 516 eine Kommunikationsschnittstelle umfassen, über die die Zustandsdaten 551-556 an einen Server, etwa den Server 81 übertragen werden können. Dazu kann die Kommunikationsverbindung 49 verwendet werden.

FIG. 3 illustriert Aspekte im Zusammenhang mit dem Server 81 . Der Server 81 umfasst einen Prozessor 51 sowie einen Speicher 52. Der Speicher 52 kann ein flüchti- ges Speicherelement und/oder ein nicht-flüchtiges Speicherelement umfassen. Außerdem umfasst der Server 81 auch eine Kommunikationsschnittstelle 53. Der Prozessor 51 kann über die Kommunikationsschnittstelle 53 eine Kommunikationsverbindung 49 mit jeder der Batterien 91-96 und der Datenbank 82 aufbauen.

Z.B. kann Programmcode im Speicher 52 gespeichert sein und vom Prozessor 51 geladen werden. Der Prozessor 51 kann dann den Programmcode ausführen. Das Ausführen des Programmcodes bewirkt, dass der Prozessor 51 einen oder mehrere der folgenden Prozesse ausführt, wie sie im Zusammenhang mit den verschiedenen Beispielen hierin im Detail beschrieben sind: Empfangen von Zustandsdaten 41 , 551 - 556, die verschiedene Komponenten eines Batteriesystems 91 -96, 501 betreffen; Verarbeiten von solchen Zustandsdaten durch Anwenden eines maschinengelernten Algorithmus, um derart einen Zustandsindikator oder mehrere Zustandsindikatoren zu bestimmen; Trainieren eines maschinengelernten Algorithmus; usw.

FIG. 4 ist ein Flussdiagramm eines beispielhaften Verfahrens. Das Verfahren aus FIG. 4 könnte zum Beispiel von einer Datenverarbeitungsanlage wie z.B. einem Server durchgeführt werden, etwa dem Server 81 aus FIG. 3. Das Verfahren der FIG. 4 dient der Überwachung eines Batteriesystems mit mehreren Komponenten. Ein entsprechendes beispielhaftes Batteriesystem wurde im Zusammenhang mit FIG. 2 beschrieben. Die Überwachung erfolgt mittels eines maschinengelernten Algorithmus.

Block 3055 umfasst das Trainieren eines maschinengelernten Algorithmus. Dazu können Trainings-Zustandsdaten sowie zugehörige Label-Zustandsindikatoren verwendet werden, als sogenannte „Ground Truth“. Darauf basierend kann das Training erfolgen. Das Training kann einen numerischen iterativen Optimierungsprozess umfassen, d.h. eine Anpassung der Parameterwerte des maschinengelernten Algorithmus kann so lange erfolgen, bis eine entsprechende Optimierungsfunktion, die in Abhängigkeit eines Unterschieds zwischen dem im jeweiligen Trainingszustand des maschinengelernten Algorithmus ermittelten Zustandsindikator und dem zugehörigen Label-Zustandsindikator definiert ist, einen Extremwert annimmt.

Beim Training können Trainings-Zustandsdaten verwendet werden, die von einem Ensemble von Batteriesystemen erhalten werden, vgl. FIG. 1. Das Training könnte auch eine Validierung umfassen. Das bedeutet, es könnte basierend auf Grundwahrheiten überprüft werden, ob der maschinengelernte Algorithmus eine gewünschte Genauigkeit erzielt oder nicht.

Details zu Training werden später im Zusammenhang mit FIG. 10 näher beschrieben.

Block 3060 betrifft eine Inferenz-Phase, bei der die Überwachung von Batteriesystemen ohne verfügbare „Ground Truth“ erfolgt.

Dabei wird der im vorangehenden Block 3060 trainierte maschinengelernte Algorithmus verwendet. Dabei können Zustandsindikatoren bestimmt werden, die indikativ für Fehlerzustände des Batteriesystems sind. Insbesondere können Zustandsindikatoren bestimmt werden, die indikativ für eine jeweilige Komponente des Batteriesystems sind, welche den entsprechenden Fehlerzustand originär verursacht. Derart kann zwischen unterschiedlichen Typen von Fehlerzuständen unterschieden werden.

Zunächst werden nachfolgend im Zusammenhang mit FIG. 5 Details im Zusammenhang mit der Inferenz-Phase aus Block 3060 beschrieben.

FIG. 5 illustriert ein Flussdiagramm eines beispielhaften Verfahrens. Das Verfahren aus FIG. 5 kann von einer Datenverarbeitungsanlage wie z.B. einem Server durchgeführt werden, etwa dem Server 81 aus FIG. 3. Das Verfahren der FIG. 5 verwendet einen zuvor trainierten maschinengelernten Algorithmus, um ein Batteriesystem zu überwachen. Verschiedene Beispiele für maschinengelernte Algorithmen, die im Zusammenhang mit dem Verfahren der FIG. 5 verwendet werden können, wurden voranstehend in Bezug auf TAB. 3 beschrieben.

Das Verfahren aus FIG. 5 kann zur Überwachung von unterschiedlichen Batteriesystemen eines Ensembles verwendet werden und jeweils für das jeweilige Batteriesystem ausgeführt werden. Beispielsweise könnte jedes der Batteriesysteme 91 -96 aus FIG. 1 mittels des Verfahrens aus FIG. 5 überwacht werden.

Die Überwachung kann Cloud-basiert erfolgen, d.h. z.B. mittels des Servers 81. Dies kann eine parallele Überwachung mehrerer Batteriesysteme ermöglichen.

Zunächst werden in Block 3070 mehrere Zustandsdaten empfangen, die unterschiedliche Komponenten des Batteriesystems betreffen. Zum Beispiel könnten zwei oder mehr der Zustandsdaten 551 -556 des Batteriesystems 501 aus dem Beispiel der FIG. 2 empfangen werden. Beispielhafte Zustandsdaten wurden auch im Zusammenhang mit TAB. 2 beschrieben.

Dann kann in Block 3075 der maschinengelernte Algorithmus auf die mehreren Zustandsdaten angewendet werden, um derart einen Zustandsindikator zu bestimmen. Dieser Zustandsindikator kann ausweisen, ob das Batteriesystem einwandfrei funktioniert oder ob ein Fehler vorliegt. Dies kann im Rahmen einer Anomaliedetektion erfolgen; es können aber auch unterschiedliche Fehlerzustände klassifiziert werden. Beispielsweise wäre es möglich, dass der Zustandsindikator indikativ für eine Komponente ist, die einen erkannten Fehlerzustand originär verursacht.

Ein entsprechender maschinengelernten Algorithmus 560 ist im Zusammenhang mit FIG. 6 schematisch illustriert. Dieser erhält im Beispiel der FIG. 6 die Zustandsdaten 551 und 552 (vergleiche FIG. 2) als Eingabe - könnte aber im Allgemeinen weitere und/oder andere Zustandsdaten als Eingabe empfangen. Basierend auf den Zustandsdaten bestimmend der maschinengelernte Algorithmus 560 dann einen Zustandsindikator 601. Dieser ist indikativ für einen Fehlerzustand. Zum Beispiel könnte - wenn ein Fehlerzustand vorliegt - indiziert werden, ob dieser Fehlerzustand originär in der Energiespeicher-Komponente 511 auftritt, oder aber in der Gehäuse-Komponente 512 (vergleiche FIG. 2).

Dabei gibt es unterschiedliche Möglichkeiten, um mittels des maschinengelernten Algorithmus den Fehlerzustand zu bestimmen. Eine beispielhafte Implementierung ist im Zusammenhang mit FIG. 7 dargestellt.

FIG. 7 illustriert Aspekte im Zusammenhang mit dem maschinengelernten Algorithmus 560. Dort ist der maschinengelernte Algorithmus mittels eines Regressionsalgorithmus 651 implementiert. Derart können z.B. Anomalien in Korrelationen zwischen mehreren Zustandsdaten - hier den Zustandsdaten 551 , 552 - erkannt werden, was einem Fehlerzustand entsprechen kann. Es können kontinuierliche Abweichungen erkannt werden. Die verschiedenen Objektpunkte sind dargestellt und die vorher trainierte Abhängigkeit ist als durchgezogene Linie illustriert. Der Objektpunkt 641 weist eine signifikante Abweichung von der Abhängigkeit zwischen den Zustandsdaten 551 und den Zustandsdaten 552 auf und kann damit als einen Fehlerzustand beschreibend erkannt werden. Zum Beispiel könnten mittels eines Regressionsalgorithmus und durch Überwachung der Abweichung der Objektpunkte von der Abhängigkeit zwischen den verschiedenen Zustandsdaten insbesondere solche Fehlerzustände erkannt werden, die sich anbahnenden Fehlem entsprechen. Beispielsweise könnte ein Abstand des entsprechenden Objektpunkts von der vorbestimmten Abhängigkeit kontinuierlich zunehmen und diese Zunahme überwacht werden, was dem sich anbahnenden Fehler entsprechen kann.

Beispielsweise wäre es denkbar, dass der Abstand zwischen dem Objektpunkt 641 und der Abhängigkeit des Regressionsalgorithmus 651 eine quantitative Betriebseinschränkung des Batteriesystems aufgrund des entsprechenden Fehlerzustands angibt. Derart können auch quantitative Aussagen im Zusammenhang mit dem Fehlerzustand über den Zustandsindikator bereitgestellt werden.

Um aufzulösen, ob die Abweichung des Objektpunkts 641 von der Abhängigkeit des Regressionsalgorithmus 651 durch einen Fehlerzustand verursacht wird, der originär in der Energiespeicher-Komponente auftritt, oder aber durch einen Fehlerzustand verursacht wird, der originär in der Gehäuse-Komponente 512 auftritt, könnten jeweils weitere Korrelationen zwischen den Zustandsdaten 551 und den Zustandsdaten 553-556 bzw. den Zustandsdaten 552 und den Zustandsdaten 553-556 überprüft werden (nicht dargestellt). Zum Beispiel könnte basierend auf eine Korrelation zwischen den Zustandsdaten 553 und den Zustandsdaten 551 überprüft werden, ob sich die Energiespeicher-Komponente 511 erwartungsgemäß in Bezug auf ein Verhalten der Kühlsystem-Komponente 513 verhält, was dann für einen Fehlerzustand sprechen würde, der originär in der Gehäuse-Komponente 512 begründet ist.

Der maschinengelernte Algorithmus 560, also insbesondere die Abhängigkeit des Regressionsalgorithmus 651 , wird basierend auf Trainings-Zustandsdaten angelernt, während der Trainings-Phase aus Block 3055. Diese Trainings-Zustandsdaten können zum Beispiel von einem einzelnen Batteriesystem als Funktion der zeit erhalten werden und entsprechende Varianten, die im üblichen, fehlerfreien Betrieb auftreten abbilden, etwa insbesondere die Alterung von Komponenten wie insbesondere der Energiespeicher-Komponente. Alternativ oder zusätzlich zum Erhalten der Trainings- Zustandsdaten von einem einzelnen Batteriesystem als Funktion der Zeit, wäre es möglich, Trainings-Zustandsdaten von mehreren Batteriesystemen desselben Typs - d.h. eines Ensembles - zu erhalten. Details zum Training werden später im Zusammenhang mit FIG. 10 beschrieben.

Der maschinengelernte Algorithmus aus FIG. 7 - implementiert als Regressionsalgorithmus 651 - ist aber nur ein Beispiel. In anderen Beispielen könnte zum Beispiel auch eine Vorhersage für Zustandsdaten basierend auf anderen Zustandsdaten getroffen werden und dann kann die Vorhersage für die Zustandsdaten verglichen werden mit den tatsächlichen Zustandsdaten für die entsprechende Komponente. Derart können dein Fehlerzustand bei der entsprechenden Komponente erkannt werden. Ein entsprechendes Beispiel wird nachfolgend im Zusammenhang mit FIG. 8 beschrieben.

FIG. 8 illustriert Aspekte im Zusammenhang mit einem maschinengelernten Algorithmus 652, der verwendet werden kann, um ein Batteriesystem oder mehrere Batteriesysteme eines Ensembles zu überwachen. Beispielsweise könnte der maschinengelernte Algorithmus 652 als künstliches neuronales Netzwerk implementiert sein, vergleiche TAB. 3.

Der maschinengelernte Algorithmus kann eine Vorhersage für Zustandsdaten einer Komponente des Batteriesystems machen, basierend auf weiteren Zustandsdaten einer anderen Komponente des Batteriesystems. Es können also wiederum - vergleichbar zum Szenario der FIG. 7 - Korrelationen zwischen den verschiedenen Zustandsdaten unterschiedlicher Komponenten ausgenutzt werden. Wenn die Vorhersage für die Zustandsdaten von den tatsächlichen Zustandsdaten der entsprechenden Komponente abweicht, kann derart ein Fehler erkannt werden. Zum Bestimmen einer entsprechenden Abweichung könnte zum Beispiel eine Schwellenwertanalyse verwendet werden. Je nach Überschreiten oder Unterschreiten eines entsprechenden vordefinierten Schwellenwerts durch eine Differenz der modellierten Zustandsdaten und der tatsächlichen Zustandsdaten als Ergebnis der Schwellenwertanalyse kann der entsprechende Zustandsindikator erhalten werden, der indikativ für eine quantitative Schwere des Fehlerzustands sein kann.

Nachfolgend wird ein konkretes Beispiel gegeben. Des maschinengelernten Algorithmus 652 aus dem Beispiel der FIG. 8 könnte - basierend auf Zustandsdaten 551 , welche die Lade- oder Entladerate der Batteriezellen der Energiespeicher-Kompo- nente 511 betreffen - die Temperatur der Kühlflüssigkeit bei Eintritt in die Energiespeicher-Komponente 511 und/oder bei Austritt aus der Energiespeicher-Komponente 511 bestimmt werden. Es wäre dann möglich, die tatsächlich gemessene Temperatur der Kühlflüssigkeit - indiziert durch die Zustandsdaten 553 - zu vergleichen mit den entsprechenden modellierten Werten, die vom maschinengelernten Algorithmus 652 erhalten werden. Eine Diskrepanz zwischen der Ausgabe des maschinengelernten Algorithmus 652 und den Messdaten, die durch die Zustandsdaten 553 indiziert werden, kann indikativ für einen Fehlerzustand im der Kühlsystem-Komponente 513 sein. Beispiele für entsprechende Fehler wären zum Beispiel Fehler im Steuerschaltkreis für das Kühlsystem, ein Pumpenausfall, Leckage, Auswahl des Kältekreislaufes usw.

Eine solche Bestimmung der Korrelation zwischen den Zustandsdaten 551 , die die Energiespeicher-Komponente 511 betreffen und den Zustandsdaten 553, welche die Kühlsystem-Komponente 513 betreffen, ist nur ein Beispiel. Es könnten auch weitere oder andere Korrelationen bestimmt werden, zum Beispiel zwischen der Energiespeicher-Komponente 511 und der Ausgangs-Komponente 514. Zum Beispiel könnte eine Schaltzeit eines Wechselrichters der Ausgangs-Komponente 513 und/oder ein Isolationswiderstand mittels eines entsprechenden maschinengelernten Algorithmus modelliert werden und mit den entsprechenden Messwerten, die durch die Zustandsdaten 554 indiziert werden, welche die Ausgangs-Komponente 514 betreffen, verglichen werden. Derart können Fehler der Ausgangs-Komponente 514 - etwa Korrosion von Kontakten, abbauen der Dielektrika in den Kabeln, usw. - bestimmt werden.

Durch die Ausgabe des maschinengelernten Modells 652 kann also eine Aussage zum Fehlerfall getroffen werden und ob es zu einem (Total-)Ausfall eines (Subsystems gekommen ist.

Neben einer solchen Erkennung von Anomalien wäre auch eine Klassifikation von Fehlerzuständen denkbar. Ein entsprechendes Beispiel ist im Zusammenhang mit FIG. 9 beschrieben.

FIG. 9 illustriert Aspekte im Zusammenhang mit einem maschinengelernten Algorithmus 653, der verwendet werden kann, um ein Batteriesystem zu überwachen. Beispielsweise könnte der maschinengelernte Algorithmus 653 als künstliches neuronales Netzwerk implementiert sein, vergleiche TAB. 3. Im Beispiel der FIG. 9 verwendet der maschinengelernte Algorithmus 653, als Eingabe, die Zustandsdaten 551 , 553. Es wäre aber möglich, dass der maschinengelernte Algorithmus 653 andere oder weitere Zustandsdaten als Eingabe verwendet. Der maschinengelernte Algorithmus 653 gibt einen Zustandsindikator 603 aus, der angibt - für einen entsprechenden Zeitpunkt - in welchem konkreten Zustand sich eine Komponente, hier die Energiespeicher-Komponente 511 , für die die Zustandsdaten 551 erhalten werden, sowie die Kühlsystem-Komponente 513, für welche die Zustandsdaten 553 erhalten werden, befindet. Beispielhafte Zustände wären zum Beispiel: „Komponente funktioniert“ oder „Komponente defekt“. Es können aber auch differenziertere Zustände beschrieben werden, beispielsweise „Kühlsystem Pumpe defekt“ oder „Kühlmittelleckage“. Es können auch mehrere Fehlerzustände zeitgleich erkannt werden.

Um eine solche Klassifikation von Zuständen inklusive Fehlerzustände zu ermöglichen, können geeignete Trainings-Zustandsdaten verwendet werden, die den Betrieb des Batteriesystems im entsprechenden Fehlerzustand beschreiben, um den maschinengelernten Algorithmus 653 zu trainieren. Entsprechende Beispiele im Zusammenhang mit dem Anlernen von maschinengelernten Algorithmen - wie beispielsweise der maschinengelernten Algorithmus 653 aus dem Beispiel der FIG. 9 - werden nachfolgend im Zusammenhang mit FIG. 10 beschrieben.

FIG. 10 ist ein Flussdiagramm eines Verfahrens gemäß verschiedenen Beispielen. Das Verfahren aus FIG. 10 dient dem Training eines maschinengelernten Algorithmus, etwa einem der Algorithmen 560, 651-653 obenstehend beschrieben. Das Verfahren aus FIG. 10 kann von einer Datenverarbeitungseinrichtung wie zum Beispiel einem Server, beispielsweise dem Server 81 , ausgeführt werden.

Optionale Blöcke sind in FIG. 10 mit gestrichelten Linien dargestellt.

Dabei werden Trainings-Zustandsdaten dazu verwendet, um den maschinengelern- ten Algorithmus zu trainieren. Die Trainings-Zustandsdaten können von einem Batteriesystem empfangen werden, wobei die Zustandsdaten dann unterschiedliche Betriebszustände zu unterschiedlichen Zeitpunkten beschreiben. Die Trainings-Zustandsdaten könnten alternativ oder zusätzlich auch von mehreren Batteriesystemen eines Ensembles (vgl. FIG. 1 ) empfangen werden und derart unterschiedliche Be- triebszustände beschreiben. Derart können typischerweise Varianzen in den Trainings-Zustandsdaten - etwa aufgrund von normaler Alterung - berücksichtigt werden.

In Block 3105 erfolgt optional eine Vorverarbeitung der Trainings-Zustandsdaten. Zum Beispiel könnten regelbasierte Filter eingesetzt werden, um bestimmte Trainings-Zustandsdaten a-priori zu verwerfen. Beispielsweise wäre es denkbar, dass bestimmte Trainings-Zustandsdaten auf offensichtlichen Messfehlern basieren und entsprechend nicht im Training berücksichtigt werden sollten. Es könnte auch eine Vorverarbeitung von in den Zustandsdaten beinhalteten Rohdaten erfolgen, etwa eine Tiefpassfilterung um hochfrequentes Rauschen zu unterdrücken, usw.

Durch eine solche Vorverarbeitung der Trainings-Zustandsdaten können aber nicht nur offensichtliche Messfehler aufgefunden werden, sondern es kann auch möglich sein, Trainings-Zustandsdaten zu erkennen, die einen Fehlerzustand beschreiben. Beispielsweise könnten solche Zustandsdaten bestimmt im Zusammenhang mit dem ordnungsgemäßen Betrieb des Batteriesystems definierte Schranken überschreiten.

In Block 3110 kann dann optional ein sogenanntes Clustern erfolgen. Dazu kann zum Beispiel der sogenannte k-Means-Algorithmus verwendet werden. Derart können Gruppen von Objekten - gebildet durch die mehreren Zustandsdaten, die unterschiedliche Komponenten des Batteriesystems betreffen, aber denselben Betriebszustandes Batteriesystems beschreiben - mit geringer Varianz und/oder ähnlichen Eigenschaften innerhalb des kompletten Datensatzes der Trainings-Zustandsdaten erkannt werden. Das Clustern kann auch ohne a-priori Wissen erfolgen. Es können entsprechende Gruppen definiert werden, die anschließend das Annotieren - das heißt das Vergeben von labeln in Block 3120 - vereinfachen.

Auch durch ein solches Clustern kann es möglich sein, Trainings-Zustandsdaten zu identifizieren, die einen Fehlerzustand beschreiben. Beispielsweise könnten entsprechende Cluster vergleichsweise wenige Objektpunkte beinhalten und/oder einen vergleichsweise großen Abstand zu benachbarten Clustern aufweisen.

Optional kann in Block 3115 das Simulieren von Trainings-Zustandsdaten erfolgen. Dazu können vordefinierte Modelle für die entsprechenden Komponenten und/oder das gesamte Batteriesystem verwendet werden. Beispielhafte Simulationsmodelle wären zum Beispiel ein elektrisch-thermisches Modell, welches die Alterung einer Batterie beschreibt. Weitere Modelle wären zum Beispiel physikalisch-chemische Modelle, welche Prozesse in Batteriezellen der Energiespeicher-Komponente betreffen. Für das Kühlsystem könnten finite Elemente Simulationen verwendet werden, um den Wärmetransport zu simulieren. Numerische Techniken zur Simulation von Stromfluss in Schaltkreisen könnten für die Ausgangs- Komponente verwendet werden. Es könnten auch Blackbox-Modelle verwendet werden.

Beispielsweise können für die unterschiedlichen Komponenten des Batteriesystems unterschiedliche Simulationsmodelle verwendet werden. Es können neben solchen Komponenten-spezifischen Simulationsmodellen auch Simulationsmodelle verwendet werden, welche eine Interaktion des Betriebs unterschiedlicher Komponenten beschreiben. Beispielsweise könnten entsprechende Simulationsmodelle eine Koppelung des Betriebs des Kühlsystems mit dem elektrothermischen Verhalten von Batteriezellen beschreiben. Dies ist nur ein Beispiel. Allgemein formuliert könnte durch solche Simulationsmodelle erreicht werden, dass mittels der Simulation entsprechender Zeitreihen die Ausbreitung von Fehlern von Komponente zu Komponente im Batteriesystem erfasst werden kann. Dadurch können auch komplexe Fehlerzustände simuliert werden, welche eine hierarchische Beeinflussung unterschiedlicher Komponenten des Batteriesystems betreffen (anstatt nur einer individuellen Komponente, die im Betrieb beeinträchtigt ist).

Z.B. ist ein Simulationsmodell bekannt aus: Schmalstieg, Johannes, et al. "A holistic aging model for Li (NiMnCo) O2 based 18650 lithium-ion batteries." Journal of Power Sources 257 (2014): 325-334.

Noch ein Simulationsmodell ist bekannt aus: Ecker, Madeleine, et al. "Development of a lifetime prediction model for lithium-ion batteries based on extended accelerated aging test data." Journal of Power Sources 215 (2012): 248-257.

Die Modelle können unterschiedliche Eigenschaften simulieren. Beispielsweise könnten die Simulationsmodelle eine Alterung von Batteriezellen der Energiespeicher- Komponente simulieren. Typischerweise nimmt nämlich die Kapazität der Energiespeicher-Komponente als Funktion der Betriebsdauer oder der Lade-Zyklen ab. Es wäre alternativ oder zusätzlich auch denkbar, dass die Modelle Fehlerzustände simulieren, d.h. z.B. den Ausfall einer bestimmten Funktionalität einer bestimmten Komponente simulieren. Derart wäre es zum Beispiel denkbar, basierend auf Trainings- Zustandsdaten, die einen fehlerfreien Betriebszustand der entsprechenden Komponente bzw. des Batteriesystems beschreiben, weitere Trainings-Zustandsdaten zu bestimmen, die einen Fehlerzustand beschreiben, unter Verwendung eines entsprechenden Modells. Das bedeutet, dass ausgehend von den Trainings-Zustandsdaten, die einen fehlerfreien Zustand beschreiben, eine Anpassung dieser erfolgen kann, sodass eine Aussage über das Erscheinungsbild der Trainings-Zustandsdaten bei Vorliegen eines Fehlerzustands getroffen werden kann. Derart kann erreicht werden, dass die Trainings-Zustandsdaten spezifisch für den jeweiligen Typ des Batteriesystems sind, andererseits aber auch Fehlerzustände abbilden.

Als Beispiel könnte zum Beispiel ein Modell, welches das Verhalten von Batteriezellen der Energiespeicher-Komponente bei unterschiedlichen Temperaturen beschreibt, als Eingangsparameter eine überhöhte Temperatur erhalten, um derart den Einfluss eines Fehlerzustands „Kühlsystem defekt“ auf die Energiespeicher-Komponente zu modellieren.

Diese Eingabe einer erhöhten Temperatur könnte zum Beispiel basierend auf der Modellierung der Systemtemperatur des Batteriesystems erfolgen. Die Systemtemperatur des Batteriesystems könnte basierend auf einer Annahme einer Masseverteilung der verschiedenen Komponenten mit assoziierten Wärmekapazitäten und Wärmeleitfähigkeit in zwischen den Komponenten erfolgen. Außerdem könnte eine zeitvariable Wärmesenke berücksichtigt werden, wobei die Wärmesenke wiederum in Abhängigkeit von der Funktionstüchtigkeit der Kühlung modelliert werden kann. Zum Beispiel könnte eine Leckage in einer Kühlmittel-Leitung simuliert werden, entsprechend eine Druckabnahme des Kühlmittels, und entsprechend eine zeitlich abnehmende Kühlleistung. Dies kann zu einer Erhöhung der Systemtemperatur führen, welche sich wiederum zeitverzögert auf eine Erhöhung der Temperatur in den verschiedenen Batteriezellen niederschlägt. Diese Erhöhung der Temperatur den verschiedenen Batteriezellen könnte dann mittels eines entsprechenden elektrothermi- schen Modells der Batteriezellen übersetzt werden in eine Änderung der Spannung und/oder des Stromflusses in den Batteriezellen. Derart können also auch Trainings- Zustandsdaten für komplexe Fehlerzustände, die mehrere Komponenten gestaffelt und mit einer Hierarchie betreffen, erzeugt werden.

Aus obenstehendem ist also ersichtlich, dass es zwei Typen von Modellen geben kann, die bei der Simulation berücksichtigt werden. Ein erster Typ kann zur Simulation des Betriebsverhaltens individual der Komponenten des Batteriesystems verwendet werden, also zum Beispiel zur Simulation des elektrothermischen Verhaltens von Batteriezellen usw. Ein zweiter Typ von Simulationsmodellen kann zur Simulation der Kopplung des Betriebsverhaltens zwischen unterschiedlichen Komponenten des Batteriesystems verwendet werden. Das bedeutet, dass zum Beispiel simuliert werden kann, wie sich eine Änderung im Betriebsverhalten in einer ersten Komponente auswirkt auf eine Änderung des Betriebsverhaltens einer zweiten Komponente.

In einer Simulationsarchitektur können solche unterschiedlichen Typen von Modellen verwendet werden, um den gesamten Betrieb des Batteriesystems zu simulieren. Insbesondere können dadurch komplexe Fehlerzustände des Batteriesystems, die nicht nur individuelle Komponenten betreffen, sondern auch die Ausbreitung von Fehlem entlang eines Fehler-Propagationspfads erfassen, simuliert werden. Insbesondere solche komplexen Fehlerzustände sind häufig nicht oder nur eingeschränkt mittels Messungen erfassbar, aufgrund der Vielzahl von potentiellen Fehlerzuständen in und der irreversiblen Natur mancher Fehlerzustände.

Derart könnten Trainings-Zustandsdaten für unterschiedliche Betriebszustände erhalten werden, die unterschiedliche Alterungszustände und/oder unterschiedliche Fehlerzustände des Batteriesystems betreffen. Insbesondere können Korrelationen im Betrieb der unterschiedlichen Komponenten bei Auftreten eines Fehlerzustands in einer der Komponenten simuliert werden. Das bedeutet, dass eine Ausbreitung von Fehlerzuständen im Batteriesystem simuliert werden kann. Solche Korrelationen können dann - wie obenstehend bereits im Zusammenhang mit den verschiedenen Figuren, insbesondere FIG. 9, erläutert - dazu verwendet werden, um die Fehlerzustände zu erkennen.

Dabei ist es nicht in allen Varianten notwendig, die Trainings-Zustandsdaten für Fehlerzustände zu simulieren. Es wäre auch denkbar, dass entsprechende Trainings-Zustandsdaten auf Grundlage von Messungen - entweder in einer Laborumgebung o- der durch Verwendung eines entsprechend großen Ensembles von Batteriesystemen - erhalten werden. Das bedeutet, dass die Trainings-Zustandsdaten die Fehlerzustände nativ beschreiben können. Dabei kann es insbesondere hilfreich sein, solche Abweichungen im Zusammenhang mit dem Clustern in Block 3110 zu erfassen, um die Trainings-Zustandsdaten, welche die Fehlerzustände beschreiben, zuverlässig zu annotieren.

Dann kann in Block 3120 das Annotieren erfolgen. Das bedeutet, dass entsprechende Label an die Trainings-Zustandsdaten vergeben werden, die als Grundlage für das anschließende Training in Block 3120 dienen. Diese Label entsprechen den Trainings-Zustandsindikatoren, die zum Beispiel indikativ für das Auftreten einer Anomalie (vergleiche FIG. 7 oder FIG. 8) oder das Auftreten eines bestimmten Fehlerzustands (vergleiche FIG. 9) für einen Klassifikator werden.

Beispielsweise können Gruppen von Objekten, die durch das Clustern in Block 3110 erhalten wurden, gemeinsam - d.h. mit einer Benutzerinteraktion, die Label für alle entsprechenden gruppierten Trainings-Zustandsdaten vergibt - annotiert werden. D.h. es können für Gruppen von Trainings-Zustandsdaten gemeinsame Label-Zu- standsindikatoren vergeben werden.

In Block 3125 erfolgt dann das eigentliche Trainieren des maschinengelernten Algorithmus. Dazu kann ein Optimierungsverfahren eingesetzt werden, welches in mehreren Iterationen die verschiedenen Parameter des maschinengelernten Algorithmus so lange modifiziert, bis eine entsprechende Verlustfunktion einen maximalen oder minimalen Wert annimmt. Die Verlustfunktion kann einen Unterschied zwischen dem vorher vergebenen Label und der Ausgabe des maschinengelernten Algorithmus mit den Parameterwerten der entsprechenden Iteration beschreiben. Die Anpassung der Parameterwerte kann auf verschiedene Arten und Weisen erfolgen, zum Beispiel durch Rückwärtspropagation usw. Es könnten Entscheidungsbäume, Random-Forest Verfahren oder sog. Gradient-Boosting verwendet werden.

Zusammenfassend wurden voranstehend Techniken beschrieben, um Monitoring und Überwachen von Batteriesystemen und deren Komponenten zu ermöglichen, sowie zum frühzeitigen Erkennen und Detektieren von Fehlem und Zuständen. Dabei erfolgt die Anwendung einer Cloud-basierten Monitoring-Strategie, wobei aber zumindest Teile der Logik auch außerhalb der Cloud ausgeführt werden können. Die zentrale Sammlung der Zustandsdaten („big data“) in der Cloud ermöglicht weitergehende Analysemöglichkeiten, etwa im Vergleich zu klassischer BMS-Funktiona- lität. Während ein BMS zur Überwachung der funktionalen Sicherheit typischerweise nur Über- oder Unterschreiten von Grenzwerten überwachen kann, kann die beschriebene Lösung durch Abgleich der Zustandsdaten unterschiedlicher Komponenten z. B. Anomalien detektieren. Die erforderliche Genauigkeit kann durch eine große Menge an Zustandsdaten, die zur Verfügung steht, erreicht werden. So können Anomalien in einem einzelnen Batteriesystem erkannt werden, wenn zum Beispiel 50 weitere Batteriesysteme eines Ensembles als Referenz dienen können. Je mehr Zustandsdaten bezüglich Vielfalt und Varianz zur Verfügung stehen, desto mehr Fehlerzustände können gelernt und identifiziert werden. Für einfachere Systemfehler können simulierte Daten Abhilfe schaffen.

Ebenso speichert ein typisches BMS keine historischen Daten. Die beschriebene Lösung ermöglicht damit einen Vergleich „across space“ (zwischen verschiedenen Speichern) und „across time“ (zwischen verschiedenen Zeitpunkten).

Durch erhöhte Rechenleistung auf Cloud-Servern können fortschrittliche Algorithmen angewandt werden, wie z.B. Machine-Learning Algorithmen, Daten-Rekonstruktions- algorithmen, Algorithmen zur Berechnung der Informationsentropie, Berechnung und Untersuchung von Korrelationen etc.

Ebenso kann zum Beispiel die Effizienz oder der Wirkungsgrad einzelner Komponenten berechnet werden. Eine schlechtere Effizienz einzelner Komponenten im Vergleich zu den anderen Komponenten ist damit erfassbar, als entsprechender Fehlerzustand, der durch einen quantitativen Zustandsindikator beschrieben wird.

Durch das Erkennen von Komponenten des Betriebssystems, welche einen Fehlerzustand originär verursachen, kann insbesondere eine geeignete Gegenmaßnahme zur Mitigation des Fehlerzustands ausgewählt werden. Dies gilt insbesondere im Vergleich zu Techniken, welche nicht die ursächliche Komponente eines Fehlerzustands erkennen, sondern lediglich die Komponenten aufzählen, die von einem Fehlerzustand betroffen sind, ohne jedoch eine entsprechende Hierarchie, die durch einen Fehler-Propagationspfad beschrieben wird. Selbstverständlich können die Merkmale der vorab beschriebenen Ausführungsformen und Aspekte der Erfindung miteinander kombiniert werden. Insbesondere können die Merkmale nicht nur in den beschriebenen Kombinationen, sondern auch in anderen Kombinationen oder für sich genommen verwendet werden, ohne das Ge- biet der Erfindung zu verlassen.

Beispielsweise wurden voranstehend Techniken beschrieben, bei denen Fehlerzustände erkannt werden. In anderen Varianten könnten aber auch andere Typen von Zuständen erkannt werden. Beispiele wären zum Beispiel Hochlast-Zustände oder Zustände, bei denen eine besonders starke Alterung des Batteriesystems, insbeson- dere von Batteriezellen der Energiespeicher-Komponente auftritt.

Als weiteres Beispiel wurden voranstehend verschiedene Techniken beschrieben, bei denen die Überwachung von Batteriesystemen Server-seitig auf einem Server stattfindet. Es wäre aber denkbar, dass zumindest manche der Logikoperationen, die hierin beschrieben werden, auch lokal auf Datenverarbeitungseinrichtung in den ver- schiedenen Batteriesystemen durchgeführt werden.