Battery Pack Monitoring System

Abstract

A system and method for monitoring a battery at various stages of its life cycle is described. The battery can be monitored in both non-operating and operating states. The monitoring can be done wirelessly. The information gathered by monitoring the battery can be used to make decisions about the use of the battery.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application Serial No. 62 / 868,837, filed on June 28, 2019, with Attorney Docket No. G0766.70293US00, and entitled “BATTLE PACK MONITORING SYSTEM,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to systems and methods for monitoring battery packs. Background Art

[0004] The formation, production and deployment of batteries is a rapidly expanding growth area driven by the need for cleaner alternatives to internal combustion engines in a variety of vehicles, including passenger cars, trucks and ships. The scale of production of high-capacity batteries, especially lithium-ion batteries, is unprecedented. With this scale comes new challenges that have not been addressed before throughout the supply chain and throughout the battery life cycle. Summary of the invention

[0005] A system and method for monitoring a battery at various stages of its life cycle is described. The battery can be monitored in both non-operating and operating states. The monitoring can be done wirelessly. The information gathered by monitoring the battery can be used to make decisions about the use of the battery.

[0006] According to one aspect of the present application, a battery management system is provided, comprising: at least one processor; and a storage device storing processor executable instructions, which, when executed by the at least one processor, causes the at least one processor to: aggregate health status information of multiple batteries in a non-operating state. In some embodiments, the multiple batteries are a first plurality of batteries, and when executed by the at least one processor, the processor executable instructions cause the at least one processor to further aggregate health status information of a second plurality of batteries in a working state. In some embodiments, the health status information includes charging status information. In some embodiments, when executed by the at least one processor, the processor executable instructions cause the at least one processor to further store the health status information in a blockchain. In some embodiments, when executed by the at least one processor, the processor executable instructions cause the at least one processor to perform anomaly detection in the health status information of the multiple batteries. In some embodiments, when executed by the at least one processor, the processor executable instructions cause the at least one processor to provide a recommended use of a first battery among the multiple batteries.

[0007] According to one aspect of the present application, a method for managing a battery pack is provided, comprising: aggregating health status information of multiple batteries in a non-operating state at one or more remote locations. In some embodiments, the multiple batteries are a first plurality of batteries, and the method further comprises aggregating health status information of a second plurality of batteries in a working state. In some embodiments, the health status information comprises charging status information. In some embodiments, the method further comprises storing the health status information in a blockchain. In some embodiments, the method further comprises performing anomaly detection in the health status information of the multiple batteries. In some embodiments, the method further comprises recommending the use of a first battery among the multiple batteries. In some embodiments, the method further comprises, in response to analyzing the health status information, providing an updated sensing algorithm to a node configured to sense the health status information of the first battery among the multiple batteries.

[0008] According to one aspect of the present application, a system for monitoring battery health is provided, the system comprising: a wireless gateway arranged at a location including a plurality of batteries in a non-operating state, the wireless gateway being configured to wirelessly communicate with the plurality of batteries to exchange data about the health status of the plurality of batteries. In some embodiments, the wireless gateway is in operative communication with a battery life cycle insight system. In some embodiments, the wireless gateway is configured to pass a health status monitoring algorithm from the battery life cycle insight system to the plurality of batteries. In some embodiments, the wireless gateway is configured to pass data about the health status of the plurality of batteries to the battery life cycle insight system. In some embodiments, the wireless gateway is a first wireless gateway, and the system further comprises a second wireless gateway arranged near the first wireless gateway and configured to exchange data with the first wireless gateway. In some embodiments, the plurality of batteries include a first battery and a second battery, and the wireless gateway is configured to receive data about the health status of the first battery via the second battery. In some embodiments, the wireless gateway is configured to send firmware updates to the plurality of batteries. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Various non-limiting embodiments of the present technology are described herein with reference to the following drawings. It should be understood that these drawings are not necessarily drawn to scale. Items appearing in multiple drawings are represented by the same reference numerals in all drawings in which they appear. For clarity, not every component may be labeled in every drawing.

[0010] Figure 1 An example of a system for monitoring a battery pack according to a non-limiting embodiment of the present application is illustrated.

[0011] Figure 2A battery cell, a battery module, and a battery pack according to non-limiting embodiments of the present application are shown.

[0012] Figure 3 A subsystem including a wireless battery management system (WBMS) node and a gateway according to a non-limiting embodiment of the present application is illustrated.

[0013] Figure 4 A subsystem including a WBMS node and a gateway according to a non-limiting embodiment of the present application is illustrated.

[0014] Figure 5 A method for monitoring a battery throughout its life cycle is illustrated.

[0015] Figure 6 An example of a configuration for monitoring a battery in storage according to a non-limiting example of the present application is shown.

[0016] Figure 7 The functional modules of the battery insight lifecycle system service according to a non-limiting embodiment of the present application are shown.

[0017] Figure 8 An example of a method that may be performed by a battery management system incorporating anomaly detection and alarming is illustrated.

[0018] Fig. 9 A non-limiting example of a workflow according to an embodiment of the present application is illustrated. DETAILED DESCRIPTION

[0019] Aspects of the present application relate to monitoring of batteries. In some embodiments, battery packs can be monitored wirelessly. In some embodiments, monitoring can be performed in a non-operating state of the battery, in some embodiments in an operating state, and in some embodiments in a non-operating state and an operating state. Monitoring can be performed by wirelessly collecting data from a single battery. The data can relate to the health state of the battery, such as the state of charge. The data can be aggregated, for example in the cloud. The aggregated data can be analyzed and various actions can be taken as a result of the data analysis. Over time, the monitoring algorithm can be updated to ensure that the required type of data is collected and to ensure that high-quality recommendations are made based on data analysis. Using such a system, the entire battery pack located in different locations, usage states, and their life cycle stages can be managed intelligently and effectively.

[0020] As described, according to aspects of the present application, monitoring of the battery pack can be performed in a non-operating state of the battery in some embodiments, in an operating state of the battery in some embodiments, and in both a non-operating state and an operating state of the battery in some embodiments. In some embodiments, the battery can be monitored from manufacturing to deployment in different locations and applications. Each battery can have a sensor, examples of which are further described below, and the data can be collected and stored in the cloud. A management system can be used to monitor the health, location, and performance of the batteries, and managers can make decisions about what batteries to use / deploy based on this information. The management system can be used to monitor the batteries before, during, and / or after battery commissioning. A database of all batteries and their sensed parameters can be stored.

