Battery state of health estimator

Abstract

The present invention relates to a computing system, method, and apparatus for determining a state of health indication for a battery. A first supervised deep neural network ("DNN") is trained using received battery characteristics as input and using received process parameters as output. Based on features extracted from the first supervised DNN, an unsupervised AI estimator is trained using one or more clustering methods, wherein the received characteristics are input to the unsupervised AI estimator. A second supervised DNN is trained using identified clusters from the unsupervised AI estimator. The identified clusters are validated by a state of health indication. User battery data is input to the second supervised DNN to determine a state of health of the battery.

Description

[0001] Cross-references to related applications

[0002] none. Technical Field

[0003] This disclosure relates to methods, apparatus, and systems for battery health state estimators, and more particularly to battery health state estimators that use inductive domain knowledge for supervised learning. Background Technology

[0004] Deep neural networks (“DNNs”) are widely used in a variety of artificial intelligence (“AI”) applications, including computer vision, autonomous vehicles, speech recognition, language translation, advertising, cancer detection, and robotics. Machine learning methods used to develop DNNs are categorized into supervised learning and unsupervised learning. In supervised learning, in addition to the given input data, trusted labels are provided as output data (i.e., ground facts) to train the DNN. In unsupervised learning, labels are unavailable and / or untrustworthy because the accuracy of such measurements is insufficient. Instead, the outputs are grouped into clusters based on their similarity in the feature space.

[0005] An unsupervised learning approach has been explored, using observable battery characteristics as input and outputting the observed state of health ("SoH") of the battery. SoH is a metric that quantifies the level of battery aging based on capacity decay and / or internal resistance. Estimating SoH is crucial for extending battery life, understanding battery operation, and improving battery performance.

[0006] State of equilibrium (SOH) can typically be estimated using experimental and model-based methods. Experimental methods monitor battery behavior by analyzing full-cycle experimental data on battery voltage, current, and temperature. Model-based estimation methods can be further divided into physics-based state estimation methods and data-driven methods.

[0007] While battery state of charge (“SoC”) can be measured with sufficient accuracy through accelerated lab testing at the single-cell level, it is challenging to adequately measure these quantities at the module / group level in electric vehicles to represent real-world driving and charging behavior. Even the seemingly simple task of accurately measuring the battery’s SoC is a challenge in current electric vehicles. Current SoC estimation approximates this only through discrete open-circuit voltage lookup tables, which map the relationship from voltage (ideally static) to SoC. However, this mapping does not account for the hysteresis of battery degradation. Furthermore, voltage-based SoC measurement is impractical for batteries in electric vehicles, which are constantly subjected to repetitive small loads for management functions (e.g., data acquisition and uploading, temperature control, and / or load balancing), resulting in quasi-closed-circuit voltages that violate the open-circuit voltage assumption. In current battery management and control systems (“BMS”), battery degradation cannot be adequately reflected in SoC or SoC measurements due to limited experience in real-time modeling and the computational and storage capabilities for application-based model-based estimations.

[0008] Figure 1 illustrates a prior art block diagram for determining the battery's state of health (SoH) using an unsupervised estimator. Unsupervised learning can be achieved by clustering features from the input signal (e.g., k-means clustering) or by training an autoencoder as an unsupervised DNN10. In cluster recognition, the goal is to minimize the similarity of data between clusters while maximizing the similarity of data within clusters. If sufficient features are extracted from the input data, desired cluster boundaries indicative of the battery's SoH can be found, showing clearly separable clusters. However, undesirable cluster boundaries are found due to the extreme difficulty in correctly selecting features. Furthermore, clustering algorithms are unsuitable for the available data due to poorly formulated parameter thresholds. The result is that overlapping features from one cluster are mixed into another, obscuring useful information.

[0009] Therefore, it is important to develop new techniques that can generate battery health indicators using supervised DNNs, which have a hybrid approach of supervised (or supervised) and unsupervised learning methods for training. Summary of the Invention

[0010] Physics-based phenomena can be modeled using domain-knowledge-driven physics models that describe a limited number of certified dominant mechanisms (e.g., thermal, electrochemical, and aging effects in battery lifetime estimation) or using purely data-driven models, such as Kalman filters or machine learning. Different approaches (or methods) include, for example, (1) physical and chemical modeling, including battery aging effects, (2) weighted methods based on outlier detection, and (3) SN curves as an event-driven approach. Data-driven methods can be used to predict battery lifetime while taking into account any capacity degradation. For example, the state of charge (SOH) of the battery is estimated by a Kalman filter, while SOH, including degradation due to aging, can be determined by least-squares regression. The accuracy of the model can be improved by inductively summarizing knowledge about physical behavior through physics-driven feature extraction.

[0011] Ideally, modeling based on domain knowledge and data can be combined to minimize the potential residual error of analytical models that describe only a limited number of key mechanisms. There are two approaches for combining different modeling methods.

