DE102015203803A1

DE102015203803A1 - Auslagerung der Parameteridentifikation durch die Verwendung von Cloud Computing-Ressourcen

Info

Publication number: DE102015203803A1
Application number: DE102015203803.3A
Authority: DE
Inventors: Yonghua Li; Johannes Geir Kristinsson; Fazal Urrahman Syed
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-03-05
Filing date: 2015-03-03
Publication date: 2015-09-10
Also published as: CN104890526B; US9533597B2; CN104890526A; US20150251555A1

Abstract

Ein Fahrzeug kann Batteriezellen einer Batterie und mindestens ein Steuergerät aufweisen, welches dafür konfiguriert ist, das Fahrzeug aufgrund einer Zustandsbeobachtung in Zusammenhang mit der Batterie gemäß Batteriemodellparametern für die Zellen, welche von einer fahrzeugexternen Rechenvorrichtung empfangen werden und die eine Rückmeldung auf Messungen in Bezug auf ein Batteriemodell der Zellen sind, welche an die Rechenvorrichtung gesendet werden, zu steuern.

Description

Die Offenbarung betrifft das Auslagern der Parameteridentifikation von sich langsam ändernden Parametern durch die Verwendung von Cloud Computing-Ressourcen.
Moderne Hydrid- und Elektrofahrzeuge verwenden Batteriepakete, um Energie für den Antrieb zu liefern und um rückgespeiste Energie zu speichern. Batteriepakete bestehen üblicherweise aus mehreren einzelnen Batteriezellen, die parallel, in Reihe oder einer Kombination davon geschaltet sein können. Ein Merkmal des Batteriepakets ist der Ladezustand (SOC). Der SOC des Batteriepakets ist ein Maß des Anteils der gesamten Ladung, die in dem Batteriepaket verbleibt und kann analog zu einer Kraftstoffanzeige betrachtet werden. SOC kann wichtig sein zur Bestimmung, wann und wie das Batteriepaket geladen oder entladen werden muss. SOC kann auch wichtig sein, um dem Fahrer Informationen, wie zum Beispiel den Fahrbereich des Fahrzeugs, zu liefern und um das Fahrzeug zu bedienen.
In einer ersten veranschaulichenden Ausführungsform weist ein Fahrzeug eine Antriebsbatterie und ein Steuergerät auf, das dafür konfiguriert ist, das Fahrzeug aufgrund von Modellparametern für die Batterie, die von einer fahrzeugexternen Rechenvorrichtung während eines Fahrzyklus empfangen werden, als Rückmeldung auf die Messungen, die ein Modell der Batterie betreffen, die während des Fahrzyklus von dem Steuergerät an die Rechenvorrichtung geschickt werden, zu steuern.
In einer zweiten veranschaulichenden Ausführungsform weist ein System eine Rechenvorrichtung auf, die dafür konfiguriert ist, von einem Fahrzeug während eines Fahrzyklus des Fahrzeugs über ein Kommunikationsnetzwerk Batteriezellmessungen zu empfangen, die einem Batteriemodell von Batteriezellen des Fahrzeugs entsprechen, und während des Fahrzyklus über das Kommunikationsnetzwerk Batteriemodellparameter für die Zellen als Rückmeldung auf die Messungen an das Fahrzeug zu senden.
In einer dritten veranschaulichenden Ausführungsform umfasst ein Verfahren das Steuern eines Fahrzeugs aufgrund einer Zustandsbeobachtung in Verbindung mit einer Batterie des Fahrzeugs gemäß Batteriemodellparametern für Batteriezellen der Batterie, die von einem Fahrzeugsteuergerät während eines Fahrzyklus des Fahrzeugs von einer fahrzeugexternen Rechenvorrichtung empfangen werden als Rückmeldung auf Messungen, die sich auf ein Batteriemodell der Zellen beziehen, welche von dem Steuergerät während des Fahrzyklus an die Rechenvorrichtung geschickt werden.
1 ist ein Diagramm eines Hybrid-Elektrofahrzeugs, das die Antriebsstrang- und Energiespeicherkomponenten veranschaulicht;
2 ist ein Diagramm einer möglichen Anordnung eines Batteriepakets, die mehrere Zellen umfasst und die von einem Batteriesteuermodul überwacht und gesteuert wird;
3 ist ein Diagramm eines beispielhaften Ersatzschaltbildes einer Batteriezelle;
4 ist ein Diagramm einer Cloud-basierten Architektur zum Auslagern von Aufgaben der Parameteridentifikation von einem Fahrzeug;
5 ist ein Diagramm einer Architektur eines Zustandsbeobachters, die die Cloud-basierte Architektur zum Auslagern von Aufgaben der Parameteridentifikation verwendet;
6 ist ein Diagramm einer Musterbeziehungskurve zwischen der Leerlaufspannung der Batterie und dem Ladezustand der Batterie;
7 ist ein Zeitdiagramm zur Veranschaulichung einer beispielhaften Wechselwirkung zwischen einem Batteriesteuermodul eines Fahrzeugs und einer Cloud Computing-Ressource unter Verwendung eines Cloud-Moduls; und
8–10 sind Diagramme eines Verfahrens zum Auslagern der Aufgaben der Parameteridentifikation von einem Fahrzeug an eine Cloud-basierte Architektur.
Wie erfordert werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können übertrieben oder minimiert vorliegen, um Einzelheiten jeweiliger Komponenten zu zeigen. Daher sollten spezifische strukturelle und funktionale Einzelheiten, die hier offenbart werden, nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einem Fachmann zu lehren, die vorliegende Erfindung verschiedentlich zu verwenden.
Da elektrifizierte Fahrzeuge, wie zum Beispiel batterieelektrische Fahrzeuge (BEVs) und Plug-in-Hybrids (PHEVs), breitere und größere Batterien erhalten, ist die Abschätzung des SOC noch wichtiger geworden. Ein mögliches Verfahren zur Berechnung der Batterie-SOC ist die Amperestunden-Integration, bei der ein Steuergerät eine Integration einer laufenden Messung des Batteriepakets im Zeitablauf durchführt. Es ist jedoch möglich, dass der geschätzte SOC ungenau ist aufgrund von Faktoren, wie zum Beispiel Geräusche in dem laufenden Messsignal, der laufenden Sensorverzerrung, Fehler bei der Bestimmung des ursprünglichen SOC-Wertes und Verfall des Kapazitätswerts aufgrund der Batteriealterung.
Eine genauere SOC-Schätzung kann ein modellbasiertes Verfahren verwenden, wie zum Beispiel die Kalman-Filterung, um den SOC zu bestimmen. Ein modellbasiertes Verfahren erfolgt durch das Festlegen eines Modells einer Batteriezelle und die darauf folgende Vorhersage des internen Zustands der Batteriezelle aufgrund einiger tatsächlicher gemessener Werte. Zu den geschätzten internen Zuständen gehören unter anderem Spannungen, Ströme oder SOC. Bei einer typischen Vorgehensweise wird ein Kalman-Filter auf jede Zelle des Batteriepakets angewandt und diese Zellwerte dann zum Berechnen der allgemeinen Paketeigenschaften verwendet. Hier kann ein Batterieprüfmodul nötig sein, das in der Lage ist, eine Anzahl von Kalman-Filtern, die gleich der Anzahl der in dem Batteriepaket vorhandenen Zellen ist, auszuführen, sowie ein Speicher, der in der Lage ist, Zustandsinformationen für jede der modellierten Zellen zu speichern. Die Anzahl der Zellen in einem Batteriepaket ist unterschiedlich, aber ein modernes Fahrzeugbatteriepaket kann aus 60 bis 100 oder mehr Zellen bestehen.
Ein weiterer modellbasierter Ansatz zur SOC-Schätzung ist unter anderem die Aufteilung von Parameteridentifikation und Zustandsbeobachtung eines Kalman-Filters in getrennte Aufgaben. Ein Parameteridentifikationsmodul kann zum Beispiel Eingaben wie zum Beispiel Spannung, Strom, Temperatur und die zuletzt geschätzte Leerlaufspannung für die Batterie enthalten (hier entweder OCV oder V_OC genannt) und kann diese Eingaben verwenden, um äquivalente Batteriekreismodellparameter zu bestimmen, die an ein OCV-Schätzmodul geliefert werden sollen. Das OCV-Schätzmodul kann die Zustandsbeobachtung gemäß den Modellparametern durchführen, die sie von dem Parameteridentifikationsmodul empfangen hat, um mindestens einen Zustand der Batterie, wie zum Beispiel die Batterie-OCV, zu bewerten. Ein SOC-Berechnungsmodul kann die geschätzte Batterie-OCV von dem OCV-Schätzmodul empfangen und den Batterie-SOC entsprechend der Abbildung von OCV zu SOC bestimmen.
Zwar erzeugen modellbasierte Verfahren genauere Schätzungen der Batterieparameter, jedoch erfordern derartige Ansätze größere Rechner- und Speicherressourcen, wenn die Anzahl der Zellen der Batterie steigt, was wiederum eine aufgerüstete Verarbeitungshardware für das Fahrzeug bei höheren Fahrzeugkosten erfordern kann.
Statt die SOC-Schätzung nur durch das Fahrzeug durchführen zu lassen, können Aspekte der SOC-Berechnung an einen fahrzeugexternen Rechendienst ausgelagert werden. Ein derartiger externer Rechendienst kann einen Cloud-basierten Computing-Server aufweisen, der über eine Netzverbindung von dem Fahrzeug zum Internet erreichbar ist. Durch die Verwendung eines modellbasierten Ansatzes zur SOC-Schätzung, einschließlich der Trennung von Parameteridentifikation und Zustandsbeobachtung kann die Aufgabe der Parameteridentifikation beispielsweise an den externen Dienst ausgelagert werden, wodurch der Rechen- und Zustandsaufwand, der erforderlich ist, um von dem Fahrzeug gewartet zu werden, gesenkt wird. Bei einem derartigen Ansatz kann das Fahrzeug Eingabeinformationen über eine Fahrzeugbatterie (z. B. Spannung, Strom, Temperatur, OCV, usw.) sammeln, die Informationen an den externen Dienst weiterleiten und Modellparameter von dem Dienst empfangen, z. B. äquivalente Parameter von Batteriekreismodellen, die bei der OCV-Schätzung verwendet werden, um die SOC-Berechnung zu vervollständigen.
Da die äquivalenten Parameter von Batteriekreismodellen sich verhältnismäßig langsam ändernde Variablen sind, kann die Latenz bei ihrer Berechnung durch einen Remote-Server eine noch akzeptable Genauigkeit bei der SOC-Schätzung liefern. Da die Zustandsbeobachtung unter Verwendung der äquivalenten Parameter von Batteriekreismodellen verhältnismäßig weniger rechenintensiv ist als die Parameterschätzung, kann außerdem eine verbesserte SOC-Schätzung möglich sein, ohne dass eine aufgerüstete Verarbeitungshardware für das Fahrzeug erforderlich ist.
Zwar wird die Parameterberechnung, die an einen fahrzeugexternen Rechendienst ausgelagert wird, hier mit Bezug auf die Bestimmung des SOC beschrieben, jedoch sollte angemerkt werden, dass die hier beschriebenen Techniken gleichermaßen auf andere Arten von Berechnungen anwendbar sind, bei denen ein Anteil der Parameterberechnung von einem Beobachteranteil einer modellierten Berechnung abgetrennt werden kann, wie zum Beispiel zur Berechnung der Batterieleistung und der Bewertung der Batteriegesundheit und bei einigen anderen Beispielen. Außerdem sind die hier beschriebenen Techniken gleichermaßen anwendbar auf andere Arten von Modellen als die äquivalenten Batteriekreismodelle. Eine Parameteridentifikation eines elektrochemischen Modells oder eines anderen steuerungsorientieren Modells mit Parametern, die in Echtzeit gelernt werden muss, kann ebenso an externe Rechenressourcen ausgelagert werden.
1 stellt ein Hybrid-Elektrofahrzeug 2 dar. Ein typisches Hybrid-Elektrofahrzeug 2 kann einen oder mehrere Elektromotoren 4 aufweisen, die mechanisch mit einem Hybridgetriebe 3 verbunden sind. Außerdem ist das Hybridgetriebe 6 mechanisch mit einem Motor 8 verbunden. Das Hybridgetriebe 6 ist ebenfalls mechanisch mit einer Antriebswelle 10 verbunden, die mechanisch mit den Rädern 12 verbunden ist. Die Elektromotoren 4 können eine Antriebs- und Verzögerungsfähigkeit bieten, wenn der Motor 8 eingeschaltet oder abgeschaltet wird. Die Elektromotoren 4 können auch als Generatoren fungieren und können Kraftstoff einsparen, indem Energie gewonnen wird, die normalerweise als Wärme in dem Reibungsbremssystem verloren wäre. Die Elektromotoren 4 können auch für weniger Schadstoffausstoß sorgen, da das Hybrid-Elektrofahrzeug 2 unter bestimmten Bedingungen elektrisch betrieben werden kann.
Das Batteriepaket 14 speichert Energie, die von den Elektromotoren 4 genutzt werden kann. Ein Fahrzeugbatteriepaket 14 liefert üblicherweise eine hohe DC-Ausgangsspannung. Das Batteriepaket 14 wird elektrisch mit dem Leistungselektronikmodul 16 verbunden. Das Leistungselektronikmodul 16 wird ebenfalls elektrisch mit den Elektromotoren 4 verbunden und bietet die Möglichkeit, Energie bidirektional zwischen dem Batteriepaket 14 und den Elektromotoren 4 zu übertragen. Ein typisches Batteriepaket 14 kann beispielsweise eine Gleichspannung liefern, während die Elektromotoren 4 einen dreiphasigen Wechselstrom erfordern, um zu arbeiten. Das Leistungselektronikmodul 16 kann die Gleichspannung in einen dreiphasigen Wechselstrom umwandeln, wie von den Elektromotoren 4 gefordert. In einem regenerativen Modul wandelt das Leistungselektronikmodul 16 den dreiphasigen Wechselstrom von den Elektromotoren 4 um, welche als Generatoren des Gleichstroms, der von dem Batteriepaket 14 gefordert wird, fungieren. Das hier beschriebene Verfahren ist ebenfalls bei einem reinen Elektrofahrzeug oder einer anderen Vorrichtung, die ein Batteriepaket verwendet, anwendbar.
Außer der Lieferung von Energie für den Antrieb kann das Batteriepaket 14 Energie für andere elektrische Anlagen von Fahrzeugen liefern. Ein typisches System kann ein DCDC-Wandlermodul 18 aufweisen, das die hohe DC-Spannungsleistung des Batteriepakets 14 in eine niedrige DC-Versorgungsspannung, die mit anderen Fahrzeuglasten kompatibel ist, umwandelt. Andere hohe Spannungslasten können direkt ohne Verwendung eines DCDC-Wandlermoduls 18 verbunden werden. Bei einem üblichen Fahrzeug werden die Niederspannungssysteme elektrisch mit einer 12 V-Batterie 20 verbunden.
Batteriepakete 14 können aus einer Vielzahl chemischer Kombinationen zusammengesetzt werden. Übliche chemische Zusammensetzungen von Batteriepaketen 14 sind Blei-Säure, Nickelmetall-Hybrid (NIMH) oder Lithium-Ion. 2 zeigt ein übliches Batteriepaket 14 in einer einfachen Reihenbauweise von N Batteriezellen 32. Andere Batteriepakete 14 können jedoch aus einer beliebigen Anzahl einzelner Batteriezellen bestehen, die in Reihe oder parallel oder in einer beliebigen Kombination davon geschaltet sind. Ein typisches System kann eine oder mehrere Steuergeräte, wie zum Beispiel ein Batteriesteuermodul (BCM) 36 aufweisen, welches die Leistung des Batteriepakets 14 überwacht und steuert. Das BCM 36 kann mehrere Pegeleigenschaften des Batteriepakets 14 überwachen, wie zum Beispiel den Paketstrom 38, die Paketspannung 40 und die Pakettemperatur 42.
Zusätzlich zu den Pegeleigenschaften des Pakets können Pegeleigenschaften der Batteriezelle vorhanden sein, die gemessen und überwacht werden müssen. Zu diesen Merkmalen können beispielsweise Spannung, Strom und Temperatur der Batteriezellen gehören. Ein System kann Sensormodule 34 verwenden, um die Eigenschaften der Batteriezelle zu messen. Je nach den Fähigkeiten kann das Sensormodul 34 die Merkmale von einer oder mehreren Batteriezellen 32 messen. Als einige Möglichkeiten kann ein Sensormodul 34 eine Modultemperatur vorsehen, die für die Temperatur einer einzelnen Zelle oder einer Gruppe mehrerer Zellen des Pakets repräsentativ ist. Das Batteriepaket 14 kann bis zu N_C Sensormodule 34 nutzen, um die Merkmale aller Batteriezellen 32 zu messen. Jedes Sensormodul 34 kann die Messungen an das BCM 36 zur weiteren Verarbeitung und Koordination übertragen. Das Sensormodul 34 kann Signale in analoger oder digitaler Form an das BCM 36 übertragen.
3 zeigt ein typisches äquivalentes Batteriekreismodell. Eine Batteriezelle kann als Spannungsquelle (V_OC) 50 modelliert sein, die Widerstände (52 und 54) und eine damit verbundene Kapazität 56 aufweist. Aufgrund der Batteriezellenimpedanz ist die Klemmenspannung, V 58, üblicherweise nicht dieselbe wie die Leerlaufspannung V_OC 50. Die Leerlaufspannung V_OC 50 ist nicht ohne weiteres messbar, da nur die Klemmenspannung 58 der Batteriezelle für die Messung zugänglich ist. Da die V_OC 50 nicht ohne weiteres messbar ist, kann ein modellbasiertes Verfahren verwendet werden, um den Wert zu schätzen. Bei jedem Modell ist es erforderlich, dass die Widerstands- und Kapazitätswerte bekannt sind oder geschätzt werden. Es ist anzumerken, dass das Batteriezellenmodell von der Zusammensetzung der Batterie abhängen kann, und das für die Batteriezelle gewählte genaue Modell nicht kritisch ist. Das Modell kann beispielsweise ein äquivalentes Batteriekreismodell sein, ein elektrochemisches Modell einer Batterie oder ein anderes Modell der Batteriezelle oder Bestandteilen der Zelle.
Die SOC und OCV können durch eine monoton steigende, eineindeutige, differenzierbare Funktion erster Ordnung in Beziehung gebracht werden: V_OC = f(SOC) (1)
Eine Zustandsraumgleichung für das äquivalente Batteriekreismodell in der veranschaulichten Ausführungsform kann wie folgt entwickelt werden. Die Ableitungen von V_OC mit Bezug auf die Zeit können mit der des SOC gegenüber der Zeit in Beziehung gesetzt werden, wie unten dargestellt:
Es sei
Gemäß dem äquivalenten Batteriekreismodell aus 3:
Aufgrund von Gleichung (1) unter der angenommenen Eigenschaft, dass die Funktion f differenzierbar erster Ordnung ist:
Durch Verknüpfen der Gleichungen (4) und (5):
Unter Bezugnahme auf Gleichung (3):
Aufgrund von Gleichung (4) besteht eine Aufgabe darin, die Modellparameter zu identifizieren und gleichzeitig den SOC (über die OCV) zu schätzen. Bei einer Ausführungsform der Erfindung kann ein Beobachter auf der Basis der Gleichungen (8) und (9) ausgelegt sein:
Bei der dargestellten Ausführungsform wird der oben beschriebene Beobachter genutzt, um ein Problem der indirekten adaptiven Beobachtung zu lösen. Es versteht sich, dass Details des Beobachters je nach der Anwendung variieren können.
Bei der veranschaulichten Ausführungsform wird der folgende Ansatz für die Parameteridentifikation verwendet. Aus den Gleichungen (4) und (5):
Durch das Erhalten einer Beziehung zwischen den Parametern und Systemvariablen und dann Diskretisieren der Beziehung:
Die diskretisierte Form ist:
Ein Verfahren, das breite Anwendung findet, ist der Kalman-Filteransatz zum langsamen Variieren der Parameteridentifikation. Es ist Teil der Familie der Verfahren zur rekursiven Parameterschätzung.
Zuerst wird Gleichung (14) umgeschrieben zu: Y(k) = Φ^T(k)·Θ(k) (15)
Dann kann das auf dem Kalman-Filter basierende Verfahren der rekursiven Parameterschätzung ausgedrückt werden als:
Wobei Θ ^(k + 1) der geschätzte Parametervektor ist, K, Q, P verwandte Zwischenvariablen (Matrizen) sind und R₁ und R₂ Konstanten sind (kalibrierbare Variablen).
Es versteht sich, dass der Kalman-Filter-Ansatz zur Parameteridentifikation ein möglicher Ansatz ist, der verwendet werden kann. Alternativ kann jedes Verfahren zur rekursiven Schätzung verwendet werden, mit variierender Robustheit und Genauigkeit.
Nun unter Bezugnahme auf die SOC-Schätzung schätzt ein nichtlinearer Beobachter die Zustände (V_OC, V_C), nachdem ein Algorithmus zur rekursiven Schätzung gewählt ist und die Schaltungsparameter gut erfahren worden sind.
In der dargestellten Ausführungsform kann unter der Annahme, dass die verwandten Parameter aus Gleichung (16) identifiziert worden sind, der Beobachter unter Verwendung der identifizierten Parameter realisiert werden:
Es sei
Unter der Annahme einer genauen Schätzung von Schaltungsparametern durch das ordnungsgemäße Auswählen eines Verstärkungsfaktoren L kann der oben gezeigte Beobachter stabil gemacht werden. Für den veranschaulichten Beobachter kann ein fester Verstärkungsfaktor (L-Matrix) ausgewählt werden, um für die ganze, durch die Gleichungen (8) und (9) dargestellte Familie von Li-Ionen-Batterien zu funktionieren. Insbesondere kann der Beobachterverstärkungsfaktor L derart gewählt werden, dass L1 > 0, L2 = 0, so dass die Fehlerdynamik für die ganze Familie der Batterie unter beliebigen Betriebsbedingungen immer stabil ist.
Da Parameteridentifikation und Zustandsbeobachtung bei dem beschriebenen Modell insbesondere getrennte Aufgaben sind, kann die Aufgabe der Parameteridentifikation von einer anderen Rechenvorrichtung als der Aufgabe der Zustandsbeobachtung ausgeführt werden. Die Aufgabe der Zustandsbeobachtung kann beispielsweise von dem BCM 36 des Fahrzeugs ausgeführt werden, während die Aufgabe der Parameterschätzung an einen fahrzeugexternen Rechendienst ausgelagert werden kann. Da die Parameteridentifikation verhältnismäßig rechenintensiver ist als die Zustandsbeobachtung, verringert das Auslagern der Aufgabe der Parameteridentifikation den Umfang des Rechen- und Computerspeichers, der von dem Fahrzeug gewährleistet werden muss.
4 ist ein Diagramm einer Cloud-basierten Architektur 70 zum Auslagern von Aufgaben der Parameteridentifikation von einem Fahrzeug. Die Architektur 70 weist ein BCM 36 auf, das mit einem Fahrzeug zum Cloud-Modul 72 kommuniziert, wobei das Cloud-Modul 72 dafür konfiguriert ist, die Fahrzeugkommunikation mit den Cloud Computing-Ressourcen 74 zu erleichtern.
Wie in der Architektur 70 als Fluss (1) angegeben, kann das BCM 36 dafür konfiguriert sein, die Batterie zu steuern und Batteriezellmessung verschiedener Batterievariablen durchzuführen. Außerdem kann das BCM 36, wie durch Fluss (2) angegeben, ferner dafür konfiguriert sein, die Messungen an das Cloud-Modul 72 zu übertragen. Das Cloud-Modul 72 kann dafür konfiguriert sein, die Messungen zu empfangen, die Messungen zu verpacken und, wie durch Fluss (3) angegeben, die Paketmessungen über eine mobile Verknüpfung zu der Cloud Computing-Ressource 74 zu übertragen (z. B. über ein Telematics-Steuergerät des Fahrzeugs). Durch die Verwendung eines Batteriemodells, wie zum Beispiel das oben ausführlich erörterte äquivalente Batteriekreismodell, kann die Cloud Computing-Ressource 74 dafür konfiguriert werden, Modellparameter der Batterie aufgrund der empfangenen Messungen zu berechnen. Andere Modelle können für die Fernberechnung anderer Arten von Werten verwendet werden, wie zum Beispiel ein Batteriegesundheitsmodell für die Schätzung der Batteriegesundheit, ein elektrochemisches Modell für die Parameteridentifikation eines elektrochemischen Modells, usw. Wie durch Fluss (4) dargestellt, kann die Cloud Computing-Ressource 74 ferner dafür konfiguriert werden, eine Rückmeldung über die mobile Verknüpfung zu dem Cloud-Modul 72 zu liefern, einschließlich der festgelegten Modellparameter. Das Cloud-Modul 72 kann die Rückmeldung empfangen und, wie durch Fluss (5) angegeben, die Modellparameter zurück zu dem BCM 36 senden. Das BCM 36 kann entsprechend die Modellparameter, die von der Ressource 74 berechnet werden, verwenden, um die Zustandsschätzung durchzuführen. Entsprechend kann das Fahrzeug durch Verwenden der Cloud-basierten Architektur 70 die Bestimmung von Modellparametern auslagern, deren Berechnung durch das BCM 36 unter Verwendung seiner eigenen Rechenfähigkeiten teuer oder schwierig sein kann.
5 ist ein Diagramm einer Architektur eines Zustandsbeobachters 80, die die Cloud-basierte Architektur 70 zum Auslagern von Aufgaben der Parameteridentifikation verwendet. Die Architektur 80 weist Eingaben 90, wie zum Beispiel Spannung, Strom und Temperatur auf. Ein externer Parameteridentifikationsblock 82, der die Cloud-basierte Architektur 70 verwendet, kann dafür konfiguriert werden, die Eingaben 90 zu empfangen, und liefert Modellparameter. Ein OCV-Schätzblock 84 dann dafür konfiguriert werden, um die Modellparameter zu empfangen und die OCV zu schätzen. Ein SOC-Berechnungsblock 92 kann dafür konfiguriert werden, die geschätzte OCV zu SOC abzubilden. Ein Verzögerungsblock 94 kann dafür konfiguriert werden, um die geschätzte OCV zu dem Parameteridentifikationsblock 82 zurückzuspeisen. Zwar wird hier eine beispielhafte Modularisierung der Architektur 80 beschrieben, jedoch sollte ebenfalls darauf hingewiesen werden, dass die Funktionalität in mehr, weniger oder verschiedene Funktionalitätsblöcke integriert werden kann.
Wie veranschaulicht, kann der Parameteridentifikationsblock 82 dafür konfiguriert werden, Eingaben 90 zu empfangen, die für die Berechnung von Modellparametern verwendet werden. Für ein äquivalentes Batteriekreismodell können diese Eingaben 90 beispielsweise Spannung, Strom, Temperatur und eine vorher geschätzte OCV umfassen. Die Eingaben 90 können Informationen umfassen, die von dem BCM 36 von den Sensormodulen 34 empfangen werden, wie zum Beispiel Messungen der Spannung, des Stroms und der Temperatur auf Zellebene, sowie Merkmale auf Batteriepaketebene 14, die von dem BCM 36 empfangen werden, wie zum Beispiel Paketstrom 38, Paketspannung 40 und Pakettemperatur 42.
Wie oben erwähnt, kann der Kalman-Filteransatz nützlich sein für die Durchführung einer Parameteridentifikation für langsam variierende Parameter. Aufgrund der verhältnismäßig langsamen Veränderung bei der Parameteridentifikation sowie der dazugehörigen rechnerischen Komplexität kann der Parameteridentifikationsabschnitt des Kalman-Filters geeignet sein zum Auslagern an die Cloud Computing-Ressource 74. Statt die Parameteridentifikation an dem BCM 36 durchzuführen, kann der Parameteridentifikationsblock 82 daher dafür konfiguriert werden, die gesammelten Eingaben 90 an das Cloud-Modul 72 zur Verarbeitung durch die Cloud Computing-Ressource 74 zu liefern (z. B. Fluss 2, wie in der Architektur 70 veranschaulicht). Der Parameteridentifikationsblock 82 kann ferner dafür konfiguriert werden, äquivalente Batteriekreismodellparameter aus der Cloud Computing-Ressource 74 über das Cloud-Modul 72 zurückzuerlangen (zum Beispiel Fluss 5, wie in der Architektur 70 veranschaulicht). Weitere Aspekte des Datenaustauschs zwischen dem BCM 36 und der Cloud Computing-Ressource 74 werden unten ausführlich mit Bezug auf die 7–10 erörtert.
Der OCV-Schätzblock 84 kann dafür konfiguriert werden, das OCV-Batteriepaket 14 zu schätzen. Ein Beobachter des OCV-Schätzblocks 84 kann beispielsweise gemäß den Modellparametern, die von dem Parameteridentifikationsblock 82 empfangen werden, gesteuert werden. Der Beobachter kann gemäß einem Modell, wie zum Beispiel dem äquivalenten Batteriezellen-Kreismodell, das in 3 veranschaulicht ist und oben ausführlich erläutert wurde, ausgeführt werden.
Der SOC-Berechnungsblock 92 kann dafür konfiguriert werden, den Batterie-SOC zu bestimmen. Der SOC-Berechnungsblock 92 kann beispielsweise einen OCV-Wert von dem OCV-Schätzblock 84 empfangen und kann eine nichtlineare Abbildung von OCV an SOC nutzen, um einen SOC für das Batteriepaket 14 zu bestimmen. 6 veranschaulicht eine beispielhafte Abbildung von OCV an SOC. Wie in der Kurve 96 zur Veranschaulichung der Beziehung zwischen der Batterie-OCV- und der Batterie-SOC-Ladung, können SOC und OCV durch eine monoton steigende, eineindeutige, differenzierbare Funktion erster Ordnung, wie oben mit Bezug auf Gleichung (1) erläutert, in Beziehung gebracht werden.
Wenn wir zu 5 zurückkehren, kann der Verzögerungsblock 94 dafür konfiguriert werden, die geschätzte OCV zurück an den Parameteridentifikationsblock 82 zur Verwendung in einer zukünftigen Runde der Parameteridentifikation als letzten geschätzten OCV-Wert zu liefern. Insbesondere da das Auslagern der Parameteridentifikation an die Cloud Computing-Ressource 74 eine zusätzliche Latenz im Vergleich mit einer lokalen Berechnung mit sich bringen kann, sind zusätzliche Verzögerungsblöcke 94 vor den Eingaben 90 an das Parameteridentifikationsmodul 82 nicht dargestellt und können optional oder unnötig sein.
7 ist ein Zeitdiagramm 100 zur Veranschaulichung einer beispielhaften Wechselwirkung zwischen dem BCM 36 des Fahrzeugs und einer Cloud Computing-Ressource 74 unter Verwendung des Cloud-Moduls 72. Wie veranschaulicht, kann das BCM 36 dafür konfiguriert werden, regelmäßig Batteriemessungen an das Cloud-Modul 72 zu liefern. Die gelieferten Messungen können von dem Cloud-Modul 72 in Paketen von mehreren kürzlichen Messungen gesammelt (zum Beispiel die 5 letzten Messungen, die 10 letzten Messungen, einzelne Messungen, usw.) und an die Cloud Computing-Ressource 74 geliefert werden. Stellt das Cloud-Modul 72 ein Paket fertig, kann das Cloud-Modul 72 das komplette Paket an die Cloud Computing-Ressource 74 senden. Wie veranschaulicht, kann das Cloud-Modul 72 beispielsweise Messungen mit einer Paketgröße von 5 sammeln. Sind die 5 ersten Messsätze empfangen worden, kann das Cloud-Modul 72 ein erstes Paket von Messungen an die Computing-Ressource 74 senden. Dies erfolgt in dem Zeitdiagramm 100 bei dem Zeitindex t = 5. Das Paket kann ebenfalls zusätzliche Informationen enthalten, wie zum Beispiel einen Zeitindex der letzten Messung, die von dem Cloud-Modul 72 empfangen wurde.
Die Cloud Computing-Ressource 74 kann das Paket der Messungen, das von dem Cloud-Modul 72 gesendet wurde, empfangen und kann Berechnungen zur Modellparameteridentifikation bei den Messungen durchführen. Nach Abschluss der Berechnungen kann die Cloud Computing-Ressource 74 die Ergebnisse der Modellparameter an das Cloud-Modul 72 als Rückmeldung auf das empfangene Paket der Messungen senden. Die von der Cloud Computing-Ressource 74 gesendete Rückmeldung kann außerdem einen Hinweis auf die Muster, die für die Bestimmung der Modellparameter verwendet wurden, enthalten. Die Ergebnisse können beispielsweise einen Zeitindex der letzten Messung, die zur Bestimmung der Modellparameter verwendet wurde, einen Zeitindex, an dem die Messungen von der Cloud Computing-Ressource 74 empfangen wurden, einen Zeitindex, wann die Messungen von dem Cloud-Modul 72 gesendet wurden, oder eine laufende Nummer, die für jeden Satz der an das Fahrzeug gesendeten Ergebnisse erhöht wird, enthalten, um einige Möglichkeiten zu nennen.
Da die Berechnung der Cloud Computing-Ressource 74 einige Zeit in Anspruch nehmen kann, bis sie erfolgt (zum Beispiel länger als der Zeitraum zwischen den Batteriemessungen, die an das Cloud-Modul 72 geliefert werden), kann das Cloud-Modul 72 dafür konfiguriert werden, die Batteriemessungen, die von dem BCM 36 empfangen werden, weiterhin zu empfangen und zu verarbeiten, auch wenn es noch nicht die Rückmeldung von der Cloud Computing-Ressource 74 empfangen hat.
Das Cloud-Modul 72 kann die Modellparameter von der Cloud Computing-Ressource 74 empfangen. Wie veranschaulicht, werden die Modellparameter, die Messungen über die Zeitindexe 1–5 entsprechen, so dargestellt, als ob sie von dem Cloud-Modul 72 zwischen den Zeitindizes 7 und 8 empfangen werden. Das Cloud-Modul 72 kann entsprechend damit beginnen, die empfangenen Parameter an das BCM 36 zurückzusenden (zum Beispiel für die Verwendung durch den OCV-Schätzblock 84). (In einigen Fällen kann das Cloud-Modul 72, bevor Modellparameter an das Cloud-Modul 72 zurückgeschickt werden, Aktualisierungen an das BCM 36 mit der Angabe liefern, dass keine Modellparameter verfügbar sind, oder mit standardmäßigen Modellparametern oder den zuletzt bekannten Modellparametern.) In einigen Beispielen, wenn dem BCM 36 keine Modellparameter zur Verfügung stehen, kann das BCM 36 standardmäßig eine andere Technik der SOC-Berechnung, wie zum Beispiel die Amperestunden-Integration, verwenden. Wie dargestellt, liefert das Cloud-Modul 72 regelmäßig die Parameter an das BCM 36, beispielsweise in Zeitindizes t = [7,5, 8,5, 9,5], wie gezeigt. Es ist anzumerken, dass der Zeitpunkt und der Zeitabstand der Lieferung von Parametern zurück an das BCM 36 schwanken können. Beispielsweise können die Parameter in einem langsameren oder schnelleren Intervall von dem Cloud-Modul 72 an das BCM 36 geliefert werden als die gemessenen Variablen an das Cloud-Modul 72 geliefert werden. Als weiteres Beispiel können die Parameter von dem Cloud-Modul 72 an das BCM 36 als Rückmeldung auf das Empfangen aktualisierter Modellvariablen von der Cloud Computing-Vorrichtung 304 statt oder zusätzlich zu den regelmäßigen Meldungen geliefert werden.
Das Cloud-Modul 72 kann ferner eine Angabe über das Alter der Parameter an das BCM 36 zusammen mit den Parametern liefern. Das Cloud-Modul 72 kann beispielsweise ein Alter der Modellparameter festlegen als Unterschied zwischen dem Zeitindex, an dem die Modellparameter an das BCM 36 geliefert werden, und dem Zeitindex des zuletzt erfassten Satzes von gemessenen Variablen, die verwendet werden, um die Modellparameter zu bestimmen. Durch dieses Alter kann das BCM 36 erfahren, wie alt die verwendeten Modellparameter tatsächlich sind. Stellt das BCM 36 fest, dass die Modellparameter zu alt sind, um verwendet zu werden, kann das BCM 36 standardmäßig eine andere Technik der SOC-Berechnung, wie zum Beispiel die Amperestunden-Integration, verwenden.
Wie oben erwähnt, kann das Cloud-Modul 72 dafür konfiguriert werden, weiterhin Batteriemessungen, die von dem BCM 36 geliefert werden, zu empfangen und zu verarbeiten. In dem Beispiel der Pakete der 5 Messungen kann das Cloud-Modul 72 am Zeitindex 10 ein zweites Paket von Messungen an die Cloud Computing-Ressource 74 liefern, einschließlich Variablen für Zeitindizes t = [6–10]. Die Cloud Computing-Ressource 74 kann das zweite Paket von Messungen empfangen, Modellparameterberechnungen durchführen und eine Rückmeldung an das Cloud-Modul 72 geben, einschließlich eines zweiten Satzes von Modellparametern, die den Zeitindizes t = [6–10] entsprechen. Das Cloud-Modul 72 kann entsprechend die aktualisierten Modellparameter empfangen und die aktualisierten Modellparameter an das BCM 36 liefern.
Ebenso kann das Cloud-Modul 72 am Zeitindex 15 dafür konfiguriert werden, ein drittes Paket von Messungen an die Cloud Computing-Ressource 74 zu liefern. In dem veranschaulichten Beispiel empfängt das Cloud-Modul 72 jedoch keinen Satz von Modellparametern basierend auf dem dritten Paket der Messungen. Dies kann aus verschiedenen Gründen erfolgt sein, wie zum Beispiel ein Kommunikationsproblem beim Senden der gemessenen Variablen an die Cloud Computing-Ressource 74, ein Rechenproblem bei der Cloud Computing-Ressource 74 beim Bestimmen der Modellparameter oder ein Kommunikationsproblem beim Empfangen der Modellparameter von der Cloud Computing-Ressource 74, um einige Möglichkeiten zu nennen.
Das Cloud-Modul 72 kann dafür konfiguriert werden, bis zu einer Timeout-Periode auf eine Rückmeldung von der Cloud Computing-Ressource 74 zu warten. Wird keine derartige Rückmeldung innerhalb der Timeout-Periode empfangen, kann das Cloud-Modul 72 dafür konfiguriert werden, eine weitere Berechnungsanfrage zu stellen. Falls das Cloud-Modul 72 beispielsweise feststellt, dass es innerhalb von drei Zeitindizes (zum Beispiel timeout Δt = 3) keine Rückmeldung von der Cloud Computing-Ressource 74 erhalten hat, kann das Cloud-Modul 72 eine neue Berechnungsanfrage an die Cloud Computing-Ressource 74 stellen. Statt jedoch die gemessenen ursprünglichen Variablen zu verwenden, für welche keine Rückmeldung empfangen wurde (in dem veranschaulichten Beispiel für die Zeitindizes t = [11–15]), kann das Cloud-Modul 72 stattdessen die neuesten Variablen in der neuen Anfrage verwenden (die am Zeitindex t = 18 bei einer Paketgröße von 5 Messungen aufweisen, die den Zeitindizes t = [14–18] entsprechen). Die Aufnahme der neuesten Daten in die neue Anfrage kann helfen zu gewährleisten, dass die berechneten Modellparameter aktueller sind, aber es kann dazu führen, dass die Cloud Computing-Ressource 74 einige historische Daten verliert (in diesem Fall für die Zeitindizes t = [11–13]), falls die Cloud Computing-Ressource 74 derartige Informationen aufbewahrt.
Die Schätzungen, die zwischen dem Cloud-Modul 72 und dem BCM 36 bei t = 8,5–10,5 und bei t = 12,5–19,5 gesendet werden, weisen insbesondere Modellparameter auf, die Wiederholungen der Modellparameter sind, die bei t = 7,5 beziehungsweise 11,5 geliefert werden, jedoch mit einem höheren Altersindikator. Das Cloud-Modul 72 kann diese regelmäßigen Aktualisierungen liefern, da das BCM 36 ein kontinuierliches Steuersystem betreiben und eine ”laufende” Eingabe erwarten kann, während die Cloud Computing-Ressource 74 eher ein ereignisbasiertes System sein kann, das auf Eingaben handelt. Das Cloud-Modul 72 kann entsprechend zwischen diesen beiden Aspekten wechseln, indem es regelmäßig die verfügbaren aktuellen Modellparameter zusammen mit ihrem Alter liefert. Es ist ferner anzumerken, dass in anderen Beispielen diese erneuten Aktualisierungen nicht erforderlich sein können und das BCM 36 stattdessen weiterhin die vorher gelieferten Modellparameter ohne die Aktualisierungen verwenden kann.
8 ist ein Diagramm eines Verfahrens 800 zum Auslagern von Aufgaben der Parameteridentifikation von einem Fahrzeug. Das Verfahren 800 kann beispielsweise von dem Cloud-Modul 72, das zwischen dem BCM 36 und der Cloud Computing-Ressource 74 kommuniziert, ausgeführt werden.
Bei Block 802 empfängt das Cloud-Modul 72 Batteriemessungen. Das Cloud-Modul 72 kann beispielsweise Batteriemessungen von dem BCM 36 empfangen. Die Batteriemessungen können beispielsweise Spannungs-, Strom- und Temperaturmessungen aufweisen, die von dem BCM 36 von den Sensormodulen 34 empfangen werden. Die Batteriemessungen können ebenfalls Pegeleigenschaften des Batteriepakets 14 enthalten, die vom BCM 36 empfangen werden, wie zum Beispiel den Paketstrom 38, die Paketspannung 40 und die Pakettemperatur 42.
Am Entscheidungspunkt 804 legt das Cloud-Modul 72 fest, ob eine Paketgröße erreicht ist. Die empfangenen Batteriemessungen können beispielsweise von dem Cloud-Modul 72 gesammelt werden, bis eine vorgegebene Anzahl von Messungen empfangen ist. Als nicht-einschränkendes Beispiel kann die vorgegebene Anzahl 5 sein, wie in 7 veranschaulicht. Ist die vorgegebene Anzahl der Messungen erreicht, geht die Steuerung zu Block 806. Andernfalls geht die Steuerung zu Block 802.
Bei Block 806 erzeugt das Cloud-Modul 72 ein Messpaket. Das Cloud-Modul 72 kann beispielsweise die vorgegebene Anzahl der Batteriemessungen in einem Paket enthalten. Das Paket kann ebenfalls zusätzliche Informationen enthalten, wie zum Beispiel den Zeitindex der neuesten Messung oder den Zeitindex, an dem die neueste Messung von dem Cloud-Modul 72 empfangen wurde.
Bei Block 808 liefert das Cloud-Modul 72 eine Meldung, die das Messpaket enthält, an die externe Computing Ressource 74. Das Cloud-Modul 72 kann beispielsweise ein Telematics-Steuergerät des Fahrzeugs nutzen, um das Messpaket an eine Adresse einer externen Computing Ressource 74 zu senden, die dafür konfiguriert ist, Messpakete von Fahrzeugen zu empfangen. Als eine Möglichkeit kann die externe Computing Ressource 74 als internetzugänglicher Cloud Service ausgeführt werden.
Am Entscheidungspunkt 810 legt das Cloud-Modul 72 fest, ob eine Rückmeldung auf die Meldung, die das Messpaket enthält, empfangen wurde. Das Cloud-Modul 72 kann beispielsweise dafür konfiguriert werden, bis zu einer im Voraus festgelegten Timeout-Periode auf eine Rückmeldung von der Cloud Computing-Ressource 74 zu warten. Wird keine derartige Rückmeldung innerhalb der Timeout-Periode empfangen, kann das Cloud-Modul 72 dafür konfiguriert werden, eine weitere Berechnungsanfrage zu stellen. Stellt das Cloud-Modul 72 fest, dass keine Rückmeldung erfolgt ist, geht die Steuerung zu Block 806. Insbesondere statt die gemessenen ursprünglichen Variablen aus der Anfrage zu verwenden, für welche keine Rückmeldung empfangen wurde, kann das Cloud-Modul 72, das zu Block 806 zurückkehrt, stattdessen die neuesten Variablen in der erneuten Anfrage verwenden. Wurde eine Rückmeldung empfangen, geht die Steuerung an Block 812.
Bei Block 812 liefert das Cloud-Modul 72 Modellparameter, die in der Rückmeldung an das BCM 36 enthalten sind. Das Cloud-Modul 72 kann ferner ein Alter der Modellparameter in der Rückmeldung enthalten (das zum Beispiel festgelegt wird als Unterschied zwischen dem Zeitindex, an dem die Modellparameter an das BCM 36 geliefert werden, und dem Zeitindex des zuletzt erfassten Satzes von gemessenen Variablen, die verwendet werden, um die Modellparameter zu bestimmen). Das BCM 36 kann entsprechend die Modellparameter verwenden, um eine Zustandsbeobachtung durchzuführen, um mindestens einen Zustand der Batterie zu schätzen. Als eine Möglichkeit kann das BCM 36 die Modellparameter nutzen, um die Zustandsbeobachtung durchzuführen, um eine Batterie-OCV zu schätzen und eine Batterie-SOC aufgrund einer Batterie-OCV-Abbildung an SOC zu schätzen. Nach Block 812 geht die Steuerung zu Block 802.
9 ist ein Diagramm eines Verfahrens 900 zum Auslagern von Aufgaben der Parameteridentifikation von einem Fahrzeug. Das Verfahren 900 kann beispielsweise von dem BCM 36, das mit dem Cloud-Modul 72 kommuniziert, ausgeführt werden, was den Zugriff auf die Cloud Computing-Ressourcen 74 erleichtert. Es ist anzumerken, dass das Verfahren 900 verschiedene Teile aufweist (beispielsweise beginnend an den Entscheidungspunkten 902, 908 und 914), die als ein oder mehrere Prozesse oder Prozessabläufe, die unabhängig voneinander erfolgen können, ausgeführt werden können.
Am Entscheidungspunkt 902 legt das BCM 36 fest, ob eine Zeitüberschreitung bei der Batteriemessung stattgefunden hat. Das BCM 36 kann beispielsweise dafür konfiguriert werden, regelmäßig Batteriemessungen an das Cloud-Modul 72 zu liefern (zum Beispiel jede Sekunde, alle 15 Sekunden, alle 3 Minuten, usw.). Ist die Zeit für die Batteriemessung überschritten, geht die Steuerung zu Block 904. Andernfalls bleibt die Steuerung beim Entscheidungspunkt 902.
Bei Block 904 führt das BCM 36 eine Batteriemessung durch. Das BCM 36 kann beispielsweise Sensormodule 34 des Fahrzeugs nutzen, um Eigenschaften der Batteriezelle zu messen, wie zum Beispiel kann die Spannung, der Strom und die Temperatur jeder Zelle gemessen werden. Als weiteres Beispiel kann das BCM 36 Pegeleigenschaften des Batteriepakets 14 messen, wie zum Beispiel den Paketstrom 38, die Paketspannung 40 und die Pakettemperatur 42.
Bei Block 906 liefert das BCM 36 die Batteriemessungen an das Cloud-Modul 72. Das BCM 36 kann beispielsweise eine oder mehrere Nachrichten über einen Fahrzeugbus an das Cloud-Modul 72 senden, einschließlich der Batteriemessungen. Das BCM 36 kann ferner dem Cloud-Modul 72 zusätzliche Informationen liefern, die für die Bestimmung von Modellparametern aufgrund des verwendeten Modells nützlich sein können, wie zum Beispiel ein vorher berechneter OCV-Wert, der gemäß einer früheren Zustandsbeobachtung, die von dem BCM 36 ausgeführt wurde, bestimmt wurde. Nach Block 904 geht die Steuerung zum Entscheidungspunkt 902.
Am Entscheidungspunkt 908 legt das BCM 36 fest, ob eine Zeitüberschreitung bei der SOC-Bestimmung stattgefunden hat. Das BCM 36 kann beispielsweise dafür konfiguriert werden, regelmäßig den SOC für die Verwendung von Fahrzeugsystemen, wie zum Beispiel den Hybrid-Antriebsstrang oder Benutzer-Schnittstellenelemente des Fahrzeugs, die den aktuellen Ladezustand angeben, zu bestimmen. Die SOC-Bestimmung kann ebenso regelmäßig durchgeführt werden (zum Beispiel jede Sekunde, alle 15 Sekunden, alle 3 Minuten, usw.). Ist die Zeit für die SOC-Bestimmung überschritten, geht die Steuerung zu Block 910. Andernfalls bleibt die Steuerung beim Entscheidungspunkt 908.
Bei Block 910 berechnet das BCM 36 die Batterie-OCV gemäß Modellparametern. Ein Beobachter des OCV-Schätzblocks 84 des BCM 36 kann beispielsweise gemäß Parametern, die von dem Parameteridentifikationsblock 82 empfangen werden, gesteuert werden. Der Beobachter kann gemäß einem Modell, wie zum Beispiel dem äquivalenten Batteriezellen-Kreismodell, das in 3 veranschaulicht ist und oben ausführlich erläutert wurde, ausgeführt werden.
Bei Block 912 bestimmt das BCM 36 den SOC gemäß der OCV. Der SOC-Berechnungsblock 92 des BCM 36 kann beispielsweise den OCV von dem OCV-Schätzblock 84 empfangen und kann eine Beziehungskurve 96 zwischen VOC an SOC nutzen, um einen SOC für das Batteriepaket 14 zu bestimmen. 6 veranschaulicht eine beispielhafte Abbildung von VOC an SOC. Nach Block 912 geht die Steuerung zum Entscheidungspunkt 908.
Am Entscheidungspunkt 914 bestimmt das BCM 36, ob aktualisierte Modellparameter von dem BCM 36 empfangen wurden. Das BCM 36 kann beispielsweise identifizieren, ob Modellparameter von dem BCM 36 von dem Steuerungsmodul 72 empfangen wurden oder ob Modellparameter, die von dem Steuerungsmodul 72 empfangen wurden, neuer sind als die Modellparameter, die aktuell von dem BCM 36 verwaltet werden. Das BCM 36 kann einen oder mehrere eines Zeitindexes der Modellparameter, ein Alter der Modellparameter oder eine laufende Nummer bei den Modellparametern nutzen, um festzustellen, ob die empfangenen Modellparameter aktueller sind. Stellt das BCM 36 fest, dass die Modellparameter aktualisiert werden müssen, geht die Steuerung an Block 916. Andernfalls bleibt die Steuerung beim Entscheidungspunkt 914.
Bei Block 916 aktualisiert das BCM 36 die Modellparameter, die von dem BCM 36 verwaltet werden. Nach Block 916 geht die Steuerung zum Entscheidungspunkt 914.
10 ist ein Diagramm eines Verfahrens 1000 zum Auslagern von Aufgaben der Parameteridentifikation von einem Fahrzeug. Das Verfahren 1000 kann beispielsweise von der Cloud Computing-Ressource 74, die mit dem Cloud-Modul 72 kommuniziert, welches eine Schnittstelle mit dem BCM 36 hat, ausgeführt werden.
Am Entscheidungspunkt 1002 bestimmt die Cloud Computing-Ressource 74, ob Batteriemessungen von einem Fahrzeug empfangen wurden. Ein Cloud-Modul 72 eines Fahrzeugs kann beispielsweise eine Meldung an die Cloud Computing-Ressource 74 geliefert haben, wie oben mit Bezug auf das Verfahren 800 erörtert wurde. Wurde eine Meldung empfangen, geht die Steuerung zu Block 1004, um die Meldung zu verarbeiten. Andernfalls bleibt die Steuerung beim Entscheidungspunkt 1002.
Bei Block 1004 berechnet die Cloud Computing-Ressource 74 Modellparameter unter Verwendung der empfangenen Messungen. Die Parameterschätzung kann beispielsweise von der Cloud Computing-Ressource 74 gemäß dem äquivalenten Batteriezellen-Kreismodell, das in 3 veranschaulicht ist und oben ausführlich erläutert wurde, ausgeführt werden.
Bei Block 1006 liefert die Cloud Computing-Ressource 74 eine Rückmeldung an das Fahrzeug, einschließlich der berechneten Modellparameter. Entsprechend kann das Fahrzeug durch Verwenden der Cloud-basierten Architektur 70 die Bestimmung von Modellparametern auslagern, deren Berechnung durch das BCM 36 unter Verwendung seiner eigenen Rechenkapazitäten teuer oder schwierig sein kann. Nach Block 1006 geht die Steuerung zum Entscheidungspunkt 1002.
Durch die Verwendung externer Cloud Computing-Ressourcen 74 kann ein Fahrzeug daher in der Lage sein, die Parameteridentifikation auszulagern, wodurch der Rechen- und Zustandsaufwand, der erforderlich ist, um von dem Fahrzeug erhalten zu werden, gesenkt wird. Da die Zustandsbeobachtung unter Verwendung extern berechneter Modellparameter verhältnismäßig weniger rechenintensiv ist als die Parameterschätzung für das Fahrzeug, kann außerdem eine verbesserte Zustandsschätzung möglich sein, ohne dass eine aufgerüstete Verarbeitungshardware für das Fahrzeug erforderlich ist.
Als eine Möglichkeit können die offenbarten Auslagerungstechniken bei einer verbesserten SOC-Schätzung angewandt werden, die ein BCM 36 eines Fahrzeugs nutzen. Da Modellparameter beispielsweise sich verhältnismäßig langsam ändernde Variablen sein können, kann die Latenz bei ihrer Berechnung durch einen Remote-Server eine noch akzeptable Genauigkeit bei der SOC-Schätzung liefern. Da außerdem die Zustandsbeobachtung unter Verwendung der Parameter von Batteriekreismodellen verhältnismäßig weniger rechenintensiv ist als die Parameterschätzung, kann außerdem eine verbesserte SOC-Schätzung möglich sein, ohne dass eine aufgerüstete Verarbeitungshardware für das Fahrzeug erforderlich ist. Als einige andere Möglichkeiten sind die hier beschriebenen Techniken ebenfalls auf andere Arten von Modellen und Berechnungen anwendbar, bei denen ein Parameterberechnungsanteil von einem Beobachteranteil einer modellierten Berechnung abgetrennt werden kann, wie zum Beispiel zur Berechnung der Batterieleistung und der Bewertung der Batteriegesundheit.
Obgleich oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke dienen eher der Darstellung und nicht der Einschränkung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener Implementierungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.

