WO2020115761A1

WO2020115761A1 - Cloud-based battery management system to predict battery life and battery health

Info

Publication number: WO2020115761A1
Application number: PCT/IN2019/050861
Authority: WO
Inventors: T. Sundaraja Iyengar VARADARAJAN; Gopalakrishnan Ramachandran; Jagannathan Srinivasan; Sathyapriya BALAKRISHNAN
Original assignee: Sosaley Technologies Pvt. Ltd.
Priority date: 2018-12-06
Filing date: 2019-11-21
Publication date: 2020-06-11

Abstract

A cloud-based battery management system (100) to predict battery life and battery health is disclosed. The system (100) includes a battery management server (102) that establishes a connection with the one or more controllers (110), which are configured to collect battery data from plurality of sensors (114). The server (102) receives the battery data and determines a first dynamic characteristic indicative of state of charge (SOC) of each battery (112) over a predetermined period of time. Next, a second dynamic characteristic indicative of state of health (SOH) is determined based on internal impedance and the state of charge characteristic. The determined SOC characteristic and SOH characteristic are compared with a predetermined look up table and a battery health status is predicted based on the comparison. The system (100) provides output, which is based on the prediction, indicating battery health status to one or more devices (106-N).

Description

CLOUD-BASED BATTERY MANAGEMENT SYSTEM TO PREDICT

BATTERY LIFE AND BATTERY HEALTH

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims priority to and is a complete specification of Application No. 201841046113, titled“CLOUD-BASED BATTERY MANAGEMENT SYSTEM TO PREDICT BATTERY LIFE AND BATTERY HEALTH”, filed on December 6, 2018.

FIELD OF THE INVENTION

[0002] The disclosure relates generally to battery management system and, in particular, to systems and methods to monitor and predict battery life and to alert battery users.

DESCRIPTION OF THE RELATED ART

[0003] Battery technology has been rapidly developing and adopted in many industrial areas. For instance, batteries are widely used in electronic goods like mobile devices, automotive goods like cars, healthcare devices, and the like. Generally, batteries are classified into three major types: primary, secondary and reserve batteries. Primary batteries are portable and designed for single use and can be discarded once they have been discharged. Secondary batteries are rechargeable energy storage sources for electronic and electrical devices (i.e., recharged for several times), and reserve batteries are used for long term storage.

[0004] Secondary batteries, in particular, have capability to supply enormous amount of energy in relatively short period of time. Such batteries deliver energy to load, such as auto-motives, emergency equipment etc., based on their demand. As a result, batteries are also finding applications in missile launching, bomb fuses, torpedoes, and various weapon systems. Lead acid (Pb/PbCL), Nickel metal Hydride (NiMH), Lithium ion Polymer (LiPo), Lithium Sulphur Dioxide (L1SO2) are some of the examples of secondary batteries.

[0005] The management of batteries has gained relevance with the universal adoption of batteries. There is a growing requirement to understand the performance, life, and health, of batteries over a period of time. Battery health plays a major role to avoid battery explosion and early diminishing of the life of the battery. Many battery- associated hazards, such as battery acid, flammable gases, electrical shock, etc., also need to be predicted in advance. Hence, battery management plays a vital role wherever battery is utilized to form as an energy source.

[0006] Battery management system (BMS) is an electronic system associated with a battery pack, which monitors and manages electric and thermal state of batteries in a safe manner by controlling battery environment. BMS also provides communication between the battery system and other macro- system controllers. Examples of such systems include vehicle management system (VMS), electric vehicles and energy management system (EMS), UPS and inverters. Generally, battery management includes ensuring that the battery operates in a safe operating area, monitoring battery state and performance parameters, reporting battery data, etc. In order to extend the battery life and to alert the user in every state of the battery, including charging and discharging, there is a requirement for an improved battery management system.

[0007] Various publications have attempted to address some of the challenges associated with determining battery parameters remotely. For instance, W02018091904A1 discloses a computer-implemented method for determining a state of health of a battery and providing alerts. EP2980596A1 discloses a method and apparatus for estimating state of battery. US20180095141A1 discloses a method and apparatus for determining the state of health and state of charge of lithium sulphur batteries. US10035427B2 discloses a method and device for the control of operating parameters of an electrical storage device, wherein said operating parameter influences a state of aging of an electrical energy storage device. However, there are no publications that discuss calculation and prediction of health and life of batteries with high accuracy.

SUMMARY OF THE INVENTION

[0008] According to one embodiment of the present subject matter, a cloud-based battery management system is disclosed. The system includes one or more controllers communicatively coupled to a plurality of sensors configured to measure battery data associated with the one or more batteries of a plurality of entities. The system includes a battery management server comprising a processing unit and a memory unit, the processing unit coupled to the memory unit, wherein the processing unit is configured to: establish a connection with the one or more controllers, wherein the one or more controllers are configured to collect battery data from the plurality of sensors. The processing unit receives the battery data from the one or more controllers associated with the one or more batteries supplying a load. The processing unit determines a first dynamic characteristic indicative of state of charge (SOC) of each battery over a predetermined period of time. Next, the processing unit determines a second dynamic characteristic indicative of state of health (SOH) based on internal impedance and the state of charge characteristic. The determined SOC characteristic and SOH characteristic are compared with a predetermined look up table and a battery health status is predicted based on the comparison. The server provides output indicating battery health status to one or more devices, wherein the output is based on the prediction.

[0009] According to another embodiment of the present subject matter, a method of monitoring and predicting battery health status associated with one or more batteries of a plurality of entities communicatively coupled to one or more controllers is disclosed.