[0021] According to one embodiment of the present application, batteries are monitored in a non-operating state. Many types of batteries require long storage periods after manufacture and before deployment. Batteries can also be stored at different stages of their life cycle, such as between different uses of the battery. Wireless monitoring of such batteries enables accurate and efficient group management. For example, batteries that are below acceptable quality standards (e.g., battery health and / or performance) when stored can be identified and removed from the supply chain before deployment, saving the cost and effort of deploying non-functional batteries. Characteristics of batteries that can be monitored when in a non-operating state include, among others, the condition of the charge and casing.

[0022] According to some embodiments, monitoring a non-operational battery includes monitoring the battery when not under load, as opposed to monitoring the battery in an operational state. The type of monitor used can be accordingly configured to monitor conditions of interest without applying a load to the battery.

[0023] A central database can record information about individual batteries in a group. Monitoring analysis can be performed based on the recorded data to identify trends and characteristics of individual batteries. This knowledge can be used to make decisions about battery deployment, such as whether to deploy a specific battery, the type of application in which the battery is deployed, or whether to replace a specific battery. Other actions can also be taken based on the monitoring.

[0024] Figure 1 An example of a system for monitoring a battery pack according to a non-limiting embodiment of the present application is illustrated. The battery management system 100 includes a wireless battery management system (WBMS) mesh network 102 of WBMS nodes 104a...104n, a plurality of gateways 106a...106n, and a data aggregation and management module 108. The data aggregation and management module 108 implements a battery life cycle insight system (BLIS) service 110 and maintains a battery database 112.

[0025] The WBMS mesh network 102 includes WBMS nodes 104a, 104b, 104c ... 104n. The WBMS nodes include a battery and a sensor. In some embodiments, the sensor is integrated with the battery. In some embodiments, the sensor is attached to the battery, for example in the form of a dongle. Figure 2-4 A non-limiting example of a WBMS node is illustrated. Regardless of the form, the WBMS nodes 104a...104n are configured to wirelessly communicate with a gateway, as further described below. For example, they may send identifiers (battery cell IDs, battery module IDs, and / or battery pack IDs) to the gateway, which in turn may provide them to the BLIS service 110. The BLIS service 110 is maintained at a location remote from the battery.

[0026] Batteries, such as those constituting WBMS nodes 104a . . . 104n , may be comprised of battery cells grouped into battery modules, which in turn are grouped into battery packs. Figure 2 , a battery cell 202 may be the smallest discrete unit of a battery. Different companies may manufacture different types of batteries with different chemistries. Companies may have proprietary battery pack compositions. Battery cells 202 may be grouped into battery modules 204. A battery module 204 may include any suitable number of battery cells 202. Figure 2 In the non-limiting example, the battery module 204 includes two battery cells 202. However, the aspects of utilizing battery modules described herein are not limited to modules including any particular number of battery cells. The battery pack 206 includes a plurality of battery modules 204. In the non-limiting example shown, the battery pack 206 includes eight battery modules 204. However, the aspects of utilizing battery packs described herein are not limited to groups including any particular number of battery modules. Figure 3 and 4 As shown and described further below, the WBMS node additionally includes sensors and wireless communication mechanisms.

[0027] Return to Figure 1 , any suitable number of WBMS nodes 104a…104n may be part of the battery management system 100. In at least some embodiments, the WBMS nodes 104a…104n constitute a group of batteries. As non-limiting examples, a group may include tens of batteries, hundreds of batteries, or thousands of batteries. The WBMS nodes, or at least some of them, may be configured to communicate with each other, thereby forming a mesh network. In this way, data may be shared between WBMS nodes. For example, battery data from a WBMS node may be passed to another node, which may then be passed to a gateway. In addition, instructions or software updates may be passed from a gateway to a WBMS node, and then from that WBMS node to another WBMS node of the mesh network.

[0028] The WBMS nodes 104a ... 104n can be different types of batteries, including batteries manufactured by different manufacturers. In some embodiments, the batteries can all be of the same type, such as if the manufacturer is implementing the battery management system. However, the battery management system 100 can be implemented by an entity other than the manufacturer, and the manufacturer can use it to monitor different types of battery packs. For example, a distributor that distributes batteries from many different manufacturers can implement the battery management system 100 to monitor and manage the batteries it distributes for the different manufacturers.

[0029] The WBMS nodes 104a ... 104n can be in any suitable location, and in some cases, the location can change. Some WBMS nodes may be located in the same place, such as in a warehouse or other storage facility, while other nodes may be located in different locations. For example, some WBMS nodes may represent batteries deployed in the field, such as in an electric vehicle, a ship, or an aircraft, and therefore the location may change. In addition, the battery management system 100 can be used to monitor WBMS nodes during transportation (e.g., in a container).

[0030] The WBMS nodes 104a…104n can be in various states of use, as will be further described in more detail below. As described above, the battery management system 100 may require and provide monitoring of batteries in a non-operating state. One or more of the WBMS nodes 104a…104n may be in a non-operating state. For example, one or more of the WBMS nodes 104a…104n may be in storage, or transported from one location to another. Batteries typically spend a lot of time in a non-usage state before deployment or between different deployments. In this case, the batteries may degrade. Therefore, monitoring their health status only when in use risks losing valuable information and may result in property or personnel loss, or a decision to deploy batteries that are not suitable for a particular application or any application, requiring replacement. The result may be a loss of time and money. Therefore, the inventors have recognized the importance of monitoring battery packs even when those batteries are not in use.

[0031] The gateways 106a...106n are used to aggregate data from multiple WBMS nodes and provide the data to the data aggregation and management module 108. The gateways are wirelessly enabled to allow wireless communication with the WBMS nodes and can communicate with the data aggregation and management module 108 wirelessly or through a wired network. The gateways 106a...106n can be located in any suitable location to collect data from the WBMS nodes. For example, a warehouse storing batteries may have one or more gateways 106a...106n. A manufacturing facility may have one or more gateways 106a...106n.

[0032] Any suitable number of gateways 106a...106n may be provided to monitor the battery packs represented by the WBMS nodes 104a...104n. Dozens, hundreds, or thousands of gateways may be provided. Multiple gateways may be placed in the same location or in the same vicinity, such as in the same building, room, or transportation vehicle. Each gateway may aggregate data from multiple WBMS nodes 104a...104n, such as from dozens, hundreds, or thousands of WBMS nodes.