[0012] First, using machine learning to model the residual error of the analytical model reduces the overall modeling error (thus improving model accuracy). The residual error is handled from a black-box perspective, therefore it does not affect the identification of the new mechanism.

[0013] Secondly, incorporating domain knowledge into machine learning allows for the derivation of fundamental domain knowledge from experimental table design, and the identification of novel mechanisms (e.g., increased electrolyte degradation in lithium-ion batteries experiencing high temperature gradients) by analyzing features governed by this domain knowledge. Experimental table design can include experimental operating conditions such as the external temperature of the vehicle or vehicle containing the battery under test, the set temperature of the controlled experiment, the humidity of the controlled experiment, the charging rate of the battery under test, and the driver type relative to the battery (e.g., aggressive, moderate, or mild-mannered driver).

[0014] This disclosure may include domain knowledge from machine learning methods derived from applied engineering and data-centric approaches. Typically, domain knowledge is neglected in purely data-driven models where only optimization algorithms are applied to extract optimal features from input data. However, domain knowledge can be used to derive characteristics through machine learning methods such as linear regression, logistic regression, etc.

[0015] Specifically, domain knowledge is incorporated into supervised learning for the DNN to determine an estimate of the battery's SoH (Solar Hour). In vehicle applications, the machine learning model is optimized for deployment in vehicles with limited computing and storage capabilities. Therefore, the vehicle can reflect battery degradation in SoC and / or SoH in real time given computational constraints. However, for SoC and / or SoH indications, there are no reliable labels generated from reliable battery measurements. This disclosure uses supervised learning methods to inductively generate knowledge from experimental designs and transfers this inductive knowledge from single-cell batteries to modules, and ultimately to groups of modules within the vehicle for use in real-world driving and charging scenarios.

[0016] Improved predictions were achieved by using domain knowledge as trusted labels in supervised DNNs to extract better features for unsupervised DNNs, thus benefiting from the advantages of both.

[0017] To determine the SoH (Solar Hierarchy) of a battery, battery characteristics and process parameters are received as training data. A supervised deep neural network (“DNN”), referred to as the first supervised DNN, is trained using the received characteristics as input and the received process parameters as output. Features are extracted from the supervised DNN and then used to train an unsupervised AI estimator. A second supervised DNN is then trained using the clusters (also referred to as “groups”) identified from the unsupervised AI estimator. Once clustering has been performed, the output of the clustering is validated using the SoH indicator. Once the second supervised DNN is determined, battery characteristics of a specific battery (or user battery data) are input into the second supervised DNN to determine the SoH indicator. Attached Figure Description

[0018] This disclosure is illustrated by way of example and in the accompanying drawings in a non-limiting manner, wherein similar reference numerals indicate similar elements, and in the drawings:

[0019] Figure 1 shows a prior art block diagram for determining battery health status using an unsupervised estimator;

[0020] Figure 2 A block diagram is shown that uses process parameters and observed battery characteristics to generate a battery health status indication;

[0021] Figure 3 A flowchart illustrating an embodiment of the present disclosure for generating a battery health status indication is shown;

[0022] Figure 4 A flowchart illustrating other embodiments of this disclosure for generating a battery health status indication is shown;

[0023] Figure 5A graph is shown illustrating the application of supervised learning to a deep neural network to determine known process parameters of a battery;

[0024] Figure 6 A graph is shown illustrating the application of unsupervised learning to a deep neural network to determine an indication of battery health using features extracted from other DNNs used to determine battery process parameters.

[0025] Figure 7 A graph showing the clustering output of an unsupervised deep neural network;

[0026] Figure 8 A graph showing the SoH categories (from a few available underlying real measurements) used to verify unsupervised clusters in the feature vector space is presented.

[0027] Figure 9 A graph of a supervised DNN is shown, which determines the SoH indication of a battery based on observable battery characteristics; and

[0028] Figure 10 A simplified block diagram of a vehicle according to an exemplary embodiment of the present disclosure is shown. Detailed Implementation

[0029] The figures and descriptions provided herein may have been simplified to illustrate aspects important for a clear understanding of the apparatuses, systems, and methods described herein, while other aspects that may be found in typical apparatuses, systems, and methods have been omitted for clarity. Those skilled in the art will recognize that other elements and / or operations may be desired and / or necessary for implementing the apparatuses, systems, and methods described herein. Because these elements and operations are well known in the art, and because they are not conducive to a better understanding of this disclosure, a discussion of these elements and operations may not be provided herein. However, this disclosure is intended to inherently include all such elements, variations, and modifications to the described aspects that are known to those skilled in the art.

[0030] Figure 2 A block diagram is shown illustrating the generation of battery health indicators using process parameters and observed battery characteristics. The underlying, or foundational, dataset contains measurable battery characteristics (e.g., time series of battery temperature, voltage, and current signals), generated by process parameters such as set temperature, SoC at the start and end of the experiment, and the charge and discharge rates used in the experiment. If reliable labels are not available for quantifying battery state (e.g., measurements of battery capacity, battery SoH, and / or battery internal resistance), supervised methods can be introduced.