The method includes establishing, by a processing unit, a connection with the one or more controllers, wherein the one or more controllers are configured to collect battery data from a plurality of sensors. The processing unit receives the battery data from the plurality of sensors associated with multiple batteries supplying a load. Next, the method determines a first dynamic characteristic indicative of state of charge (SOC) of each battery over a predetermined period of time. A second dynamic characteristic indicative of state of health (SOH) is determined based on internal impedance and the state of charge characteristic. The determined SOC characteristics and SOH characteristics are compared with a predetermined look up table. A battery health status is predicted based on the comparison and output indicating battery health status is provided to one or more devices, wherein the output is based on the prediction.

[0010] In various embodiments, the sensors include one or more of a voltage sensor, a current sensor, and a temperature sensor. The battery data includes voltage characteristics, current characteristics, and temperature characteristics. The voltage characteristics, current characteristics, and temperature characteristics includes one or more parameters selected from charging and discharging voltage, time to charge, initial discharge rate, temperature variations in the positive terminal of the battery with respect to internal chemical change, charge cycles of the battery, sulfation, and lead stratification. In some embodiments, the processing unit and the controller establish the connection through TCP handshake or a three-way handshake protocol. In some embodiments, the one or more controllers include a master controller and one or more slave controllers, and wherein the slave controllers are coupled to the plurality of sensors to monitor and communicate the battery data to the master controller. In another embodiment, the plurality of sensors are smart sensors and configured to operate as slave controllers and the controller is configured to operate as a master controller. In some embodiments, the server includes a network device communicatively coupled to the plurality of devices and a plurality of entities over a network, wherein each electronic entity comprises one or more batteries.

[0011] In various embodiments, the state of charge (SOC) is determined based on at least Nernst equation, coulomb counting, and depth of discharge. In some embodiments, establishing the connection includes: initiating a connection through TCP handshake or three-way handshake method; receiving the battery data on activation of the connection; and transmitting an acknowledgement signal to the controller to confirm the connection and/or reception of the battery data. In some embodiments, the look up table provides non-linear model of battery health status. In some embodiments, the method further includes creating the look up table by determining one or more initial table entry values of regular discharge points for a battery. A linear model of a look up table for the battery based on the determined table entries is obtained. Battery voltage data and status are monitored over a period of time. The look up table is updated in real time based on the monitoring. A non-linear model of the look up table is obtained based on the updated look up table for future battery health computations.

[0012] This and other aspects are disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention has other advantages and features which will be more readily apparent from the following detailed description of the invention and the appended claims, when taken in conjunction with the accompanying drawings, in which:

[0014] FIG. 1 illustrates a system environment of battery management system, according to an embodiment of the present subject matter.

[0015] FIG. 2A and FIG. 2B illustrate battery management system for an automobile and an e-rickshaw, according to an embodiment of the present subject matter.

[0016] FIG. 3A illustrates architecture of the battery management system, according to an embodiment of the present subject matter.

[0017] FIG. 3B illustrates architecture of the battery management system and the controller devices, according to an embodiment of the present subject matter.

[0018] FIG. 4 illustrates a diagram for establishing connection between a master controller and a battery management system, according to an embodiment of the present subject matter.

[0019] FIG. 5 illustrates a method of monitoring and predicting battery health status associated with one or more batteries of a plurality of entities, according to one embodiment of the present subject matter.

[0020] FIG. 6 illustrates a method of SOC and SOH calculation, according to one embodiment of the present subject matter.

[0021] FIG. 7 illustrates a method of creating a look up table, according to one embodiment of the present subject matter

[0022] FIG. 8 illustrates battery management application architecture, according to one embodiment of the present subject matter.

[0023] FIG. 9A, FIG. 9B, and FIG. 9C illustrate block diagrams of ZigBee slave device, current slave device, and wired slave device, according to one embodiment of the present subject matter. [0024] FIG. 10A and FIG. 10B illustrate block diagrams of slave device and master device for mobile battery devices and master device for mobile batteries, according to one embodiment of the present subject matter.

[0025] FIG. 11A and FIG. 11B illustrate block diagram of slave device with communication blocks and master device with communication blocks, according to one embodiment of the present subject matter.

[0026] FIG. 12 illustrates a graph depicting SOH calculation, according to one example of the present subject matter.

[0027] FIG. 13 illustrates a graph interpolation method, according to one example of the present subject matter.

[0028] FIG. 14: illustrates a change in voltage drop with time, according to one example of the present subject matter.

[0029] FIG. 15: illustrates a voltage drop difference with respect to the SOH, according to one example of the present subject matter.

[0030] FIG. 16A and FIG. 16B illustrate trends for SOC data for various SOH of a battery during charging and discharging, respectively, according to one example of the present subject matter.

[0031] FIG. 17 illustrates voltage drop trend with respect to SOH, according to one according to one example of the present subject matter.

[0032] FIG. 18 illustrates number of cycles for calculated SOH, according to one example of the present subject matter.

DETAILED DESCRIPTION

[0033] While the invention has been disclosed with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt to a particular situation or material to the teachings of the invention without departing from its scope.

[0034] Throughout the specification and claims, the following terms take the meanings explicitly associated herein unless the context clearly dictates otherwise. The meaning of "a", "an", and "the" include plural references. The meaning of "in" includes "in" and "on." Referring to the drawings, like numbers indicate like parts throughout the views. Additionally, a reference to the singular includes a reference to the plural unless otherwise stated or inconsistent with the disclosure herein.