[0033] The gateways 106a...106n may communicate with the WBMS nodes 104a...104n and the data aggregation and management module 108 using any suitable protocol. In some embodiments, the gateway may be 4G and / or 5G enabled and may communicate in accordance with wireless 4G and / or 5G standards. However, aspects of the present application relating to gateways communicating with WBMS nodes and data aggregation and management modules are not limited to communicating in accordance with any particular protocol. Figure 3 and Figure 4 A non-limiting example of communication between a WBMS node and a gateway is illustrated.

[0034] Figure 3 A subsystem 300 including a WBMS node 304 and a gateway 306 is illustrated. The WBMS node 304 includes a battery pack 305 and a dongle 307 including an antenna 309. The battery pack 305 may be of the type described previously herein, or may be any other battery pack that needs to monitor the condition of the battery pack. The dongle 307 may include a sensor configured to sense the condition of the battery pack 305. For example, the dongle may include a sensor configured to sense voltage, current, state of charge, temperature chemical composition, or any other condition of the battery pack that needs to collect data. In some embodiments, the sensor may include a spectrometer, an ultrasonic imager, or a RADAR imager. The dongle may be attached to the battery pack 305 in any suitable manner, such as clamped to a battery terminal, screwed to the housing of the battery pack, or connected in any other manner. The dongle may be detachable so that it can be connected to a different battery pack when needed. The dongle may provide more complex measurement and sensing technology suitable for warehouse and transportation storage, which may be too expensive to be integrated into each battery. Non-limiting examples of such measurement and transmission technologies may include impedance spectroscopy with edge processing / modeling. Antenna 309 may be part of dongle 307 , including integrated into the dongle's packaging, and may communicate wirelessly with gateway 306 .

[0035] Gateway 306 may be previously combined with Figure 1 The gateway 306 may include an antenna 310. The antenna 310 may send signals to the WBMS node 304 and receive signals from the WBMS node 304. Specifically, the signals may be wirelessly communicated between the antenna 309 and the antenna 310.

[0036] Figure 4 Pictured Figure 3 An alternative subsystem to a subsystem. Figure 4 The subsystem 400 includes a WBMS node 404 and a gateway 306. The gateway 306 has been previously incorporated into Figure 3 The WBMS node 404 is different from the WBMS node 304 in that it includes a battery pack 405 with an integrated sensor 407. The integrated sensor 407 can be any type of sensor previously described herein. The integrated sensor 407 can include an integrated antenna for wireless communication with the antenna 310 of the gateway 306.

[0037] The battery pack may include multiple types of WBMS nodes. For example, the battery pack may include WBMS node 304 and WBMS node 404. The gateway may be configured to communicate with multiple types of WBMS nodes.

[0038] from Figure 3 and Figure 4 It should be appreciated that according to one aspect of the present application, a wireless battery monitor is provided. The wireless battery monitor can be secured to a battery in an operational or non-operational state and can collect information about desired characteristics of the battery. In some embodiments, the wireless battery monitor can be a dongle. In other embodiments, the wireless sensor is an integral part of the battery. The type of monitoring performed by the wireless sensor can be wirelessly controlled and can change over time, as further described below.

[0039] In some embodiments, a wireless-enabled battery may have all the features already included in the battery, and the battery monitoring service can select the correct edge model, optimize edge measurement techniques, and continuously improve existing models. Such operations may be particularly beneficial if the data being analyzed includes data from earlier parts of the life cycle, such as battery formation. The same techniques can also be used in a separate dongle embodiment.

[0040] return Figure 1, the battery management system 100 includes a data aggregation and management module 108. As previously described, the data aggregation and management module 108 implements the BLIS service 110 and maintains a battery database 112. The BLIS service 110, which may be executed in the cloud or alternatively may be executed on a dedicated network in some embodiments, or may be implemented in other ways, may serve as an aggregation point for data collected from WBMS nodes, may provide a user interface, may maintain a digital twin of the monitored batteries, may serve as a battery marketplace, and may serve as a source for battery model development and deployment. These functions are described in more detail below. The battery database 112 may store data of the type collected from the WBMS nodes, as well as additional data that may be useful in the performance of the functions handled by the BLIS cloud service 110. For example, Figure 1 As shown, the battery database 112 may include a table 114 for storing information, such as a battery pack identification ("packID"), a battery module identification ("moduleID"), a battery cell identification ("cellID"), voltage, current, temperature, and date information. For example, each measurement of voltage, current, and / or temperature may be date stamped. These measurements may be made at different times, and information related to the measurements over time may be stored in the battery database 112. Additional or alternative information may be maintained as desired. Such information may be sent by a WBMS node (e.g., WBMS nodes 104a...104n) to the BLIS service 110.

[0041] As mentioned above, a battery management system can be used to monitor the battery at any and all stages of its life cycle. Figure 5 A non-limiting example is illustrated. Method 500 illustrates monitoring of a battery cell, module, or battery pack during its lifecycle. As shown in stage 502, the battery may be manufactured. At this stage, monitoring 503 may be performed. Monitoring may include detecting SOH, SOC, or any other desired parameter, including any of those previously described herein.

[0042] At stage 504, the battery may be stored in a storage facility. For example, the battery may be placed in a warehouse for later deployment. At this stage, monitoring 505 may occur. As with the other monitoring stages of method 500, monitoring stage 507 may require monitoring any parameters of interest.

[0043] Figure 6An example of a configuration for monitoring batteries in storage is shown in FIG. Monitoring setup 600 includes a plurality of batteries 602 on a shelf 604 and a gateway 606. The batteries 602 may be WBMS nodes, such as any of the WBMS nodes described previously. The shelf 604 may be in a warehouse or other storage location. Any number of batteries 602 may be stored on the shelf, awaiting deployment. The gateway 606 may be any type of gateway described previously herein. The gateway may wirelessly communicate with all or a subset of the batteries on the shelf 604, collecting data from the batteries that may be passed to a BLIS service, such as previously described in conjunction with FIG. Figure 1 Such monitoring and data collection may occur at any suitable intervals.

[0044] Return to Figure 5 , at stage 506, the battery may be deployed in its first use. For example, the battery may be used in a ship or electric vehicle. At this stage, monitoring 507 may be performed. As with the other monitoring stages of method 500, monitoring stage 507 may entail monitoring any parameters of interest.