[0031] A supervised classification DNN is trained by generalizing domain knowledge of process parameters 20 into class labels. Next, the features of the DNN are used for clustering. Different class labels can be obtained by binning the values ​​of process parameters (e.g., low / medium / high C-rates or temperature) (e.g., dividing continuous values ​​into discrete bins, such as 40-55 degrees Celsius representing high temperature). As an alternative to the classifier, a regression DNN can be trained to directly approximate the process parameters as output quantities without binning. In either case, the features in the convolutional layers characterize the input data of the underlying process parameters 20 and the observable battery characteristics 22. Through the knowledge generalization step, these features are forced to be developed simultaneously during training for both the input quantities and the process parameters. These features are then used for unsupervised training of an artificial intelligence (“AI”) estimator. The AI ​​estimator can be trained in a supervised manner to develop a supervised DNN for outputting a health status indication 24 based on the observable battery characteristics 22. Understandably, an AI estimator can be an AI algorithm (e.g., a machine learning algorithm, a deep learning algorithm, or a combination thereof) trained using unlabeled data (i.e., without a base real-world predictive reference from measurement or simulation).

[0032] Figure 3 A flowchart illustrating an embodiment of this disclosure for generating a battery health status indication is shown. To determine the battery's SoH (State of Health), battery characteristics and process parameters are received as training data 40. Battery characteristics include observable quantities of the battery. For example, a BMS (Battery Management System) can be coupled to the battery for battery load management and battery cooling. The BMS can measure various battery characteristics, including battery temperature, battery voltage, battery current, number of charge cycles, charging characteristic curves, discharging characteristic curves, etc. The measured characteristics can be measured within a predefined cycle time to generate a function of specific characteristics. Process parameters are generated by measuring external factors applied to the battery, such as a set temperature designed for the experiment, the start and / or end of the SoC (State of Health), charging rate, etc. Process parameters can individually affect the workload of a particular battery and may lead to personalized degradation of that particular battery.

[0033] Supervised deep neural networks (“DNNs”), often referred to as the first supervised DNNs, are trained using received features as input and received process parameters as output. Supervised DNNs can be trained using various supervised learning algorithms, including convolutional layers with multiple fully connected layers (plus max pooling), ResNet, U-Net, or other DNN architectures. In this way, features of the supervised DNN are inductively derived from known quantities of received battery characteristics and process parameters.

[0034] Features are extracted from the supervised DNN and then used to train an unsupervised AI estimator. The unsupervised AI estimator can be trained using one or more clustering methods based on the features extracted from the supervised DNN. For example, machine learning algorithms for clustering, such as k-means clustering, can be applied. During unsupervised training, the received battery characteristics are input into the unsupervised AI estimator. Identified clusters can be found from the AI ​​estimator. It is understood that additional steps may be included, in which at least one planarization layer is removed from the supervised DNN to enable feature extraction and remapping for other class outputs (e.g., SoH indications).

[0035] Next, a second supervised DNN is trained using the identified clusters (also called “groups”) from the unsupervised AI estimator 46. The output of the unsupervised AI estimator can be clustered using a classification algorithm. For example, the output of the unsupervised DNN can be clustered by dividing continuous values ​​into discretized bins. Alternatively, a DNN regression algorithm can be used to cluster the output. Understandably, other classification / clustering algorithms can also be used. Once clustering has been performed, the clustering output is validated using the SoH instruction 48.

[0036] Once the second supervised DNN is determined, the battery characteristics of the specific battery (or user battery data) are input into the second supervised DNN to determine the SoH indicator 50. High-intensity SoH measurements can be performed on representative, measurable battery characteristics to assign clusters of output from the second supervised DNN to the SoH indicator (e.g., low / medium / high health or 10 / 50 / 90% battery health). It is understood that the user battery data can be received battery characteristics, a battery dataset specific to a particular battery, or a combination thereof.

[0037] In vehicle applications, given the user characteristics corresponding to this battery, user battery data, such as battery usage, battery charge and discharge cycle data, is monitored and stored by the BMS. It is understood that the validated SoH indices can be used to retrain the second supervised DNN to further refine the feature mapping of the second supervised DNN (e.g., customizing the estimator for different regions / drivers).

[0038] Figure 4A flowchart illustrating another embodiment of this disclosure for generating a battery health status indication is shown. The entire process of estimating inductive domain knowledge for SoH can include combining unsupervised (e.g., clustering) and supervised (e.g., classification / regression) training methods. The training of the unsupervised AI estimator 44b and the training of the second supervised DNN 46 can be repeated multiple times until a convergence criterion 47 is met. Steps 44b and 46 can be repeated, for example, based on a predefined number of repetitions, a modified clustering convergence criterion, whether a predefined accuracy is achieved by training the second DNN, or a combination thereof. During retraining in step 44b, features are extracted from the previous unsupervised AI estimator and used for retraining. Thus, after each repetition in step 44b, the output of the unsupervised AI estimator can be refined from coarse numbers to finer numbers.