[0035] The various architectural components of the present invention may be distributed across various special purpose or general purpose computing devices including various hardware components. The components may also encompass electronic, electrical, automotive systems and machines using one or more batteries. The terms“systems”,“client devices”,“computing devices” encompass devices, such as servers, desktop computers, laptop computers, tablet computers, personal digital assistants (PDA), smartphones, mobile phones, smart devices, appliances, sensors, or the like. The systems may include processing units, memory units, video or display interfaces, input/output interfaces, video or audio recording units, buses that connect the various units, network interfaces, peripheral interfaces, and the like. Regardless of the device type or the processing capability of the client, most client devices may be operated by a user in either an online or offline state.

[0036] The terms“mobile device”,“smart device”,“cellular device”, and“wireless device” may be used interchangeably and refer to any one of the various cellular telephones, smart phones, multimedia enabled cellular telephones and similar entities capable of sending and receiving wireless communication signals. In an embodiment, the wireless device is a cellular handheld device (e.g., a mobile device), which can communicate via a cellular telephone communication network. The terms “app”, “application”,“program”, and“software” may be used interchangeably and may include standalone applications, SDKs, and modules of applications or operating systems.

[0037] The invention in its various embodiments proposes a cloud-based battery management system to monitor battery parameters and predict battery life. The present subject matter includes a method and system for predicting accurate calculation of battery parameters. Further, the present subject matter also provides a battery management platform and associated application to users for providing alert notifications indicating battery health and life.

[0038] A system environment for battery management system to monitor battery parameters and predict battery life is illustrated in FIG. 1, according to one embodiment of the present subject matter. The cloud based battery management system 100 includes one or more controllers 110, which are communicatively coupled to a plurality of sensors 114 that are configured to measure battery data associated with one or more batteries 112 of a plurality of entities 104-1, 104-2,..., 104-N. The system 100 further includes a battery management server 102, a plurality of devices 106-1, 106-2, ..., 106-N, communicating with each other over a network 108. In various embodiments, the units 102, 104, 106 and other components in FIG. 1 may be computing devices, such as servers, desktop computers, laptop computers, tablet computers, personal digital assistants (PDA), smartphones, mobile phones, smart devices, appliances, or the like. The computing devices may include processing units, memory units, network interfaces, peripheral interfaces, and the like. Some or all of the components may comprise or reside on separate computing devices or on the same computing device.

[0039] In some embodiments, the electronic entities 104 may be any non- stationary battery powered electronic system, such as automobiles or e-rickshaws, and the like. In some embodiments, the electronic entities 104 may be any stationary battery powered electronic device or electrical circuitry, such as power inverters that change direct current to alternate current. The electronic entities 104 may be coupled to one or more controller devices 110 configured to collect battery data associated with the batteries 112. The battery data may include parametric information indicating status of the battery 112, such as voltage, current, temperature, etc.

[0040] In some embodiments, the one or more controllers 110 may include a master controller and plurality of slave controllers. The slave controllers may be coupled to plurality of sensors 114 to monitor and communicate the battery data to the master controller. The sensors are attached to the batteries of electronic devices. The sensors 114 are configured to measure the battery data. The slave controllers may include a ZigBee slave, current slave, the wired slave, etc. The slave controllers may include sensors that monitor voltage, current, temperature, etc., of the battery and communicate with external systems. The slave controller devices may be configured to monitor the voltage, current, temperature, etc., of the battery of the electronic device entities 104 and communicate the same to the master controller device. The measured sensor data may be communicated to the controller device 110 through wired technologies, such as RS485 serial link, or through wireless technologies, such as ZigBee module. In various embodiments, the sensor data may be communicated to the server 102 over the network 108.

[0041] In various embodiments, the server 102 may facilitate an online platform that may be accessed by a user, via the device 106, for obtaining information associated with battery. In some embodiments, the devices may be configured to utilize various communication protocols, such as Global System for Mobile Communications (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Bluetooth, High Speed Packet Access (HSPA), Long Term Evolution (LTE), 5G, 5G-New Radio, and Worldwide Interoperability for Microwave Access (WiMAX). [0042] In some embodiments, the battery management system 100 may manage the battery life and health of a mobile system or machine. Batteries 112 in automobiles may be monitored and managed as shown in FIG. 2 A and FIG. 2B, according to another embodiment of the present subject matter. The battery management system environment for mobile batteries, as shown, may include an automobile 202 and battery 204 in communication with a mobile device 206. The mobile device 206 may communicate with controller (not shown in figure) to receive battery data through a Bluetooth connection. In some embodiments, the mobile device 206 may be configured to run an application associated with the battery management system platform by syncing with the cloud network 108. The application may allow a user to receive alerts, monitor status, transactional data through a simple user-interface. Similarly, battery in mobile or moving systems, such as E-rickshaws 208, may also be monitored using the battery management system 100.

[0043] An architecture diagram of the server 102 is illustrated in FIG. 3A and FIG. 3B, according to an embodiment of the present subject matter. The server 102 may include one or more processing units 302, a memory unit 304, a network device 306, user interface 308, a second memory unit 310 and other subsystems 312. The network device 306 connects to the plurality of devices 106-N and the plurality of entities 104-N over the network 108. The memory unit 304 may include a plurality of modules to be executed by the processing units 302. The plurality of modules may include a data management module 314, a user management module 316, a battery status module 318, an archival data module 320, a settings module 322, and an export module 324. In various embodiments, the modules may be implemented as one or more software modules, hardware modules, firmware modules, or some combination of these.

[0044] The second memory unit 310 may include instructions to monitor and predict battery health status associated with one or more batteries 112 of electronic entities 104. The processing unit 302 may execute the instructions to establish a connection with the one or more controllers 110, which are configured to collect battery data from the plurality of sensors 114. The processing unit 302 receives the battery data from the one or more controllers 110 associated with the one or more batteries 112 supplying a load. The processing unit 302 may determine a first dynamic characteristic indicative of state of charge (SOC) of each battery 112 over a predetermined period of time. Next, the processing unit 302 may determine a second dynamic characteristic indicative of state of health (SOH) based on internal impedance and graph interpolation of the state of charge characteristic. The determined SOC characteristic and SOH characteristic may be compared with a predetermined look up table and a battery health status may be predicted based on the comparison. Outputs, such as alerts, indicating battery health status based on the prediction, may be provided to one or more devices 106-N.

[0045] The second memory unit 310 may be a physical storage media, such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, non-volatile storage, magnetic disk storage or other magnetic storage devices, or any other medium. In various embodiments, the memory or storage components may include fixed media a fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flash memory drive, a removable hard drive, an optical disk). Other examples may include RAM, dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), or any other type of media suitable for storing information. In various embodiments, the memory units may be used to carry or store desired program code means in the form of computer- executable instructions or data structures and, which can be accessed by a general purpose or special purpose computing device. The computer-executable instructions may include, for example, instructions and data which cause any general or special purpose computing device to perform a certain function or group of functions. [0046] The server 102 receives the battery data from the master controller 326 through wireless communication as shown in FIG. 3B. The master controller 326 obtains the battery data from the slave controller 328 which is coupled to a plurality of sensors 114 including, but not limited to, temperature sensor 330, voltage sensor 332, and a current sensor 334. The plurality of sensors 114 may be attached to the batteries 112 of the electronic entities 104. In some embodiments, the plurality of sensors 114 may be smart sensors that may monitor, examine, and communicate the battery data. The smart sensors may operate as a slave device and the controller 110 may operate as master device. In some embodiments, the electronic device 104 may be in constant communication with the server 102 regardless of the device location.