[0045] After deployment at stage 506, the battery may be retired and placed back into storage at stage 508. For example, the battery may be returned to a warehouse or other storage facility. At this stage, monitoring 509 may occur. As with the other monitoring stages of method 500, monitoring stage 507 may entail monitoring any parameters of interest.

[0046] At stage 510, the battery may be reused, such as in its second use. For example, the battery may be commissioned for a new use from the battery at stage 506. At this stage, monitoring 511 may be performed. As with the other monitoring stages of method 500, monitoring stage 511 may entail monitoring any parameters of interest.

[0047] Method 500 may involve iterating between using the battery and storing the battery, as indicated by the arrow from stage 510 to 508. A battery may have multiple lives and be reused multiple times. The battery management system described herein may monitor the battery throughout its life cycle.

[0048] Tamper-proof audit trail

[0049] According to one aspect of the present application, battery monitoring data collected from methods such as method 500 may be stored in a tamper-resistant audit trail. For example, data stored by battery management system 100, or at least some data, may be stored in a tamper-resistant audit trail. Figure 7A non-limiting example of the functional blocks of the BLIS service 110 is illustrated. As shown, the BLIS service 110 may include a secure audit trail 702. Each time a measurement is taken on a battery pack, module, or battery, it may be stored in the battery database 112 and digitally signed or hashed. It may also be added to the blockchain. The consensus mechanism of the blockchain may be server-based (e.g., distributed across multiple cloud services). Over time, the blockchain or trusted database will build a trusted ledger containing the network status as well as the measurements, state of health (SOH), state of charge (SOC), algorithms, battery packs, battery modules, and battery cell IDs for each monitored entity in the network. The trusted database can be used to create digital twins and enhance these digital twins in n-th life scenarios, as described below. Trusted database entries can be protected by a combination of cryptographic hash functions and digital signatures, with keys stored in secure hardware modules.

[0050] As already described, the BLIS service 110 can perform various types of analyses on the aggregated data. Various examples are now described. However, it should be understood that the battery management system 100 can perform alternative or additional analyses different from those described. For example, a subset of the analyses now described can be implemented. An administrator of the BLIS service 110 can select which analyses to perform. In some embodiments, the analyses can change over time.

[0051] Identifying assets and mutual authentication

[0052] The BLIS service 110 may include an access control function 704 to allow access only to authorized WBMS nodes. According to one embodiment of the present application, one or more, and in some embodiments, each battery pack, module, or battery contains a WBMS component containing a unique identifier. This allows the battery pack, its composite module, and battery to be uniquely identified based on the WBMS node. The identifier is cryptographically bound to the asset (package, module, or unit) by a digital signature issued when the WBMS node is manufactured. The WBMS node also includes a set of cryptographic primitives, including public key cryptography, symmetric encryption algorithms, hash functions, and secure key storage and security protocol implementations. The public key can be bound to the device identity through a digital signature or a public key certificate to form a trusted identity. The BLIS service 110 can use such information to verify the trusted identity by requesting the battery pack, module, or battery to calculate the digital signature and use the public key certificate to verify the signature and establish a trust chain. The WBMS node also contains a trusted key store containing a root certificate or a trusted public key that can be used to verify the BLIS service. The BLIS service 110 will verify itself by digitally signing the challenge issued by the WBMS node. This will establish an authentication context that is only valid for a limited time that can be configured by the customer or other user of the BLIS service 110. The measurement data may optionally be encrypted according to a key exchange protocol before transmission to the BLIS service 110 so that only the BLIS service 110 can decrypt and use the reported data.

[0053] Battery chemical fingerprint

[0054] According to one aspect of the present application, a battery management system can be used for battery chemistry fingerprinting. A customer or other user of the battery management system 100 can configure the BLIS service 110 for a specific battery chemistry, which in turn will allow the BLIS service 110 to recommend a set of optimal battery health algorithms for the specific battery chemistry. In addition, the BLIS service 110 can fingerprint the battery and infer its chemical properties by observing a series of simple voltage and current measurements over time, or by deploying more advanced measurement techniques such as impedance spectroscopy or other electrical and chemical characteristics to identify the battery and automatically select and recommend the best battery health algorithm. This will enable customers to mix different battery chemistries in their deployment without having to explicitly configure them in BLIS. In some embodiments, customers will have a fail-safe override option to ensure that the chemistry of their choice is selected.

[0055] Group Benchmark Anomaly Detection Algorithms

[0056] According to one aspect of the present application, a battery management system may be used to detect battery anomalies within a monitored group. For example, the BLIS service 110 may include a decision engine 706 configured to receive monitored data and analyze it for anomalies. The BLIS service 110 will deploy a set of anomaly detection algorithms that use a combination of statistical and machine learning techniques to identify outliers in terms of battery health or other parameters of interest. For example, battery health can be compared across a group of batteries, and outliers, such as those above and below thresholds, may be expected. For example, the first threshold may be the highest 5%, while the second threshold may be the lowest 5%. Those batteries that test within the top 5% of battery health may be rated as premium. Those batteries that test below 5% may be reprocessed, or designated as scrapped. Other thresholds may be used, and other parameters besides battery health may be used in such an analysis.

[0057] According to some embodiments, machine learning (ML) techniques are used to classify batteries into different groups. Such machine learning techniques can utilize information about the current battery population as well as historical populations to assess the health of the current batch of batteries. These algorithms will be, in some embodiments, pluggable and may be augmented or replaced by customer-specific or third-party provided algorithms. They will be protected like other pluggable modules using digital signatures.

[0058] Therefore, according to one embodiment of the present application, the battery management system 100 is used to perform anomaly detection. The BLIS service 110 runs one or more algorithms to detect abnormal measurements of any battery in the monitored group. Such abnormal measurements cause an alarm to be generated for the manager or operator of the battery management system 100. The manager can evaluate the alarm and take appropriate action. In some embodiments, the analysis can be completed using a machine learning algorithm executed by the BLIS service 110.

[0059] Alarm system