[0039] Figure 5 A graph illustrates the application of supervised learning to a deep neural network to determine known process parameters of a battery. In one embodiment, the supervised DNN42 includes a convolutional layer 60 for feature extraction, a planarization layer 62, one or more fully connected layers 64, and an output layer 66. The planarization layer 62 is located between the convolutional layer 60 for feature extraction and the one or more fully connected layers for regression. The output layer 66 provides classification or regression values ​​based on the outputs of the one or more fully connected layers 64.

[0040] Features from the convolutional layers are extracted as vectorized quantities (with planarized layers) for feature-based clustering. Since this feature vector is associated with the SoH indicator, it can then be used to generate clusters. Because the extracted features represent characteristics of both process parameters and observed battery properties, the identified clusters in the feature vector space may have relevant characteristics for representing the desired clusters for battery SoH estimation. Therefore, the identified clusters can then be relabeled considering the associated but unlabeled output of the SoH value. The SoH value can include a percentage of the total ideal capacity relative to 100% of the undegraded battery. For example, 10% might mean that the tested battery may have degraded to the point where it can only retain a preset percentage of the charge of an undegraded battery. Alternatively, the SoH indicator can include related terms for different states, including SoH indicators of “poor,” “moderate,” or “good.” Different states can correspond to threshold percentage values ​​for SoH or SoC.

[0041] Figure 6A diagram illustrating the application of unsupervised learning to a deep neural network is shown. Observable battery characteristics are fed into convolutional layer 78. The convolutional layer represents features extracted from a supervised DNN trained on the battery characteristics and process parameters. The convolutional layer outputs to a planarization layer 80 to produce feature vectors 82. The planarization layer converts the 2D and / or 3D features from convolutional layer 78 into vector quantities. One or more clustering algorithms can be used to cluster the feature vectors 82 output from the planarization layer 80 to generate boundaries around similar feature vectors.

[0042] Figure 7 A graph showing the clustering output of the unsupervised deep neural network is presented. During training step 44 of the unsupervised AI estimator, the feature vector 82 can be clustered using an unsupervised learning algorithm. Since features extracted from the supervised DNN (including process parameters as domain knowledge) are used to generate the feature vector 82, the boundaries of the feature vector 82 can be more easily determined based on more meaningful features.

[0043] Clustering algorithms can identify clusters such as cluster 1, cluster 2, cluster 3, ..., cluster N-1, and cluster N as different clusters. The number of clusters can be selected based on a predefined number or according to a specific threshold.

[0044] Figure 8 A graph is shown for the SoH classifier used to validate unsupervised clusters in the feature vector space. Once clusters are identified in the feature vector 82, one or more representative samples from each cluster can be used to validate what SoH indication corresponds to the corresponding cluster.

[0045] For example, based on the SoH test of one or more representative samples from cluster 1, cluster 1 can be associated with the SoH indicator "Good". Furthermore, one or more representative samples from each of the other clusters can be tested against a SoH indicator, and then that cluster can be associated with that SoH indicator. In this example, cluster 2 is associated with the SoH indicator "Poor"; cluster 3 is associated with the SoH indicator "Moderate".

[0046] Figure 9A diagram of the supervised DNN disclosed herein for determining a battery SoH indicator based on observable battery characteristics is shown. The supervised DNN 100 includes a convolutional layer 102, a planarization layer 104, one or more fully connected layers 106, and an output layer 108. The output layer 108 can have SoH indicators, such as "good," "poor," and "medium." Features of the supervised DNN can be derived from previous supervised (classification / regression via process parameters) and unsupervised (clustering) steps. The unsupervised steps are reformulated into supervised steps by identifying clusters as labels. Once trained, the supervised DNN 100 can be used to evaluate a specific battery for the SoH indicator. In particular, observable battery characteristics are input into a second supervised DNN to produce "good," "poor," and / or "medium" SoH indicators.

[0047] Figure 10 A simplified block diagram of a vehicle according to exemplary embodiments of the present disclosure is illustrated. In an exemplary embodiment, vehicle 158 includes a computing system 160, sensors 162, a vehicle communication system 164, a propulsion system 166, a control system 168, a power supply 170, a user interface system 172, and a battery management system 174. In other embodiments, vehicle 158 may include more, fewer, and / or different systems, and each system may include more, fewer, and / or different components. Furthermore, systems and / or components may be combined and / or divided into multiple arrangement configurations.

[0048] The computing system 160 may be configured to transmit data to, receive data from, and interact with and / or control one or more of the propulsion system 166, sensor 162, control system 168, BMS 174, and any other components of the vehicle 158.

[0049] In at least one embodiment, the computing system 160 may be configured to store data in a local data storage device and / or communicatively coupled to an external data storage device. It is understood that data may also be transmitted to and received from a cloud server via over-the-air (“OTA”) wireless technology. OTA wireless technology may be used, for example, to transmit updated DNN models or to upload data of interest, such as corner cases.