[0047] The server 102 and the controller 110 may establish a connection as illustrated in FIG. 4, according to one embodiment of the present subject matter. The plurality of batteries 112 of the electronic entities 104 are communicatively coupled to the controller 110. The controller 110 and the processing unit 302 in the server 102 may establish a connection, which includes initiating the connection through TCP handshake or three-way handshake method at step 402. On activation of the connection, the battery data collected by the controller 110 may be received at the server 102 at step 404. If the connection is not alive, then subsequent attempts to communicate the data is performed. When the connection is activated an acknowledgement signal is transmitted to the controller 110 to confirm the connection and/or reception of battery data at step 406. In some embodiments, the acknowledgement signal sent by the server 102 may include that the connection is interrupted and disconnected.

[0048] On reception of the battery data, the server 102 may be configured to predict battery life and battery health based on the received data. A flow diagram broadly illustrating the functions performed by the server 102 is shown in FIG. 5, according to some embodiments. The method 500 may include establishing a connection with the one or more controllers and receiving the battery data at blocks 502 and 504, as described earlier. The received data may be segregated battery-wise and converted into the essential parameters for display at block 506. The segregation of the data may further include pre-processing steps, such as data classification, data cleansing, file storage, and the like. The server 102 further determines a first dynamic characteristic indicative of state of charge (SOC) of each battery over a predetermined period of time. The determination may be based on Nemst Equation, coulomb counting, and depth of discharge obtained from battery data at block 508. The server 102 then determines a second dynamic characteristic indicative of state of health (SOH) based on lookup table and interpolation of two values in state of charge curve at block 510. In various embodiments, the lookup table may be created based on historical data associated with plurality of batteries 112. The battery data may include voltage characteristics, temperature characteristics, current characteristics, charging status, etc. The voltage characteristics, current characteristics, and temperature characteristics includes one or more parameters selected from charging and discharging voltage, time to charge, initial discharge rate, temperature variations in the positive terminal of the battery with respect to internal chemical change, number of charge cycles of the battery, sulfation, and lead stratification. The historical data may also include state of charge, state of health calculated based on Nemst equation.

[0049] In some embodiments, the SOC and SOH may be calculated based on a plurality of data including, but not limited to, charging and discharging voltage, variations in the time taken to get charged, first few discharging current rates, temperature variations in the positive terminal of the battery with respect to internal chemical change, number of charge cycles the battery has undergone till the present time, sulfation, lead stratification, etc. The internal chemical change may refer to the sulfation of a lead acid battery or particles of lithium interacting with iron rod in lithium battery.

The SOC and SOH may depend on temperature variation of the device. For instance, the device must ideally operate in predetermined range of temperatures when the battery is charging or discharging as shown in Table 1.

Table 1: Temperature dependence of SOC and SOH

[0050] The determined SOC and SOH may be compared with a predetermined look up table at block 512. The look up table provides non-linear model of battery health status. Based on the calculated SOC and SOH, the system generates output, which includes alerts that are sent to user devices to avoid battery abuse and extend the battery life at block 514. The alerts may be provided to the user devices 106-N over the network periodically. For instance, the battery performance and conditions may be provided to the user devices 106-N every week or day. In some embodiments, alerts regarding battery health may be provided to the user devices 106-N before months. In various embodiments, the alerts may be generated and executed for every battery parameter, SOC and SOH of individual battery for any predetermined criteria violation.

[0051] A flow diagram of the SOC and SOH calculation is illustrated in FIG. 6, according to one embodiment of the present subject matter. Upon initializing 601 the method, it is determined whether an initial state of charge can be calculated at 602. If a first flag has been set, then the initial SOC may be calculated at 603. The calculation may be based on Nernst equation, which is derived from Gibb’s free energy under standard condition. The difference between the E_reduction and E_oxidation, i.c., State of Charge (SOC) may be calculated with respect to various voltages of the battery 112. For instance, the highest voltage of the battery V_max, lowest voltage of the battery V_min, instantaneous battery voltage V may be used for calculating the SOC. The SOC is the rated difference between the V_max and V or the rated difference between V and V_min. Similarly the instantaneous charging or discharging percentage may be calculated with respect to coulomb counting and battery Ah over every minute. In one embodiment, the initial SOC may be determined as follows:

[0052] SOC (t₀) = [-I ZZSEL * 100] or SOC (t₀) = 100 - [ ( Vmax P )

(Vmax min) ⁽ Vmax^~'^min ⁾

100]

[0053] If the flag has not been set, then the battery mode may be checked at 604. The method determines whether the battery is in standby mode or not by checking if the current is less than 1A. If the current is not less than 1A, then coulomb counting may be performed for every minute to estimate the SOC at block 605. If the current is less than 1A, then the previous SOC and SOH is displayed at block 606. The process may be reiterated continuously for every data packet for over 60 seconds for SOC and SOH calculation at block 607.

[0054] Further, the instantaneous SOC may be calculated at block 608. The instantaneous SOC may be calculated based on SOC(t) = SOC(t₀) ±

* 100 /(Battery_Ah * 60) . Next, the method determines whether the battery 112 is charging or not at 609. If the battery 112 is charging, then the SOC during charging is determined at block 610. The SOC during charging may be the aggregate of SOC(to) and SOC(t). If the battery 112 is not charging, then SOC during discharging is determined at 611. The SOC during discharging may be the difference between SOC(to) and SOC(t). Further, the state of health SOH may be determined during the discharging cycle for every minute at block 612. In some embodiments, error correction may be performed with respect to previous SOH value of the battery.

[0055] Based on the calculation of SOH, the battery capacity is determined and every point of capacity fade corresponds to reduction in battery health. The capacity fade may happen for different reasons, such as irregular charging and discharging, lead stratification, and sulfation. Such situations may also lead to battery deterioration. The battery deterioration due to irregular charging may be avoided by monitoring the time remaining and cycle life of the battery.

[0056] Time remaining during discharging may be estimated from Peukert’ s law. From the battery capacity*(C), discharging current (I_d), the battery hour rating (R), Peukert’s exponent for lead acid battery (n), Peukert’s equation as follows:

Q

Discharging times remaining, T_d =

d)

£]ⁿ

Peukert’ s capacity of the battery, C_p = R

.R.

Charging times remaining, T_c = C/I_c

[0057] Further, battery deterioration due to lead stratification and sulfation may be prevented by applying equalizing charge. The lead stratification may be quantified based on the variation of SOH over time. The extent of suflation may be indirectly reflected in the health of the battery 112. Equalizing a battery 112 may be done by applying a 10% higher voltage than the recommended charge voltage. The high level of charge frees the sulfur ions back into the electrolyte and desulfates it. The high voltage also forces the acid accumulated at the bottom of the cell to rise up and mix equally with the water. Thus, stratification problem may also be reversed.

[0058] In some embodiments, a method of creating look up table is illustrated in

FIG. 7, according to one embodiment of the present subject matter. The method may include determining one or more initial table entry values of regular discharge points for a battery 112 at block 702. A linear model of a look up table for the battery 112 may be obtained based on the determined table entries at block 704. The battery voltage data and status may be monitored over a period of time at block 706. Based on the monitoring, the look up table is updated in real-time at block 708. The battery health is estimated based on repeated voltage drops with respect to time during battery discharge at block 710.

Finally, a non-linear model of the look up table is obtained based on the updated look up table for future battery health computations at block 712. [0059] In various embodiments, the battery management system 100 provides the platform for remotely determining battery parameters and predicting battery life and health. The platform may be accessed from the user device 106-N through a BMS cloud application. Application architecture is illustrated in FIG. 8, according to an embodiment of the present subject matter. As known in the art, design architecture may involve seven OSI layers to collect the data from embedded master controller device 110. Various functions involving mail services, directory services, network resource, etc., are provided by the application layer of the OSI.

[0060] The BMS cloud web application may use wireless communication to receive the data from embedded device, and for multiple client multiple IP address may be provided. Data format involved in data transmission for BMS cloud web application may contain start byte, command byte, data byte, error code, CRC byte, status byte, reserved byte and end byte. Data Format may be as shown below:

Table 2: Data Format

[0061] The data packet may include 4 parameters namely voltage, temperature, current, and status. Based on the status, SOC and SOH value may be calculated for each and every battery.

[0062] The BMS cloud application may perform five major functions through threads or modules to execute various operations. The modules may refer to any of the various subsets of software code, threads, or sub-routines. A data collection module 802 may run in background to collect data from embedded devices through connection oriented protocol and the data may be segregated for different batteries. The segregated data may be aligned and stored in file system. There are many number of JAR files involved to carry the mentioned process. In various embodiments, the BMS cloud application uses HTTP protocol in application layer. [0063] The architecture illustrates the various functions including collecting data from a controller device 110. The architecture may include other modules for user management, battery status, archival data, settings, and export/report. A user management module 804 may involve user authentication. The user may be provided individual username, password for every client admin and client user. The client admin may be permitted to modify battery details as follows: product ID, add battery, remove battery, etc. The client user may view the battery details and the battery modification would be denied to them. The users may be allowed to view it, but the modification will be prohibited to them for security reasons. The data may be segregated from consolidated file system according to every user.