[0060] According to one aspect of the present application, the BLIS service can analyze the detected anomaly and determine an appropriate action, such as issuing an alarm or alert. For example, in some embodiments, once the system detects an anomaly using the decision engine 706, it will apply an algorithm to determine the severity and level of escalation. As described with respect to anomaly detection, the algorithm and its threshold levels can be automatically calibrated for the battery pack data, but additional criteria can be added to increase or decrease the severity level. Customers of the BLIS service can develop their own event / alarm algorithms, but can also utilize or configure the algorithms included by default in the BLIS service. The event algorithm can be executed by the alarm system 708 and can be further refined to take into account different battery chemistries as well as historical data about a specific battery (for example, combining measurements with battery formation information to generate a battery-specific alarm, even if the situation may be dangerous for a given battery for most batteries).

[0061] In some embodiments, a tiered alert system can be used to categorize events into multiple levels, ranging from informational only to immediately actionable. The event system can trigger alerts and can integrate with a range of event systems, such as email, SMS, and application notification systems. The alert / event system can also maintain an event queue in case an event cannot be generated. Event records sent will be recorded as part of a trusted audit trail to provide a record of when abnormal behavior is observed.

[0062] Figure 8 An example of a method that may be performed by a battery management system incorporating anomaly detection and alerting is illustrated. Method 800 begins at stage 802, where a BLIS service receives data from a plurality of batteries of a group. The data may be voltage data, current data, temperature data, or any other data aggregated by the BLIS service.

[0063] At stage 804, method 800 involves comparing the data of a given battery with data representative of a battery pack. For example, the SOC of a particular battery can be compared with representative data of the SOC of a battery pack. In some embodiments, stage 804 includes comparing the data of a given battery with a threshold value.

[0064] At stage 806, method 800 involves detecting an anomaly associated with a battery of interest. As non-limiting examples, an anomaly may cause battery data to be above a threshold or below a threshold.

[0065] The method may involve an optional stage 808 in which additional data about the abnormal battery is analyzed. The block of stage 808 is dashed to indicate the optional nature of this stage. The additional data that may be analyzed may be any suitable data for verifying the abnormal result of state 806 or determining the severity level of the abnormality.

[0066] At stage 810, which is also optional, an alert may be generated. The alert may be an alert generated to a user of the BLIS service or to an administrator of the BLIS service. The alert may be visual, audible or both.

[0067] Detecting anomalies and the methods that act on them can be different Figure 8 Therefore, it should be understood that method 800 is a non-limiting example.

[0068] Digital Twin

[0069] In some embodiments, the data collected by the BLIS service will be used as input to generate a digital twin model for a given battery, module, or battery pack. That is, according to some embodiments, a digital twin can be maintained for a given battery cell, battery module, or battery pack. The digital twin model library 710 of the BLIS service 110 can handle this. The digital twin can be composed of multiple models by a customer, a third-party expert, or an expert system integrated into the BLIS service through a "digital twin editor". After determining the battery chemistry, the digital twin editor may recommend multiple models for creating a digital twin. The battery chemistry can be identified by user input, looking up a specific batch number (including formation history), or examining measurement data (for example, observing the voltage, current, and temperature of a given battery cell, module, or battery pack, or performing impedance spectroscopy or ultrasonic analysis, etc.). In some embodiments, the BLIS service will maintain a digital twin for each asset and retain the parameters and models even after the asset is no longer tracked in the BLIS service. This information can then be accessed in later life cycle events to refine and update the digital twin. The digital twin can be enhanced throughout its lifecycle by adding and refining models (e.g., updating one of the existing models, or adding additional models). Every time a change is made to the models and parameters, it is possible to write it to a trusted audit log or blockchain entry.

[0070] A simplified version of the digital twin can be derived that can run locally on an edge node (WBMS node), sensor, or dongle in an energy-efficient manner. The digital twin of the edge node, sensor, or dongle will be used to make local predictions of SOH / SOC, which in some embodiments can eliminate the need for continuous wireless communication with a gateway or BLIS service, thereby reducing battery usage, which is particularly valuable in warehousing scenarios. The BLIS service will effectively offload some of the computations of the digital twin to the edge (WBMS node). If the local prediction deviates from the state measured at the edge node, an alarm can and in at least some embodiments will be issued, and buffered data of all measurements since the previous connection to the BLIS service will be sent to the BLIS service for deeper inspection and more powerful modeling in a high-fidelity digital twin. The model may be updated, or an alarm may be raised as a result. The updated model or an updated set of parameters (including the weights of a multi-layer neural network) can be redistributed back to the edge node, sensor, or dongle.

[0071] Model Market

[0072] In some embodiments, the BLIS service may provide a model marketplace from which digital twins may be created. The BLIS service 110 may include, for example, Figure 7 Market front end 712 is shown. In some embodiments, the market may include a database storing models. Different users of the BLIS service may be allowed to access the models stored in the database. For example, the BLIS service may include a server hosting a database storing models. Users of the BLIS service may access the models stored in the database. For example, the market may include an interface (e.g., a website) provided by the BLIS service through which users can access the models stored in the database.

[0073] A digital twin may consist of one or more models. Models may be optimized for different battery chemistries and input parameters. Parameters may include voltage, current, and temperature, but can be extended to include the results of impedance spectroscopy, ultrasonic analysis, or other active or passive measurements. The BLIS service may include a set of common models for common battery chemistries. In some embodiments, customers may alternatively or additionally create and upload their own models through the market front end 712 and upload their own models to the BLIS service. The models will be encapsulated in a library with a well-defined interface and will be digitally signed to ensure integrity. The models will be executed in a sandbox environment to prevent them from interfering with other models, while also helping to protect the intellectual property (IP) of the model provider by treating the model as a black box. In addition to customer-provided models, the BLIS service in some embodiments allows entities specializing in model creation (such as companies) to develop models and model sets that can be used for digital twin creation, as well as recommended model combinations for specific battery chemistries. Customers and third-party suppliers can provide their models and model combinations for use in the BLIS service through a digital marketplace accessible through the market front end 712. Customers and third-party suppliers can provide their models and model combinations for use in the BLIS service through a digital marketplace accessible through the market front end 712. Customers can try new models and model combinations, compare them to their own models and model combinations, and license these models from third parties or from each other. Third parties and customers can choose to control access to their models and can choose to make them visible only to themselves or selected customers. Third parties may include expert consulting companies, universities, or battery manufacturers who want to provide models for their batteries in the BLIS service. The model marketplace will contain a recommendation engine, search engine, reviews, and detailed descriptions of the models. When customers submit their models for inclusion, it may support a variety of pricing and licensing options, which can be expressed in markup languages ​​and captured through a graphical user interface. Models include not only the algorithmic simulation of the model, but also metadata about how the measurements are made (e.g., the excitation pulse, waveform, and frequency to be used by the impedance spectroscopy measurement system). Customers may see prerequisites for specific models (e.g., ultrasonic sensors). In addition to the list of included models, customers can also choose to contact model providers to provide feedback or commission custom models.