[0050] In another embodiment, computing system 160 may be configured to cause sensor 162 to capture images of the environment surrounding vehicle 158. In another embodiment, computing system 160 may control the operation of propulsion system 166 to operate vehicle 158 autonomously or semi-autonomously. As another example, computing system 160 may be configured to store and execute instructions corresponding to algorithms from control system 170 (e.g., for steering, braking, and / or throttle adjustment). As another example, computing system 160 may be configured to store and execute instructions for using sensor 162 to determine the environment surrounding vehicle 158. More importantly, computing system 160 may be configured to store and execute instructions for operating BMS 174 and a supervised DNN for indicating the SoH (Solar Hour) of vehicle 158's battery. BMS 174 and / or computing system 160 may detect and record battery characteristics, including temperature, voltage, and current, via CAN data every predefined number of hours and / or days. The supervised DNN can use this information as input and generate an SoH indication for the battery. Based on the generated SoH indication, user feedback can be provided to the vehicle's user, indicating favorable directions for protecting the battery's SoH (e.g., avoiding three consecutive fast charges). These are just some examples of the many possible settings for the computing system 160.

[0051] The computing system 160 may include one or more processors. Furthermore, the computing system may have its own data storage device and / or use an external data storage device. The one or more processors may include one or more general-purpose processors and / or one or more dedicated processors. Where the processors include more than one processor, such processors may operate individually or in combination. The data storage device of the computing system 160 may include one or more volatile storage components and / or one or more non-volatile storage components, such as optical, magnetic, and / or organic storage devices. The data storage device may be integrated wholly or partially with one or more processors of the computing system 160 and may be communicatively coupled to the data storage device. In some embodiments, the data storage device of the computing system 160 may include instructions (e.g., program logic) that can be executed by the processor of the computing system 160 to perform various vehicle functions (e.g., the methods disclosed herein).

[0052] The term "computing system" can refer to data processing hardware, such as a CPU and / or GPU, and includes all kinds of devices, apparatuses, and machines for processing data, such as programmable processors, computers, multiprocessors, multiple computers, cloud computing, and / or embedded low-power devices (e.g., Nvidia Drive PX2). The system can also be, or further include, dedicated logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, the system may optionally include code that creates an execution environment for computer programs, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these. Computer programs can also be used to simulate the computing system.

[0053] A computer program, also referred to or described as a program (software, software application, application, module, software module, script, or code), can be written in any programming language, including compiled or interpreted languages, or declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may, but does not need to, correspond to a file in a file system. A program may be stored as part of a file containing other programs or data; for example, one or more scripts may be stored in a markup language document, in a single file dedicated to the program involved, or in multiple harmonizing files, such as a file containing one or more modules, subroutines, or code portions. A computer program may be deployed for execution on a single computer, or it may be deployed for execution on multiple computers located in one location or distributed across multiple locations and interconnected via a data communication network.

[0054] The processes and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform functions by running based on input data and producing output. The processes and logic flows can also be executed by dedicated logic circuitry, such as FPGAs or ASICs, or by a combination of dedicated logic circuitry and one or more programmable computers.

[0055] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, such as semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0056] Embodiments of the subject matter described in this specification can be implemented in computing systems that include back-end components, such as a data server, or middleware components, such as an application server, or front-end components, or combinations of one or more such back-end, middleware, or front-end components. The front-end components are, for example, client computers, web browsers, or applications with graphical user interfaces through which users can interact with implementations of the subject matter described in this specification. Components of the system can be interconnected via any form or medium of digital data communication, such as a communication network. Examples of communication networks include wired and / or wireless local area networks (“LANs”) and wired and / or wireless wide area networks (“WANs”), such as the Internet.

[0057] A computing system may include clients and servers. Clients and servers are typically geographically separated and usually interact via a communication network. The client-server relationship arises from computer programs running on respective computers that have a client-server relationship with each other. In some embodiments, the server transmits data, such as HTML pages, to a user device, for example, to display data to a user interacting with the device acting as a client and to receive user input from the user. Data generated at the user device, such as the result of user interaction, can be received from the device at the server.

[0058] Sensor 162 may include multiple sensors configured to detect information about the environment in which vehicle 158 is located, and one or more actuators configured to modify the position and / or orientation of the sensors. The sensors may include a Global Positioning System (“GPS”), an Inertial Measurement Unit (“IMU”), a radar unit, a laser rangefinder, and / or one or more lidar units and / or a camera. In some embodiments, sensor 162 may be implemented as multiple sensor units respectively mounted at corresponding locations on the vehicle (e.g., top side, bottom side, front side, rear side, right side, left side, etc.). Other sensors are also possible.

