The present disclosure generally relates to battery capacity estimation for an electric vehicle.
Estimating capacity of a battery is important in managing performance of an electric vehicle. However, estimating battery capacity has many challenges and existing state of the art methods can be difficult to keep battery capacity learning updated on a regular basis. As such an improved system and method is needed for battery capacity estimation for an electric vehicle.
A battery management system (BMS) for an electric vehicle is provided. The battery management system may include a battery pack and a battery controller. The battery controller may acquire a first reading of battery terminal voltage, battery temperature, and battery current throughput of the battery cell or pack in response to first criteria being met, acquire a second reading of battery terminal voltage, battery temperature, and battery current throughput of the battery cell or pack in response to second criteria being met, and determine an estimated capacity of the battery cell or pack. The battery controller may further validate the estimated capacity in response to third criteria being met.
The battery controller may determine the estimated capacity based on State of Charge (SoC) of battery at two different time instants and an accumulated ampere-hour between the time instants. The estimated capacity of each battery cell may be determined periodically. The estimated capacity of each battery cell may involve two different learned values of capacity and one old value of capacity. The state of charge values may be acquired based on Open-Circuit Voltage (OCV) of the battery cell or pack in equilibrium state. The battery controller may determine if the battery capacity needs to be updated based on the time passed since last update of capacity.
In other aspects of the disclosure, the battery controller may determine the temperature of the battery at the time of the SoC read. The battery controller may determine if the battery has reached to an equilibrium state. The battery controller may determine based on temperature and battery rest time, to read a first value of SoC if a capacity update has to be performed based on time since last update. The battery controller may determine to read a second value of SoC. The battery controller may determine the difference ΔSoC between the second value of SoC, and the first value of SoC, and determine the battery rest time. The battery controller may analyze ΔSoC and battery rest time, and determine a capacity learning procedure shall be initiated, or reset the procedure, or wait and record Ah, or replace the first value of SoC with the second value of SoC and reset Ah reading.
Also, the battery controller may determine the learned capacity using ΔSoC and Ah recorded capacity between first and second value of SoC. The battery controller may determine whether a validation of learned capacity is required. The battery controller may determine based on temperature and battery rest time, to read a third value of SoC. The battery controller may determine the difference ΔSoC between the third value of SoC, and the second value of SoC, and calculates the battery rest time. The battery controller may analyze ΔSoC and battery rest time, and determines a capacity learning procedure shall be initiated, or reset the procedure, or wait and record Ah, or replace the second value of SoC with the third value of SoC and reset Ah. The battery controller may determine a second learned capacity using ΔSoC and Ah recorded capacity between the second value of SoC and the third value of SoC.
The battery controller may determine a validation index with respect to nominal capacity of battery based on the first learned capacity and second learned capacity. The battery controller may determine based on the validation index to update capacity or discard new learning values. The battery controller may analyze the validation index to determine an impact of new learned values in an overall capacity update. The battery controller is configured to perform an adaptive (eg., weighted) averaging between the first and second learned capacity values to identify a new learned capacity of battery cell or pack. The battery controller may compare the new learned capacity with the last valid capacity of the battery cell or pack, analyzes a time passed since a last valid value to identify a depth of aging of the battery cell or pack. The battery controller may employ an analysis of the depth of aging to tune an averaging algorithm with the new learned value of capacity and an old valid value. The battery controller may update the estimated capacity based on the new learned value, the old valid value, and a tuning mechanism.
Further objects, features, and advantages of this invention will become readily apparent to persons skilled in the art after a review of the following description, with reference to the drawings and claims that are appended to and form a part of this specification.
State of Health (SoH) of the battery can be an important parameter of concern in battery monitoring. It can be an important indicator that may be required by end-customers. SoH is often defined in terms of the capacity of the battery with respect to fresh cell capacity, e.g., how much of electrical charge the battery can store before it is over charged. In this regard, accurate estimation of battery capacity can be the key to accurate SoH monitoring. One method is to measure battery capacity using a coulomb counting algorithm where SoC is measured at two instances of battery use, integral of current versus time is calculated between these two data points, and capacity is estimated as Qlearned=∫ηI·dt/ΔSoC. The new estimated value may be filtered using a weighted averaging methodology that combines the new value with old value.
There are a couple of drawbacks in the above described method that this proposal can address and improve. First, the estimation of battery cell or pack capacity Q can be performed in an open-loop structure where no validation on the accuracy of estimated capacity Q is conducted. Due to the averaging mechanism between old value and current estimated value, a corrupted capacity estimated value could corrupt the capacity estimation for the entire life of the battery usage. There are a number of different factors that can impact the accuracy of battery capacity estimation such as: accuracy of calculated SoC values, charging efficiency values, temperature variation, battery conditions under which the estimation is performed, battery usage profile such as current profile, the averaging that may be performed between old and new learned values, or other parameters. However, for existing methods, there is no compensation mechanism incorporated for the mentioned uncertainty factors. Moreover, in the weighted averaging methodology, only the time instances between current estimation time and the old estimation time is considered and no other conditions regarding the accuracy of estimated battery cell or pack capacity value Qlearned and Qold is considered. Also, the acquired SoC values may be restricted to be measured at two consecutive events of Keyon to Keyoff which may not be readily available, thus impede capacity estimation, and also influence its accuracy depending the specific vehicle usage patterns.
This disclosure provides improvement of battery capacity estimation methodologies to address the aforementioned drawbacks. The proposed method may provide a validation of the estimated capacity by using a second estimation of the current capacity. Consistency between estimated capacity values would increase the confidence in estimated values and thus old estimated values can be corrected more effectively, and in a timely manner.
In another aspect of this disclosure, a more dynamic and sophisticated mechanism is provided for averaging between new learned values and old values of battery capacity. This is to address the fact that battery capacity estimation is done in a periodic manner and aging of that battery has gone through in each period could be different depending on the usage pattern of the battery, weather conditions, and road conditions, among others. A new update scheme for capacity value that reflects the estimation accuracy of new learned capacity value and the difference between old value and new learned value is proposed in this disclosure.
Also, provided in this disclosure is a new scheme on how to collect and merge required data to perform capacity estimation to facilitate the capacity estimation under different driving patterns.
The battery controller 110 may also be in communication with a thermal controller 116. The thermal controller 116 may heat or cool the battery pack 110 using a heater or cooler 118. The heating or cooling may be based on various measured or calculated variables of the battery pack 110 and/or additional information related to the vehicle or vehicle subsystems.
A power source 210 (e.g. battery) is provided that represents the OCV=f(SoC). The circuit 200 includes a resistance R0 represented by resistor 212. The circuit 200 includes a first load including a resistance R1 and a capacitance C1 (e.g. in parallel) that causes a voltage drop of V1 which is represented by resistor 214 and capacitor 216 (e.g. connected in parallel). The first load may be in series (e.g. or parallel not shown) with additional loads, such as a second and third load. The second load may include a resistance R2 and a capacitance C2 (e.g. in parallel) that causes a voltage drop of V2 which is represented by resistor 218 and capacitor 220 (e.g. connected in parallel). Meanwhile, the third load may include a resistance R3 and a capacitance C3 (e.g. in parallel) that causes a voltage drop of V3 which is represented by resistor 222 and capacitor 224 (e.g. connected in parallel). The loads may collectively generate a current flow of I and a total voltage drop of Vt which may be measured by a measurement device 226 (e.g. which may include an amp meter and/or volt meter).
In one implementation, the battery capacity may be calculated in a periodic manner where at two successive instances of Keyon events, SoC value is calculated and captured, and learned capacity is calculated, for example, as follows. Here I is the battery current as a function of time, η is the charging efficiency of the battery (whereas discharge efficiency is considered to be 1), and SoC2 and SoC1 are the two SoCs mentioned above.
In this implementation, a validation stage is added to estimation, and updating scheme of the capacity value is also modified accordingly which provides a dynamic framework for battery capacity update. Also, the necessity of capturing SoC in consecutive driving cycles is modified in a manner that provides more flexibility for the software to perform the estimation in a more frequent manner which would lead to a more accurate estimation of capacity and state of health value. Therefore, the following aspects of the proposed system may include:
To have an accurate estimation of SoC, and hence battery capacity, SoC is estimated from open circuit voltage (OCV) of the battery when battery has sufficiently rested. Also, ΔSoC between two instances used in battery capacity estimation must meet certain limits so to suppress disturbance and error accumulation impact on capacity estimation.
Depending on the driving pattern, there might be many instances that the above conditions are not met properly in two consecutive Keyon events to be able to measure capacity. Prior art methods will simply abandon the overall estimation process if conditions do not meet to give accurate estimation of capacity. However, discarding captured values of Ah=∫ηI·dt, and SoC1 if those conditions are not met, will just delay the capacity estimation which may not be necessary.
For instance, consider the situation where a first read of SoC is available, the battery was only relaxed for a short period that does not allow the SoC estimation based on battery voltage readings, or it was driven for a short period that did not create enough ΔSoC, in this implementation, the controller can still keep data, update Ah, and try to do the estimation on the next Keyon event, given the conditions are satisfied rather than discarding the data and start all over again.
In one implementation, Table 1 is provided which depending on the values of ΔSoC, and Keyoff time (i.e. battery rest time), a decision is made as what action must be taken. Depending on the conditions, four possible actions might be adopted which are 1). Continue to update Ah; 2). Discard old value of SoC1, replace it with the latest value of SoC, and reset Ah; 3). Capture SoC2 and perform Q calculation; 4). Reset SoC1 and Ah and look for the next Keyon event to capture SoC1 value. Each range of ΔSoC in Table 1 can be determined by the controller, then update strategies can be chosen in response to the determined range. The actual values of each range may be specific to a battery or vehicle model. Further, all or some of the ranges may be utilized for a specific model.
Short is same as Medium Short in Table 1, but depending on the desired conditions, either of them can be modified as well. For example in case deltaSOC is too small, we can reset for short-period (due to large impact of noise for instance), but let medium-short to update Ah.
The capacity estimation may be performed in two stages where the second capacity calculation is used to validate the first calculation. For prior art, capacity could only be calculated in an open loop manner where no validation on the estimated value was performed. Therefore, if estimated capacity is inaccurate or even faulty, it will affect the capacity estimation and no recovery mechanism is provided.
Depending on the validation results, the contribution of the new learned value in the averaging process is determined.
Two capacity values are calculated as follows:
The two learned values are compared for consistency, and a consistency value is calculated as follows. The value QBOL is the battery cell or pack capacity at begin-of-life (BOL) of the battery
ϑ=∥(Qlearned,1−Qlearned,2)/QBOL∥
Qlearned,1 and Qlearned,2 must be acquired in a relatively close time to each other compared to the periods of capacity estimation. Due to slow dynamics of capacity, and the fact that capacity values are measured relatively close to each other, it is expected that Qlearned,1 and Qlearned,2 are close and their difference is much smaller than QBOL.
Consistency value is checked with pre-defined boundaries, and appropriate decision is taken depending on the consistency level acquired. The decision could include the weight of Qlearned in overall capacity estimation, or the decision to discard the values and not performing any update.
The new learned value for capacity is calculated as following:
Q
learned
=γQ
learned,1+(1−γ)Qlearned,2
where γ as the weighting average can take a pre-defined constant or a dynamic value depending on the estimation conditions under which each estimation occurred.
The overall capacity of the battery is updated as follows:
Q=α
new
Q
old+(1−αnew)Qlearned
where αnew is a function of time since last update, degradation since last update as captured by Qold and Qlearned, and consistency value which determines the confidence level of the new learned value.
Parameter αnew is calculated as follows:
where α∈[0,1] is a function of consistency value ϑ, T is the life of the battery, T1 is the pre-defined calibrated time, and Tc is the time passed since the last estimation, and parameter β∈[0,1] is a function of Qlearned/Qold, where as Qlearned/Qold decreases, β decreases to give more weight to new learned value. This is determined based on the fact that battery capacity normally decreases with additional usage.
If the first read is available in block 318, then the method proceeds to block 326. In block 326, the controller determines if a subsequent (e.g. 2nd) read of SoC is available. If a subsequent read of SoC is not available, then the method may proceed to block 328. In block 328, the controller may determine if the conditions are met to capture SoC2. The conditions to capture SoC2 may include 1) battery rest time, 2) accurate SOC estimation, 3) battery temperature, 4) battery operation mode, etc. If the conditions to capture SoC2 are not met, then the method proceeds to block 330. In block 330, the controller may 1) keep updating Ah, 2) replace SoC1 with a new value, 3) reset the first read available flag, or any combination of these elements. If the conditions to capture SoC2 are met, then the method proceeds to block 332. In block 332, the controller may 1) capture SoC2, 2) save SoC2 temperature, 3) calculate Qlearned,1, 4) set a second read available flag to indicate a second read has been acquired, 5) reset Ah, or any combination of these elements. The method may then restart in block 310, jump to block 326, or conclude.
If the subsequent (e.g. 2nd) read is available in block 326, the method may proceed to block 334. In block 334, the controller determines if conditions are met to capture SoC3. The conditions to capture SoC3 may include 1) battery rest time, 2) time passed since last SoC read, 3) accurate SoC estimation, 4) battery temperature, 5) battery operation mode, etc. The conditions to acquire SoC3 could generally be more relaxed to facilitate the validation of capacity learning procedure and its update. If the conditions to capture SoC3 are met, then the method proceeds to block 336. In block 336, the controller may 1) capture SoC3, 2) calculate Qlearned,2, 3) determine Qlearned, or any combination of these elements. The method may then proceed to block 338. In block 338, the controller may update Q, update SoH, update last update time, reset Ah, reset first and second reading available flags, or any combination of these elements. The method may then conclude or restart in block 310.
If the conditions are not met to capture SoC3, the method may proceed to block 340. In block 340, the controller determines if the validation step should be skipped. If the controller determines that the validation step should not be skipped, the method proceeds to block 342. In block 342, the controller decides whether to keep Ah, update Ah, replace SoC2, or any combination of these elements. If the controller determines that the validation step should be skipped, the method proceeds to block 338. In block 338, the controller may 1) update Q, 2) update SoH, 3) update last update time, 4) reset Ah, 5) reset first and second reading available flags, or any combination of these elements. The method may then conclude or restart in block 310.
The proposed method improves the capacity estimation on a few fronts, including estimation accuracy, validation of learned capacity, facilitation of capacity estimation and accommodation of different battery operating and storage conditions.
A validation step is added to the method to validate the learned value of battery capacity Q. This will improve the accuracy of estimated capacity and state of health. It also provides a framework to verify the estimated value and make corrective action if required where current state of art uses an open-loop estimation in which a one-time bad estimated value of capacity will forever affect capacity estimation and leaves no choice to perform any correction.
A validation step not only improves the accuracy on the new learned value but also provides a framework that can validate the old learned value of capacity based on the consistency level acquired between the two new learned values of capacity.
The capacity estimation mechanism is also enhanced to better accommodate different driving patterns. As a result, capacity estimation is facilitated which allows to perform estimation more regularly and avoid delays in estimation due to some driving conditions which impose limitations on accumulated Ah, or ΔSoC, or battery rest time.
Also, the update scheme of the capacity is modified in order to consider the accuracy achieved in validation, and also the contribution of Qold and Qlearned in the estimation of new value is adjusted dynamically based on battery aging happened since last update of capacity.
The methods, devices, units, controllers, modules, units, engines, and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components and/or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples.
The circuitry may further include or access instructions for execution by the circuitry. The instructions may be stored in a tangible storage medium that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings.
The implementations may be distributed as circuitry among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways, including as data structures such as linked lists, hash tables, arrays, records, objects, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a Dynamic Link Library (DLL)). The DLL, for example, may store instructions that perform any of the processing described above or illustrated in the drawings, when executed by the circuitry.
As a person skilled in the art will readily appreciate, the above description is meant as an illustration of implementation of the principles this disclosure. This description is not intended to limit the scope or application of this system in that the system is susceptible to modification, variation and change, without departing from the spirit of this disclosure, as defined in the following claims.