[0074] Battery Characterization and Model Creation

[0075] According to one aspect of the present application, the BLIS service includes a set of tools and capabilities to characterize batteries and quickly create models based on these characterizations. The data obtained from the characterization will be uploaded through the BLIS portal front end 714, and models can be derived from the data using a variety of techniques, including lookup tables, curve fitting, artificial intelligence (AI), and machine learning (ML) techniques. In some embodiments, the battery model creator generates a model that conforms to the interface supported by the BLIS service. The model creator tracks additional data captured during operation for each modeled battery and automatically uses this data to continuously improve the overall model, thereby creating a self-learning, adaptive battery model that is continuously improved as more data is collected.

[0076] In some embodiments, the model may include a battery simulation as well as metadata about the battery. For example, the metadata may include instructions on how to use the model, how to make measurements, and other information about the model. The BLIS service may provide generic models for different battery types (e.g., different battery chemistries). In some embodiments, the BLIS service may allow users to provide custom-developed models. The BLIS service may provide custom-developed models to other users of BLIS. BLIS may allow users to combine different models provided by BLIS to create new models for creating digital twins. In some embodiments, the BLIS service may allow users to experiment with models and model combinations. Users may be able to run simulations on the models. In some embodiments, the BLIS service may protect access to the models. For example, the BLIS service may restrict access to the models by encrypting the models and requiring a secure login to access certain models. In some embodiments, the BLIS service may provide a graphical user interface (GUI) through which users can search, create, submit, and / or modify models. The BLIS service may also provide a search engine for searching for available models provided by BLIS. In some embodiments, the BLIS service may include a recommendation engine to recommend models to users. The BLIS service may receive information (e.g., about the battery) from the user and determine a set of recommended models to provide to the user.

[0077] Distributing Updates

[0078] According to one aspect of the technology, the type of monitoring performed by sensors at a WBMS node can be updated based on computations done remotely, such as in the cloud. For example, many different batteries can be monitored and the collected data sent to the cloud for processing, as described above. Based on the data, it can be determined that the sensors should use different algorithms, so the updated algorithms can be transmitted from the cloud to the sensors on the batteries to update their monitoring. For example, the sensors may initially run one type of sensing algorithm but are later updated to run a different type of algorithm. In some embodiments, the algorithms can be updated by updating the parameter set, algorithm type, and / or battery model used by the sensor. For example, the sensor may: (1) initially run an algorithm using a first parameter set, a first type of algorithm, and / or a first battery model; (2) be later updated to use a second parameter set, a second type of algorithm, and / or a second battery model.

[0079] According to an embodiment of the present application, a wireless battery management system (WBMS) enables nodes (battery packs, modules, batteries) to connect to a battery lifecycle insight system (BLIS) and authenticate each other. BLIS will verify the version and edge algorithm set running on the WBMS node, then update the WBMS node to the correct firmware version, set the WBMS node to the correct network mode, enable inventory mode for local data storage of the WBMS node (e.g., for BLIS retrieval), enable measurement data encryption (optional), update edge algorithms and waveforms that can be used for more complex measurement techniques (e.g., impedance spectroscopy), and then enable those algorithms, waveforms, and measurement techniques that the customer has licensed. Updates may include changes to the code executed at the edge (including models), parameters used to configure edge nodes (including models, communication modes, and operating modes), and activation of specific functions at the edge node (e.g., impedance spectroscopy is enabled only when the customer licenses / pays for a specific measurement mode). All updates (firmware, settings, waveforms, parameters) are encapsulated in a common data structure that is serialized and digitally signed by BLIS to ensure that the updates are authentic and come from an authorized BLIS server. The BLIS service may maintain multiple signing keys for each deployment or each customer to further enhance security.

[0080] In some embodiments, the WBMS node may measure temperature, voltage, and / or current. In some embodiments, the WBMS node may be enhanced to measure additional modalities beyond temperature, voltage, and current. For example, the edge node may be enabled to participate in impedance spectroscopy to provide more complex diagnostics. In some embodiments, the BLIS may control the excitation frequency and waveform. For example, the BLIS may control the excitation frequency and waveform used for impedance spectroscopy and / or other measurement modalities used by the BLIS. The edge node may interpret the results itself or pass them back to the BLIS service for interpretation. The waveform and frequency will vary depending on the battery chemistry, and there may be multiple waveform and frequency variations for a given battery chemistry. The combined results may be used to infer a deeper understanding of the battery health. System users may develop their own waveform and frequency graphs, and this may be provided as a plug-in to the BLIS service, which then manages and distributes this on behalf of the customer using the same mechanism as described further below with respect to pluggable algorithms. The system manager may continually update and augment the waveform and frequency graphs. As new measurements are developed, support for these measurements may be added to the BLIS service (e.g., ultrasound or radar imaging of batteries).

[0081] Offline operation

[0082] According to one aspect of the present application, a WBMS node can record data while offline. In the event that a WBMS node cannot connect to a BLIS service or cannot connect to a gateway, in some embodiments, it can continue to take measurements and timestamp these measurements using a real-time clock that is synchronized periodically when the edge node can connect to the system. WBMS-enabled nodes can store these measurements locally or forward them to a gateway if available. The gateway can queue messages until a BLIS service becomes available and then send the measurements to BLIS.

[0083] Pluggable algorithms

[0084] The BLIS service may maintain a library of algorithms 716 for different SOH, SOC, and other battery-related algorithms. The BLIS service may include a set of baseline algorithms. These algorithms may be replaced by custom algorithms developed by the customer or a supplier of their choice. The BLIS service may accept multiple algorithms for a single battery chemistry and allow the customer to select one or more of these algorithms to represent the battery health. Plug-in algorithms may run in a secure container on the service and may be sandboxed to prevent it from interfering with other algorithms or other aspects of BLIS operation. In some embodiments, if the plug-in algorithms are digitally signed by the manager of the BLIS service as an additional layer of protection, they will only run in the BLIS service. Customers can develop their own SOH and SOC and other battery health measurement algorithms using the SDK and a quality control test suite that sets minimum quality standards. Customers will be able to limit the visibility they provide to plug-ins that they deploy themselves, and these algorithms will not be visible to other customers.