Claims

Fahrzeug, umfassend: eine Antriebsbatterie; und ein Steuergerät, das dafür konfiguriert ist, das Fahrzeug basierend auf Modellparametern für die Batterie, die von einer fahrzeugexternen Rechenvorrichtung während eines Fahrzyklus empfangen werden, und als Rückmeldung auf die Messungen betreffend ein Modell der Batterie, welche während des Fahrzyklus von dem Steuergerät an die Rechenvorrichtung geschickt werden, zu steuern.
Fahrzeug nach Anspruch 1, wobei die Messungen Messungen der Batteriespannung, des Batteriestroms und der Batterietemperatur umfassen.
Fahrzeug nach Anspruch 1, wobei das Steuergerät ferner dafür konfiguriert ist, regelmäßig die Messungen der Batterie zu erheben und wobei die Messungen eine vorgegebene Anzahl von regelmäßig erhobenen Messungen umfassen.
Fahrzeug nach Anspruch 1, wobei das Modell ein äquivalentes Batteriekreismodell aufweist und wobei das Steuergerät ferner dafür konfiguriert ist: eine Zustandsbeobachtung durchzuführen, um eine Leerlaufspannung (OCV) der Batterie zu schätzen; und den Ladezustand (SOC) der Batterie basierend auf einer Abbildung der zu Batterie-OCV-zu-SOC zu schätzen.
Fahrzeug nach Anspruch 4, wobei die Messungen ferner eine vorherige Schätzung der Batterie-OCV enthalten.
Fahrzeug nach Anspruch 4, wobei das Steuergerät ferner dafür konfiguriert ist, (i) eine Anzeige der verfügbaren Batterieladung in einer Benutzerschnittstelle des Fahrzeugs gemäß dem SOC zu liefern und/oder (ii) den SOC zu nutzen, um den Betrieb eines Hybrid-Antriebsstrangs des Fahrzeugs zu konfigurieren.
Fahrzeug nach Anspruch 4, wobei das Steuergerät ferner dafür konfiguriert ist, standardmäßig eine Amperestunden-Integration zu verwenden um den SOC zu berechnen, wenn (i) die Modellparameter nicht empfangen wurden oder (ii) die Modellparameter älter sind als eine vorgegebene Altersgrenze.
Fahrzeug nach Anspruch 4, wobei die Zustandsbeobachtung mindestens eine der Leistungsfähigkeitsbestimmung oder der Batteriegesundheitsüberwachung umfasst.
System, umfassend: eine Rechenvorrichtung, die dafür konfiguriert ist, von einem Fahrzeug während eines Fahrzyklus des Fahrzeugs über ein Kommunikationsnetzwerk Batteriezellmessungen zu empfangen, die einem Batteriemodell von Batteriezellen des Fahrzeugs entsprechen; und während des Fahrzyklus über das Kommunikationsnetzwerk Batteriemodellparameter für die Zellen als Rückmeldung auf die Messungen an das Fahrzeug zu senden.
System nach Anspruch 9, wobei die Messungen Messungen der Zellspannung, des Zellstroms und der Zelltemperatur umfassen.
System nach Anspruch 9, wobei die Messungen eine vorgegebene Anzahl von regelmäßig erhobenen Batteriemessungen aufweisen.
System nach Anspruch 9, wobei das Batteriemodell ein äquivalentes Batteriekreismodell aufweist, das dafür konfiguriert ist, äquivalente Parameter von Batteriekreismodellen zu liefern, um eine Batterie-Leerlaufspannung (OCV) zu schätzen.
System nach Anspruch 12, wobei die Messungen ferner eine vorherige Schätzung der Batterie-OCV enthalten.
System nach Anspruch 9, wobei die Messungen ferner eine Zeitangabe enthalten, wann mindestens eine Teilmenge der Batteriezellmessungen erhoben wurde und wobei die Rechenvorrichtung ferner dafür konfiguriert ist, die Zeitangabe mit den Batteriemodellparametern zu senden.
Verfahren, umfassend: das Steuern eines Fahrzeugs basierend auf einer Zustandsbeobachtung in Verbindung mit einer Batterie des Fahrzeugs gemäß Batteriemodellparametern für Batteriezellen der Batterie, die von einem Fahrzeugsteuergerät während eines Fahrzyklus des Fahrzeugs von einer fahrzeugexternen Rechenvorrichtung empfangen werden als Rückmeldung auf Messungen, die sich auf ein Batteriemodell der Zellen beziehen, welche von dem Steuergerät während des Fahrzyklus an die Rechenvorrichtung geschickt werden.
Verfahren nach Anspruch 15, wobei die Messungen Messungen der Zellspannung, des Zellstroms und der Zelltemperatur umfassen.
Verfahren nach Anspruch 15, ferner umfassend das regelmäßige Erheben der Messungen der Batteriezellen, wobei die Messungen eine vorgegebene Anzahl von regelmäßig erhobenen Messungen umfassen.
Verfahren nach Anspruch 15, wobei das Batteriemodell ein äquivalentes Batteriekreismodell aufweist und ferner umfasst: das Durchführen einer Zustandsbeobachtung, um eine Leerlaufspannung (OCV) der Batterie zu schätzen; und das Schätzen des Ladezustands (SOC) der Batterie basierend auf einer Abbildung der Batterie-OCV-zu-SOC.
Verfahren nach Anspruch 18, wobei die Messungen ferner eine vorherige Schätzung der Batterie-OCV umfassen.
Verfahren nach Anspruch 18, ferner umfassend (i) das Bereitstellen einer Anzeige der verfügbaren Batterieladung in einer Benutzerschnittstelle des Fahrzeugs gemäß dem SOC und/oder (ii) das Nutzen des SOC, um den Betrieb eines Hybrid-Antriebsstrangs des Fahrzeugs zu konfigurieren.