[0059] The vehicle communication system 164 can be any system that is directly and / or wirelessly coupled (wired or wirelessly) to one or more other vehicles, sensors, or other entities via a communication network. The wireless communication system 164 may include antennas and chipsets for communicating directly or via a communication network with other vehicles, sensors, servers, and / or other entities. The chipset or wireless communication system 164 can typically be configured to communicate according to one or more types of wireless communication (e.g., protocols), such as Bluetooth, communication protocols described in IEEE 802.11 (including any IEEE 802.11 revisions), cellular technologies (e.g., V2X, V2V, GSM, CDMA, UMTS, EV-DO, WiMAX, or LTE), ZigBee, Dedicated Short Range Communication (DSRC), and Radio Frequency Identification (“RFID”) communication. The wireless communication system 164 may also take other forms.

[0060] The propulsion system 166 can be configured to provide powered motion for the vehicle 158. The propulsion system 166 may include various components for providing such motion, including an engine / motor, an energy source, a transmission, and wheels / tires. The engine / motor may include any combination of an internal combustion engine, an electric motor (powered by a battery, fuel cell, and / or other energy storage device), and / or a steam engine. Other motors and engines are also possible.

[0061] The control system 168 can be configured to control the operation of the vehicle 158 and its components. The control system 168 may include various components, including a steering unit, throttle, braking unit, sensing system, navigation or path system, and obstacle avoidance system.

[0062] The perception system can be any system configured to process and analyze images and / or sensor data captured by sensors (e.g., cameras, radar, and / or lidar) of vehicle 158 to identify objects and / or features in the environment in which vehicle 158 is located, such as traffic signals and obstacles. For this purpose, the perception system may use object recognition algorithms, structure of motion (“SFM”) algorithms, video tracking, or other computer vision techniques. In some embodiments, the perception system may be additionally configured to map the environment, track objects, estimate object speeds, etc.

[0063] In at least one embodiment, the entire system may include a perception subsystem for identifying objects, a planning subsystem for planning a smooth driving path around obstacles, and a control subsystem for executing the path from the planning device.

[0064] Power supply 170 may be an energy source that powers, wholly or partially, the engine / motor of vehicle 158 and / or the electrical equipment of vehicle 158. The vehicle's engine / motor may be configured to convert power supply 170 into mechanical energy. Energy sources for power supply 170 include, for example, gasoline, diesel, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other electrical sources. One or more energy sources may additionally or alternatively include any combination of fuel tanks, batteries, capacitors, and / or flywheels. In some embodiments, the energy source may also power other systems of vehicle 158.

[0065] In one embodiment, the power supply 170 is a battery communicatively coupled to the BMS 174. The BMS 174 monitors various characteristics of the power supply 170, including battery temperature, battery voltage, battery current, and battery charging and discharging data. This information may be stored locally by the BMS 174 and / or the computing system 160. The BMS 174 may also transmit such monitoring information to an external storage device (e.g., to the cloud) via the vehicle communication system 164. The BMS 174 may regulate the operating conditions of the power supply 170, for example, cooling the battery temperature to a predefined threshold temperature range.

[0066] The computing system 160 may be configured to generate a SoH using a supervised DNN of the present disclosure. For example, in one embodiment, the computing system includes: at least one data storage device configured to store computer program instructions; and at least one processor communicatively coupled to the at least one data storage device, the at least one processor configured to execute the computer program instructions to perform the following: determining a battery health status indication, further including the steps of: receiving battery characteristics and process parameters; training a first supervised deep neural network, wherein the received characteristics are inputs to the first supervised DNN and the received process parameters are outputs to the supervised DNN; training an unsupervised AI estimator based on features extracted from the first supervised DNN, wherein the received characteristics are inputs to the unsupervised AI estimator; training a second supervised DNN using identified clusters from the unsupervised AI estimator; verifying the identified clusters using the health status indication; and determining the battery health status indication using the second supervised DNN. The at least one data storage device may be a non-transitory computer-readable medium encoded with instructions that, when executed by the at least one processor, cause the processor to execute the instructions. The SoH indication can be input to the BMS174 so that the BMS174 can adjust the operating conditions of the power supply 170. In another embodiment, the supervised DNN used to generate the SoH indication can be executed by one or more processors of the BMS174.

[0067] User interface system 172 may include software, human-machine interface (“HMI”), and / or peripheral devices configured to enable vehicle 158 to interact with external sensors, other vehicles, external computing devices, and / or users. For this purpose, peripheral devices may include, for example, wireless communication systems, touchscreens, microphones, and / or speakers. SoH indicators or related metrics (e.g., SoC) may be displayed through user interface system 172.

[0068] In some embodiments, vehicle 158 may include one or more elements as a supplement to or alternative to the illustrated components. For example, vehicle 158 may include one or more additional interfaces and / or power supplies. Other additional components are also possible. In this embodiment, the data storage device of computing system 160 may also include instructions executable by the processor of computing system 160 to control additional components and / or communicate with additional components.

[0069] Furthermore, although each component and system is shown as being integrated into vehicle 158, in some embodiments, one or more components or systems may be detachably mounted on vehicle 158 using wired or wireless connections or otherwise (mechanically or electrically) connected to vehicle 158.