[0085] Additional measurements

[0086] WBMS nodes can be enhanced to measure other modes beyond temperature, voltage, and current. For example, edge nodes can be made to participate in impedance spectroscopy to provide more complex diagnostics. The BLIS service can control the excitation frequency and waveform. The WBMS node can interpret the results itself or pass them back to the BLIS service for interpretation. The waveform and frequency may vary due to battery chemistry, form factor, or other unique characteristics of the battery, and there may be multiple waveform and frequency variations for a given battery chemistry. The combined results can be used to infer a deeper understanding of the battery health. Customers can develop their own waveform and frequency plots and can provide them as plug-ins to the above BLIS service. The administrator of the BLIS service can continuously update and expand the waveform and frequency plots. As new measurements are developed, such as ultrasound or radar imaging of battery cells, the BLIS service may support such measurements.

[0087] localization

[0088] In addition to measuring, monitoring, and maintaining the models that make up the digital twin, the BLIS service will be able to provide other services, such as localization. Batteries stored on shelves can be located using a set of matching barcodes that are scanned whenever a battery is placed on or removed from a shelf. The BLIS service can activate and configure the WBMS nodes and mesh network to enter "localization" mode. In this mode, the BLIS service can use signals from the WBMS nodes to calculate the location of battery packs, modules, and cells relative to each other using triangulation techniques. These relative locations can then be converted to absolute locations by mapping them to gateways with known locations (either manually entered or derived from a global positioning system). Location information can be combined with battery performance data to identify areas in the warehouse where battery performance may be unduly affected by location (for example, a top shelf, west-facing battery may discharge faster than a battery on a bottom shelf in the center of the warehouse). This information can be used to develop a battery location rotation program to ensure that batteries are not stored in unfavorable locations for long periods of time.

[0089] Battery matching

[0090] According to one embodiment of the present application, BLIS may operate as a battery matching service, where BLIS creates a battery pack to recommend to a user (e.g., a customer). In some embodiments, BLIS may use data collected from monitoring of one or more nodes to determine a combination of modules and / or batteries to create a battery pack. The BLIS service may use data collected from a group of batteries to create a battery pack. The created battery pack may then be used to provide the battery pack to the user. For example, the determined battery pack may be used to extract battery cells, modules, and / or battery packs from inventory and used for assembly of battery packs. The created battery pack may also be used to establish an inventory of battery packs, modules, and / or batteries to be maintained in inventory, so as to subsequently provide the created battery pack to the user.

[0091] In some embodiments, the BLIS service can operate a battery matching service to facilitate the maintenance of battery packs. If the BLIS service determines that a WBMS node does not meet quality standards (e.g., health or performance), the BLIS service can match a battery pack with the node and trigger the scheduling of the battery pack to a geographic location (e.g., a service center) where the node's current battery pack can be replaced. The battery pack at the node can then be replaced with the assigned battery pack. In some embodiments, the BLIS service can predict that a node will fail to meet quality standards and trigger scheduling based on predicted failures. For example, the BLIS service can use digital twins to predict failures and trigger scheduling of battery packs based on predicted failures.

[0092] According to one aspect of the present application, in addition to providing positioning, modeling and monitoring services, the BLIS service can also operate as a battery matching service for maintenance and battery pack creation scenarios. Based on the collected data and the digital twins built based on the battery and module models, the BLIS service may recommend the best combination of modules and batteries to create a battery pack by looking at the data of a large number of battery packs. This information can then be used to extract batteries from inventory and order them to the production line to create the best performing battery pack while minimizing production time by ensuring that the correct batteries and modules are provided on the production line at the right time. In addition, it can also be used to determine whether the correct batteries and modules are combined. When it returns to the inventory, it will continue to monitor the created module or pack. The BLIS service can identify the most compatible module or battery for the battery pack, and this information can be used to establish an inventory of replacement parts, allowing specific modules or batteries to be reserved to match the number of battery packs on site. This may help ensure that there are always a large number of compatible replacement parts in the inventory. The same matching algorithm can be used throughout the life cycle of the battery pack to facilitate the maintenance of the battery pack. If a module is detected to be faulty or underperforming, the BLIS service in some embodiments finds a match and dispatches it to a geographic location, such as a service center, where the battery can be updated with a matching module. The BLIS service can decide where to dispatch the battery based on location information provided as an additional input from another system. The BLIS service can also predict potential failures if operational data is acquired through an integrated interface and the model of the cell, module, or pack is further refined. The BLIS service may be able to predict failure of a battery through digital twin simulation, identify compatible modules in inventory, send them to a local service station, and set up an appointment for the battery pack to be repaired by integrating with the customer's schedule (or the group owner's maintenance plan), thereby optimizing maintenance cycles and reducing operating costs while avoiding catastrophic failures.

[0093] N'thLife Recommends

[0094] In some embodiments, the BLIS service may use data collected from the monitoring to determine one or more subsequent uses of the battery. For example, the BLIS service may use data collected from monitoring a battery used for a first application (e.g., an electric vehicle) to determine a second application of the battery (e.g., an electric scooter). In some embodiments, the BLIS service may use the data to parameterize a digital twin maintained in the BLIS service and use the parameterization to predict the availability of the battery for subsequent use. Example parameters generated from the digital twin may include temperature, cycle time, vibration history, impedance spectrum history, and / or other parameters. The BLIS service may use the determined parameters to predict the performance of the battery for subsequent use and provide recommended subsequent uses based on the predicted performance.

[0095] The information collected in the BLIS service can be combined with data collected during battery operation to determine the most appropriate second, third, fourth or subsequent life of the battery. The combined data can be used to parameterize the digital twin model maintained in the BLIS service, to grade the batteries and to recommend a usage profile for the next life cycle based on current and projected performance (e.g., a battery from a three-year-old car may be suitable for a new truck, forklift or scooter depending on its SOH and SOC history and other parameters collected, such as temperature, cycle time, vibration history, impedance spectroscopy history or other parameters).