[0064] A battery status module 806 may display data according to user setup. When the user enters the battery page or dashboard, the module requests data for presentation related to all the batteries pertaining to the authenticated user. From the data stream associated with first ten set of batteries data may be displayed initially and the next set of battery data may be displayed while traversing next pages through the application. Alternatively, an option may be provided to view particular controller data. Users may also be provided alert-wise data view according to the selected battery. Live status may be displayed based on whether HTTP session is in online or offline condition. The user may come to know whether the data is being received from embedded device or not.

[0065] An archival data module 808 may be configured to store and retrieve data.

The user may view the archived data report, which may include battery ID, date and time, voltage, temperature, SOC in percentage, SOH, current, status, asset-code, and location. Users may be provided the option to view individual battery records as well as consolidated battery records. SOC and SOH data may be calculated using trained machine learning algorithm. For every individual battery, the SOC and SOH value may be calculated. Asset-code battery may be taken from user’s settings and location of the mobile battery may be taken from the embedded device. Embedded device will collect the location information of mobile battery using GPS. Old data may be consolidated and archived and may not be displayed in view-data. Whenever the user desires to look up the old datasets, the archival option may be utilized. Some set of data based on receiving date of the battery may be viewed in archival option. User may also view the archival data normally.

[0066] A settings module 810 may be configured to vary battery settings for client admin and client user. Client admin has three categories of settings to modify the batteries details and client user has two categories of settings. Client user can only view the batteries settings and they may not be provided modify privileges. An export module 812 may be configured to enable client admin and user to export the report from any page of BMS cloud application. Export operation may prompt three options, namely all data export, date- wise export, and alert- wise export.

[0067] Referring back to the hardware aspects of FIG. 3B, the slave controller devices 328 coupled to the electronic entities may include various components. In various embodiments, the slave controller devices 328 may include wireless slave device, current slave device, and a wired slave device A block diagram of the wireless

(ZigBee) slave device, current slave device, and a wired slave device is illustrated in

FIG. 9A, FIG. 9B, and FIG. 9C, according to an embodiment of the present subject matter. The ZigBee slave device may include a microcontroller 902 configured to received battery parameters from sensors 114. A voltage sensing unit 904 and a temperature sensing unit 906 may be used for obtaining voltage and temperature data from the battery 112 of the electronic entity 104. The microcontroller 902 may receive the voltage and temperature data through an operational amplifier 908. The ZigBee slave device may also include a power supply unit 910 and a wired communication unit 912, such as RS485 unit, coupled to an isolator unit 914. Further, the microcontroller 902 is coupled to a ZigBee unit 916, which is configured to provide wireless communication.

[0068] Block diagrams for current slave device and wired slave device is illustrated in FIG. 9B and FIG. 9C, according to one embodiment of the present subject matter. The current slave device and the wired slave device include voltage sensing unit, temperature sensing unit, operational amplifier, power supply unit, RS485 unit, and isolator unit. The current slave device further includes a current sensing unit 918 to measure current.

[0069] In other embodiments, the battery management system for a battery that is mobile also includes a slave device 902 and a master device 904 as shown in FIG. 10A and FIG. 10B. The slave device 1002 of the mobile BMS may include voltage sensing unit 904, temperature sensing unit 906, operational amplifier 908, power supply unit 910, RS485 unit, and isolator unit. Further, the slave device may include a wireless communication unit 1006, such as a Bluetooth unit. The master device 1004 of the mobile BMS may include a microcontroller coupled to power supply unit 910, wireless communication unit, such as ZigBee unit 1008 and Bluetooth unit 1010. The master device 1004 may also be configured to communicate using wireless fidelity (WiFi) 1012 and GPRS/GSM protocols 1014 for communicating with the server 102.

[0070] A block diagram of the master and slave devices coupled to various communication modules is illustrated in FIG. 11A and FIG. 11B, according to another embodiment of the present subject matter. The slave device block 1102, as shown in FIG. 11 A, may include a microcontroller configured to communicate using various communication protocols, such as inter-integrated protocol (I2C) 1104 and serial peripheral interface (SPI) 1106. The microcontroller may be coupled to analog to digital converter (ADC) 1108 and Universal Asynchronous Receiver/Transmitter (UART) 1110 for asynchronous serial communication. The slave device may also include power supply units 1112. The slave device may also include RS485 unit 1114 for wired communication and a power supply unit 1116 with varying voltage inputs of 3.3V and 5V.

[0071] Further, the master device block 1118, as shown in FIG. 1 IB, may include a microcontroller configured to communicate using various communication protocols, such as inter-integrated protocol (I2C) 1104 and serial peripheral interface (SPI) 1106.

The microcontroller may be coupled to analog to digital converter (ADC) 1108 and Universal Asynchronous Receiver/Transmitter (UART) 1110 for asynchronous serial communication 1012. The slave device may also include RS485 unit 1114 for wired communication and a power supply unit 1112. Additionally, the master device 1118 may also include Controller Area Network (CAN) protocol 1120 and a SD card 1122 for communication. The master device may also include universal serial bus (USB) connection for transfer of data with other devices.

EXAMPLES

[0072] The server 102 receives the raw battery data from embedded controller device 110, which was connected to a plurality of electronic entities 104. The data reception at the server system 102 was configured to be performed every 2 seconds. The server system 102 segregated the data for each controller 110 and stored the segregated battery data in memory units. The data was converted into decimal format such that user can understand. The SOC-SOH value associated with each battery 112 was calculated from voltage and current values obtained from the raw data and the converted data was compared with criteria of battery standards. Alerts are configured to be generated if any predetermined criteria are violated. The converted data and alerts were stored in file system and the alert repetition frequency was configurable as per the user requirement. The battery-wise data was viewable through the application and the battery details were listed out for every controller 110.