[0070] In one exemplary embodiment, the cloud server and / or backend server may be configured to perform DNN compression (e.g., using similarity-based filters for reduction, quantization, or other DNN compression methods). Once the DNN is compressed, the cloud server and / or backend server can deploy the DNN to vehicle 158, and the vehicle can use the compressed DNN to perform inference on embedded hardware of vehicle 158, such as through computing system 160. Therefore, a supervised DNN for generating SoH indications for power supply 170 can be generated in real time within vehicle 158.

[0071] The computing system 160 can run DNN predictions on embedded hardware with potentially limited computing power at runtime. Therefore, multiple functions can run simultaneously on the computing system. The compressed DNN size allows for a smaller footprint in the computing system 160's memory and enables rapid transmission via wireless connections. Therefore, when an improved version of the DNN is released, it can be easily deployed to the vehicle 158 via the vehicle communication system 164 and processed by the computing system 160.

[0072] Although the functions of the disclosed embodiments and the system components for providing those functions have been discussed with reference to specific terms indicating the functions to be provided, it should be understood that in practice, the functions of the components may be provided at least in part, and existing and known components may be included in conventional transport vehicles.

[0073] For example, as discussed above, the disclosed embodiments at least partially use software to perform functions to achieve the measurement and analysis of data, using software code stored on a non-transitory computer-readable medium running on one or more processors in the transport vehicle. Such software and processors can be combined to form at least one controller coupled to other components of the transport vehicle to integrate with a vehicle navigation system and multiple sensors to support and provide autonomous and / or auxiliary transport vehicle functions. These components can be coupled to at least one controller to communicate and control via the transport vehicle's CAN bus or other buses (e.g., Flexray).

[0074] It should also be understood that the currently disclosed embodiments can be implemented using dedicated or shared hardware included in the transport vehicle. Therefore, components of the module can be used by other components of the transport vehicle to provide vehicle functionality without departing from the scope of this disclosure.

[0075] Exemplary embodiments are provided to make this disclosure sufficient and to fully convey the scope to those skilled in the art. Numerous specific details, such as examples of specific components, apparatuses, and methods, are set forth to provide a full understanding of embodiments of this disclosure. In some illustrative embodiments, well-known processes, well-known apparatus structures, and well-known techniques are not described in detail.

[0076] The terminology used herein is for describing particular illustrative embodiments only and is not intended to be limiting. Unless the context otherwise requires, the singular forms of the foregoing elements may be intended to include the plural forms. The method steps, processes, and operations described herein should not be construed as necessarily having to be performed in the particular order discussed or described, unless specifically determined that the order of performance or a particular order is inherently necessary for the operability of the embodiments. It should also be understood that additional or alternative steps may be employed.

[0077] The disclosed embodiments include the methods described herein and their equivalents, a non-transitory computer-readable medium programmed to perform the methods, and a computing system configured to perform the methods. Furthermore, a vehicle is included, comprising any of the methods, a non-transitory computer-readable medium programmed to implement instructions or perform the methods, and a system for performing the methods. The computing system and any sub-computing system will generally include a machine-readable storage medium containing executable code; one or more processors; a storage device coupled to the one or more processors; an input device; and an output device coupled to the one or more processors to execute the code. The machine-readable medium may include any mechanism for storing or transmitting information in a machine-readable form, such as a computer processor. The information may, for example, be stored in volatile or non-volatile memory. Furthermore, the functionality of the embodiments can be implemented using embedded devices and an online connection to a cloud computing infrastructure, which may be available through a radio connection (e.g., wireless communication) to such infrastructure.

[0078] It is understood that embodiments and functional operation of the subject matter described herein can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and their structural equivalents, or one or more combinations thereof. Embodiments of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more computer program instruction modules, which are encoded on a tangible, non-transitory storage medium for execution by a data processing apparatus or for controlling the operation of the data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of the above. Alternatively or additionally, program instructions can be encoded on artificially generated propagation signals, such as machine-generated electrical signals, optical signals, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus.

[0079] While this specification contains numerous specific implementation details, these details should not be construed as limiting the scope of the invention or the scope of claims, but rather as descriptions of features that may be unique to particular embodiments of a particular invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, different features described in the context of a single embodiment may be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in a specific combination, or even originally claimed on their own, in some cases one or more features from a claimed combination may be removed from said combination, and the claimed combination may implement sub-combinations or variations thereof.

[0080] Similarly, although operations or executions are described in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific or sequential order shown, or to perform all illustrated operations to obtain the desired result. In a given environment, multitasking and parallel processing may be advantageous. Furthermore, the separation of different system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0081] Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. For example, the operations described in the claims can be performed in different orders and still achieve the desired result. As an example, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain situations, multitasking and parallel processing may be advantageous.

Claims