[0096] As already described, aspects of the present application provide a battery lifecycle insight system (BLIS). In some embodiments, BLIS can be a comprehensive battery lifecycle management service with its own user interface and connection options. However, it can also be integrated into existing enterprise resource planning systems through a set of well-defined APIs. For example, again referring to Figure 7 , the BLIS service 110 may include an API integration point 718. The API may be access controlled and authenticated so that a client only requests and views their own data, while viewing raw data, calculated data, and meta information about a specific cell, module, or package. The API may not only extract data, but may also obtain additional data about a specific battery, including battery formation information, operational information, and location information.

[0097] The various functions of the BLIS service have been described. The workflows for these functions can take any suitable form. The workflows themselves can be defined dynamically through a user interface tool that creates a configuration file containing the expression of the composed services captured in a markup language. Thus, rapid experimentation with different workflows that are easily customizable on a per-customer basis can be achieved. The workflow blocks themselves can be defined through a series of interfaces, which in turn can be implemented as a series of microservices. Fig. 9 A non-limiting example of a workflow according to an embodiment of the present application is illustrated. The listed functional blocks can be grouped into access services 902, workflow services 904, and common services 906. Common services 906 can be called from any workflow service.

[0098] The data flow is given by the following sequence shown in the figure.

[0099] Data such as voltage, temperature, and current are sensed and provided to the access service 902. Specifically, some data is sent directly (flow 1a) to the API integration point 718. Some data is first sent to the portal front end 714 (flow 1b) and then to the API integration point 718 (flow 2a), and some data is first sent to the marketplace front end 712 (flow 1c) and then to the API integration point (flow 2b).

[0100] The API integration point 718 verifies the identity of the WBMS node against the access control system function 704 (flow 3).

[0101] A security audit log entry for data ingestion is created in the security audit trail 702 (flow 4).

[0102] For a given battery pack or module, data is written to the battery database 112 (process 5).

[0103] The data is also passed to the algorithm library 716 (flow 6).

[0104] It is determined which algorithms to apply and the results are written to the battery database 112 (process 7).

[0105] Control is passed to the digital twin (process 8), which may consist of a complex model of the battery cell, module, or battery pack from the digital twin model library 710.

[0106] The output of the digital twin from the digital twin model library 710 can be written to the battery database 112 (process 9).

[0107] Control may be passed to decision engine 706 (flow 10), which may decide whether to issue an alert (flow 12).

[0108] The results of the decision engine 706 may be written to the battery database 112 (flow 11 ). The data from flows 5 , 7 , 9 , and 11 may be provided from the battery database 112 to the security audit trail 702 .

[0109] In response to the decision engine issuing an alert (flow 12), control may pass to the alert system 708, which may send a predefined alert.

[0110] This workflow is a non-limiting example, as other information exchange methods are also possible. In addition, it should be understood that the order or steps may be different from what is shown, and multiple processes may be performed simultaneously.

[0111] It should be understood that the various functions described herein can be performed by a suitable processor configuration. For example, a WBMS node, a gateway, and a BLIS can, and in at least some embodiments, each include at least one processor. At least one processor executes processor-executable instructions to perform the functions of those items. For example, in some embodiments, the BLIS service 110 is implemented by multiple processors (at least one processor) that execute processor-executable instructions to prompt the BLIS service to perform the functions described herein. A storage device, such as one or more memories, including distributed memory, stores processor-executable instructions. If the BLIS service 110 is implemented in the cloud, a suitable combination of storage devices and processors can be used to perform the described functions.

[0112] The terms "approximately" and "roughly" may be used in some embodiments to indicate ±20% of a target value, in some embodiments to indicate ±10% of a target value, in some embodiments to indicate ±5% of a target value, and in some embodiments still within ±2% of a target value. The terms "approximately" and "roughly" may include a target value.

Claims

1. A battery management system, comprising: at least one processor; and a storage device storing processor-executable instructions that, when executed by the at least one processor, cause the at least one processor to: aggregating state-of-health information of a first plurality of batteries for a first application, the first plurality of batteries being in a non-operational state, wherein the aggregation of the state-of-health information includes monitoring the first plurality of batteries when not under load; determining a second application for at least one battery in the first plurality of batteries using the aggregated state of health information of the first plurality of batteries; Wherein determining the second application comprises: parameterizing a digital twin of the plurality of batteries using the aggregated state of health information of the first plurality of batteries, and Based on the parameterization of the digital twin, performance of the at least one battery for the second application is predicted. 2 . The battery management system of claim 1 , wherein the processor-executable instructions, when executed by the at least one processor, cause the at least one processor to further aggregate health status information of a second plurality of batteries in a working state. 3 . The battery management system of claim 1 , wherein the health status information includes charging status information.

4. The battery management system of any one of claims 1 to 3, wherein the processor executable instructions, when executed by the at least one processor, cause the at least one processor to further store the health status information in a blockchain.

5. The battery management system of any one of claims 1 to 3, wherein the processor-executable instructions, when executed by the at least one processor, cause the at least one processor to perform anomaly detection in the health status information of the plurality of batteries.

6. The battery management system of any one of claims 1 to 3, wherein the processor-executable instructions, when executed by the at least one processor, cause the at least one processor to provide a recommended usage of a first battery in the first plurality of batteries.

7. A method for managing a battery pack, comprising: aggregating, by at least one processor, state-of-health information of a first plurality of batteries for a first application, the first plurality of batteries being in a non-operational state at one or more remote locations, wherein aggregating the state-of-health information includes monitoring the first plurality of batteries when not under load; determining, by the at least one processor, a second application for at least one battery in the first plurality of batteries using the aggregated state of health information of the first plurality of batteries; Wherein determining the second application comprises: parameterizing a digital twin of the plurality of batteries using the aggregated state of health information of the first plurality of batteries, and Based on the parameterization of the digital twin, performance of the at least one battery for the second application is predicted.

8. The method of claim 7, further comprising aggregating, using the at least one processor, state of health information for a second plurality of batteries in an operational state.

9. The method of claim 7, wherein the health status information includes charging status information.

10. The method of any one of claims 7 to 9, further comprising storing health status information in a blockchain.

11. The method of any one of claims 7 to 9, further comprising using the at least one processor to perform anomaly detection in the health status information of the plurality of batteries.

12. The method of any one of claims 7 to 9, further comprising recommending use of a first battery in the first plurality of batteries.

13. The method of any one of claims 7 to 9, further comprising providing, using the at least one processor, an updated sensing algorithm to a node configured to sense the health status information of a first battery among the plurality of batteries in response to analyzing the health status information.

Images