[0073] As discussed earlier, the state of health of the battery 112 decreases over a period of time due to irregular charging and discharging, lead stratification, and sulfation. It was experimentally determined and affirmed that that the state of health of a battery 112 is associated with internal impedance of the battery 112. The resistance, capacitance, and inductance, which are linked to the internal impedance, were used for calculation of initial SOH. Initial SOH is calculated from maximum current with their terminal voltage drawn from battery during discharging and is given by (Initial standby voltage - Load voltage)/ Measured Current. The SOH calculation graph is shown in FIG.

12. The graph shows that when time increases SOH of the battery will decrease i.e., capacity fade occurs due to sulfation, lead stratification and irregular charging or discharging.

[0074] Further, the instantaneous SOH was calculated based on a look up table, which depicts that the increase in internal impedance increases the capacity fade, i.e., SOH value decreases due to sulfation process. The look up table is as follows:

Table 3: Instantaneous State of Health (SOH) Lookup Table

[0075] The above table shows the linear prediction of battery SOH. In case of non linear, the interpolation method between two points was followed. The interpolation graphs are as shown in FIG. 13. Similarly, the change in voltage drop with time for different current values is observed and depicted in a graph as illustrated in FIG. 14. Further, the voltage drop difference with respect to the SOH was captured and a graph illustrating the same is shown in FIG. 15.

[0076] Further, the health of the battery 112 was also predicted under non-linear conditions using a lookup table method. A dedicated lookup table was created for each battery that was used for examination and experimentation purpose. The lookup table was created based on the method described earlier, wherein initial table entry values of five regular discharge points were determined for a full load condition from fully charged to fully discharged status. Over a period of time by collecting the data on battery voltage and status conditions, the table was continually populated with the actual values. With repeatability of situations that involve voltage drop with respect to time during discharge, the battery’s health was computed. Thus with time the linear model was getting transformed into a non-linear model by updating the non-linear values involved in observation of the battery and the table was updated.

Example 1: State of charge (SOC) calculation for charging and discharging

[0077] State of charge of the battery 112 during charging or discharging was calculated by coulomb counting at regular intervals. For the use case we calculated every minute of instantaneous state of charge, which is either added to or subtracted from the initial SOC(to) for charge and discharge, respectively. State of charge of the battery during standby is calculated by using the formula:

(OCV— Load voltage )

5OC(t₀) =

Upper threshold voltage— Lower threshold voltage

[0078] During the time of charging the battery’s charger voltage was measured and the battery 112 was charged in constant current constant voltage topology. There was an increase in the voltage of the battery 112 till its cycle value for the constant current that was being supplied to it. After reaching the float voltage the battery’s current started decreasing and reached Ai which was very close to zero current to float charge the battery 112. During the constant current phase by taking voltage, current and time as a function the SOC is incremented from the previous value. Instantaneous SOC was calculated by the ratio of current to the Ah of the battery with respect to every minute. The instantaneous SOC may be given by:

[0079] By this way the state of charge of the battery 112 was calculated for both charging and discharging conditions. The charging trend for the battery with SOH degradation is illustrated in FIG. 16A and the discharge trend for the battery with SOH degradation is illustrated in FIG. 16B. The experimental data associated with the trends were recorded in Table 4 and Table 5.

Table 4: SOC data for various SOH over time during charging

Table 5: SOC data for various SOH over time during discharging

Example 2: Battery health calculation using voltage drop

[0080] The SOH of the battery corresponds to the health of the battery 112 and the formula used for computing the health of the battery 112 is as follows:

100

SOH(t₀ ) = 100 -

[0081] For an ideal case, a fully charged battery during discharging, the voltage drop must be less than or equal to 0.2V. If the voltage drop is greater than 0.2V then the battery's health is considered to be in decline. In case if the voltage-drop of the fully charged battery is greater than 2.5 then the battery is declared as dead. The voltage drop trend with respect to SOH is illustrated in FIG. 17 and the corresponding data is provided in Table 6.

Table 6: Voltage drop for various battery SOH

[0082] The number of charge-discharge cycles can be defined as one complete cycle of charging and discharging that a battery undergoes. A battery is said to be fully charged only when it regains the Ah that it has lost during its discharge. The Ah that is mentioned in the above point corresponds to the usable Ah value of the battery 112. The count of the charge-discharge cycle is incremented based on the ratio of Ah value that is measured during charging and discharging, i.e., the accumulated value of Ah value to its maximum capacity both in charge and discharge time. At the end of the calculation the user will be displayed battery's life in terms of the cycle that it can undergo with the existing health.

Example 3: Battery life calculation using Ah of the battery and charge-discharge cycles

[0083] The entire life of a battery 112 is usually specified by the manufacturers and how long the battery would last is an important parameter to be determined. This prediction was performed with the help of the same battery health using the earlier model mentioned to calculate battery’s health. Battery’s life will be calculated by the percentage of battery’s health with the number of cycles the manufacturer specified for a year/years.

Cycles Remaining (/₀)

SOH(t_Q ) _* Manufacturer specified charge discharge cycles

100

[0084] FIG. 18 illustrates graph depicting number of cycles for different values of the calculated SOH. For example, the number of charge-discharge cycle of lead acid battery lies in the range of 800-1000 cycles. The cycle time defined as time taken by the battery to undergo one complete charging (from 0% to 100%) and complete discharging (100% to 0%). The cycle time is not considered during the stand-by-mode. During calculation of cycles charge and discharge 90% accumulated value will be considered as 100% because the battery undergoes self-discharging and float charge undergoes at the time of charging.

Table 7: Number of cycles for calculated SOH

[0085] Based on the above stated algorithm the calculations are performed for the individual batteries and the results of state of charge, state of health, charge-discharge cycle, life expectancy with the effect of battery usage such as applied load current and charging modes are being displayed to the user.