1. A computing system comprising: at least one data storage device configured to store computer program instructions; and at least one processor communicatively coupled to the at least one data storage device, the at least one processor configured to execute the computer program instructions to perform the following, including: determining a state of health indication for a battery, further comprising the steps of: receiving characteristics of the battery and process parameters; training a first supervised deep neural network, wherein the received characteristics are inputs to the first supervised deep neural network and the received process parameters are outputs of the first supervised deep neural network; training an unsupervised Al estimator using one or more clustering methods based on features extracted from the first supervised deep neural network, wherein the received characteristics are inputs to the unsupervised Al estimator; training a second supervised deep neural network using identified clusters from the unsupervised Al estimator, wherein the received characteristics are inputs to the second supervised deep neural network; validating the identified clusters by the state of health indication; and determining the state of health indication for the battery using the second supervised deep neural network. The steps of training the unsupervised Al estimator and the steps of training the second supervised deep neural network are repeated after the third training step and before the validation step until a convergence condition is met.

2. The computing system of claim 1, wherein, In the second training step, the one or more clustering methods include partitioning continuous values of outputs of the unsupervised Al estimator into discretized bins.

3. The computing system of claim 1, wherein, In the second training step, the one or more clustering methods include applying a regression deep neural network to outputs of the unsupervised Al estimator.

4. The computing system of claim 1, wherein, In the second training step, the one or more clustering methods include applying subspace clustering by an autoencoder to outputs of the unsupervised Al estimator for dimensionality reduction.

5. The computing system of claim 1, wherein, The received characteristics include at least one of a group comprising a battery temperature, a battery voltage, and a battery current.

6. The computing system of claim 1, wherein, The received process parameters include at least one of a group comprising a charge rate of the battery, a state of charge of the battery, and a process temperature.

7. The computing system of claim 1, wherein, 8. A computer-implemented method for determining a state of health indication for a battery, the method comprising: receiving characteristics of the battery and process parameters; training a first supervised deep neural network, wherein the received characteristics are inputs to the first supervised deep neural network and the received process parameters are outputs of the first supervised deep neural network; training an unsupervised Al estimator using one or more clustering methods based on features extracted from the first supervised deep neural network, wherein the received characteristics are inputs to the unsupervised Al estimator; training a second supervised deep neural network using identified clusters from the unsupervised Al estimator, wherein the received characteristics are inputs to the second supervised deep neural network; validating the identified clusters by the state of health indication; and determining the state of health indication for the battery using the second supervised deep neural network. ​ 9. The computer-implemented method of claim 8, wherein, After the third training step and before the validation step, the steps of training the unsupervised AI estimator and training the second supervised deep neural network are repeated.

10. The computer-implemented method of claim 8, wherein, In the second training step, the one or more clustering methods include partitioning continuous values of the output of the unsupervised AI estimator into discretized bins.

11. The computer-implemented method of claim 8, wherein, In the second training step, the one or more clustering methods include applying a regression deep neural network to the output of the unsupervised AI estimator.

12. The computer-implemented method of claim 8, wherein, In the second training step, the one or more clustering methods include applying subspace clustering by autoencoder to the output of the unsupervised AI estimator for dimensionality reduction.

13. The computer-implemented method of claim 8, wherein, The received characteristics include at least one of a group including a battery temperature, a battery voltage, and a battery current.

14. The computer-implemented method of claim 8, wherein, The received process parameters include at least one of a group including a charge rate of the battery, a state of charge of the battery, and a process temperature.

15. A non-transitory computer-readable medium encoded with instructions that, when executed by at least one processor, cause the processor to perform the following operations: receiving characteristics and process parameters of a battery; training a first supervised deep neural network, wherein the received characteristics are inputs to the first supervised deep neural network and the received process parameters are outputs of the first supervised deep neural network; training an unsupervised AI estimator using one or more clustering methods based on features extracted from the first supervised deep neural network, wherein the received characteristics are inputs to the unsupervised AI estimator; training a second supervised deep neural network using identified clusters from the unsupervised AI estimator, wherein the received characteristics are inputs to the second supervised deep neural network; verifying the identified clusters by a state of health indication; and determining a state of health indication of the battery using the second supervised deep neural network.

16. The non-transitory computer-readable medium of claim 15, wherein, After the third training step and before the validation step, the steps of training the unsupervised AI estimator and training the second supervised deep neural network are repeated.

17. The non-transitory computer-readable medium of claim 15, wherein, In the second training step, the one or more clustering methods include partitioning continuous values of the output of the unsupervised AI estimator into discretized bins.

18. The non-transitory computer-readable medium of claim 15, wherein, In the second training step, the one or more clustering methods include applying a regression deep neural network to the output of the unsupervised AI estimator.

19. The non-transitory computer-readable medium of claim 15, wherein, In the second training step, the one or more clustering methods include applying subspace clustering by autoencoder to the output of the unsupervised AI estimator for dimensionality reduction.

20. The non-transitory computer-readable medium of claim 15, wherein, The received characteristics include at least one of a group including a battery temperature, a battery voltage, and a battery current, and wherein the received process parameters include at least one of a group including a charge rate of the battery, a state of charge of the battery, and a process temperature.

Images