[0086] The above subject matter and its embodiments provide method and system to predict battery health and battery life based on accurate determination of SOC and SOH. The present subject matter provides alerts associated with battery parameters to users through a cloud platform. The system processes the measured battery parameters to estimate potential risks and failure associated with the batteries. The accuracy of the SOC and SOH calculation ensures that alerts provided to the users are genuine and timely, which allows users to efficiently use and maintain batteries. The battery management system allows safe usage of batteries, improves mitigation design from battery bound risks, and consequently enhances battery life. Further, the BMS platform enables communication of data and alerts in real-time.

[0087] Although the detailed description contains many specifics, these should not be construed as limiting the scope of the invention but merely as illustrating different examples and aspects of the invention. It should be appreciated that the scope of the invention includes other embodiments not discussed herein. Various other modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the system and method of the present invention disclosed herein without departing from the spirit and scope of the invention as described here.

Claims

We claim:

1. A cloud-based battery management system (100) comprising: one or more controllers (110) communicatively coupled to a plurality of sensors (114) configured to measure battery data associated with one or more batteries (112) of a plurality of entities (104-N); a battery management server (102) comprising a processing unit (302) and a memory unit, the processing unit (302) coupled to the memory unit, wherein the processing unit is configured to: establish a connection with the one or more controllers (110), wherein the one or more controllers (110) are configured to collect battery data from the plurality of sensors (114); receive the battery data from the one or more controllers (110) associated with the one or more batteries (112) supplying a load; determine a first dynamic characteristic indicative of state of charge (SOC) of each battery over a predetermined period of time; determine a second dynamic characteristic indicative of state of health (SOH) based on internal impedance and the state of charge characteristic; compare the determined SOC characteristic and SOH characteristic with a predetermined look up table; predict battery health status based on the comparison; and provide output indicating battery health status to one or more devices (106-N), wherein the output is based on the prediction.

2. The system of claim 1, wherein the sensors comprise one or more of a temperature sensor (330), a voltage sensor (332), and a current sensor (334).

3. The system of claim 1, wherein the battery data comprises voltage characteristics, current characteristics, and temperature characteristics.

4. The system of claim 3, wherein the voltage characteristics, current characteristics, and temperature characteristics comprises one or more parameters selected from charging and discharging voltage, time to charge, initial discharge rate, temperature variations in the positive terminal of the battery with respect to internal chemical change, number of charge cycles of the battery, sulfation, and lead stratification.

5. The system of claim 1, wherein the processing unit (302) and the controller (110) establish the connection through TCP handshake or a three-way handshake protocol.

6. The system of claim 1, wherein the one or more controllers (110) comprises a master controller (326) and one or more slave controllers (328), and wherein the slave controllers (328) are coupled to the plurality of sensors (114) to monitor and communicate the battery data to the master controller (326).

7. The system of claim 1, wherein the plurality of sensors (114) are smart sensors and configured to operate as slave controllers (328) and the controller (110) is configured to operate as a master controller (326).

8. The system of claim 1, wherein the output comprises alerts to one or more devices (106-N) over a network (108).

9. The system of claim 1, wherein the server (102) further comprises a network device (306) communicatively connected to the plurality of devices (106-N) and a plurality of entities (104-N) over a network (108).

10. A method of monitoring and predicting battery health status associated with one or more batteries of a plurality of electronic entities (106-N) communicatively coupled to one or more controllers (110), the method comprising: establishing, by a processing unit (302), a connection with the one or more controllers (110), wherein the one or more controllers (110) are configured to collect battery data from a plurality of sensors (114); receiving, by the processing unit (302), the battery data from the plurality of sensors (114) associated with multiple batteries supplying a load; determining, by the processing unit (302), a first dynamic characteristic indicative of state of charge (SOC) of each battery over a predetermined period of time; determining, by the processing unit (302), a second dynamic characteristic indicative of state of health (SOH) based on internal impedance and graph interpolation of the state of charge characteristic; comparing, by the processing unit (302), the determined SOC characteristics and SOH characteristics with a predetermined look up table; predicting, by the processing unit (302), battery health status based on the comparison; providing, by the processing unit (302), output indicating battery health status to one or more devices (106-N), wherein the output is based on the prediction.

11. The method of claim 10, wherein the state of charge (SOC) is determined based on at least Nemst equation, coulomb counting, and depth of discharge.

12. The method of claim 10, wherein establishing the connection comprises: initiating a connection through TCP handshake or three-way handshake method; receiving the battery data on activation of the connection; and transmitting an acknowledgement signal to the controller to confirm the connection and/or reception of the battery data.

13. The method of claim 10, wherein the battery data comprises voltage characteristics, current characteristics, and temperature characteristics.

14. The method of claim 13, wherein the voltage characteristics, current characteristics, and temperature characteristics comprises one or more parameters selected from charging and discharging voltage, time to charge, initial discharging rates, temperature variations in the positive terminal of the battery with respect to internal chemical change, number of charge cycles of the battery, sulfation, and lead stratification.

15. The method of claim 10, wherein the look up table provides non-linear model of battery health status.

16. The method of claim 15 further comprising creating the look up table by: determining, by the processing unit (302), one or more initial table entry values of regular discharge points for a battery; obtaining, by the processing unit (302), a linear model of a look up table for the battery based on the determined table entries; monitoring, by the processing unit (302), the battery voltage data and status over a period of time; updating, by the processing unit (302), the look up table in real-time based on the monitoring; and obtaining, by the processing unit (302), a non-linear model of the look up table based on the updated look up table for future battery health computations.