Intelligent preconditioning for high voltage electric vehicle batteries

Abstract

A system pre-conditions a vehicle's battery pack to support fast charging. The system detects triggers indicating that the vehicle is about to travel or that the vehicle's battery pack has decreased to a predetermined capacity. The system collects multiple samples of the vehicle's location data. The system predicts the vehicle's destination based on the samples. The system determines a user's charging habits based on the user's past charging behavior. The system determines a confidence score for the predicted destination and the determined habits. The system determines whether to schedule battery pack pre-conditioning based on the confidence score reaching a threshold.

Description

Background Technology

[0001] During driving, an electric vehicle (EV) can be primarily powered by a battery pack containing multiple cells. The battery pack's power capacity can decrease as electricity is consumed by various systems, such as propulsion, climate control, and entertainment systems. An EV's driving range (historically a key performance metric) is at least in part based on the battery pack's power capacity. At any given time, the user can choose to recharge the EV's battery pack, restoring its capacity to provide power and range. A faster restoration of the battery pack's capacity means EV users can resume operating the EV more quickly.

[0002] The goal of reducing recharging time has led to a relatively recent boom in fast-charging infrastructure. Many today's EVs can be fast-charged at a minimum of 150kW via technologies such as DC fast charging. For example, most EVs released in 2019 can be charged to 80% of their associated battery pack capacity in 30 minutes using fast-charging technology. Charging at higher power levels can improve the convenience of the user experience by reducing the associated downtime of EVs. Summary of the Invention

[0003] According to embodiments of the disclosed technical solution, a system can pre-condition a vehicle's battery pack to support fast charging. The system may include a processor and a memory communicating with the processor. The memory may store multiple instructions executable by the processor to cause the system to detect triggers indicating that the vehicle is about to travel or that the vehicle's battery pack has decreased to a predetermined capacity. The memory may include multiple samples of the vehicle's location data collected by the system. The memory may further include instructions to cause the system to predict the vehicle's destination based on the samples. The memory may further include instructions to cause the system to determine a user's charging habits based on the user's previous charging behavior. The memory may further include instructions to cause the system to determine the predicted destination and a confidence score for the determined habits. The memory may further include instructions to cause the system to determine whether to schedule battery pack pre-conditioning based on a confidence score reaching a threshold. The memory may further include instructions to cause the system to determine whether a charging station exists at the predicted destination. Pre-conditioning of the vehicle's battery pack may involve systematically increasing the battery pack's temperature. The memory may further include instructions to cause the system to determine an estimated arrival time of the vehicle at the predicted destination and to determine a pre-conditioning time prior to the estimated arrival time when the vehicle should begin pre-conditioning of the battery pack. The memory may further include instructions to cause the system to determine a time window required to raise the temperature of the battery pack to a target pre-conditioning temperature. The memory may further include instructions to cause the system to compare the time window with the estimated arrival time of the vehicle at the predicted destination and to begin pre-conditioning of the battery pack based on the comparison. The system may determine the presence of a charging station at the predicted destination based on aggregate data published by multiple other vehicles attempting to charge at the predicted destination. Instructions to cause the system to predict the vehicle's destination may be based on the determination that no destination has been set in the vehicle's navigation function. The memory may further include instructions to cause the system to cancel the battery pack's scheduled or currently performed pre-conditioning based on a confidence score that has not reached a threshold. The behavior may be further based on at least one of the following: the predicted location, the total distance driven in a day, the total distance driven since the last known charging event, the presence of other users or occupants in the vehicle, the price of recharging at a charging station at the predicted location, scheduled events and appointments stored in the user's personal computing device, the predicted driver of the vehicle, the remaining state of charge of the battery pack, or whether amenities are available near a charging station at the predicted location.

[0004] According to embodiments of the disclosed technical solution, a computer-implemented method can pre-condition a vehicle's battery pack to support fast charging. The method can detect triggers indicating that the vehicle is about to travel or that the vehicle's battery pack has decreased to a predetermined capacity. The method may further include collecting multiple samples of the vehicle's location data. The method may further include predicting the vehicle's destination based on the samples. The method may further include determining a user's charging habits based on the user's previous charging behavior. The method may further include determining a confidence score for the predicted destination and the determined habits. The method may further include scheduling battery pack pre-conditioning based on the confidence score reaching a threshold. The method may further include determining whether a charging station exists at the predicted destination. Pre-conditioning of the vehicle's battery pack can be achieved by systematically increasing the battery pack's temperature. The method may further include determining an estimated arrival time for the vehicle to reach the predicted destination and determining a pre-conditioning time prior to the estimated arrival time when the vehicle should begin pre-conditioning the battery pack. The method may further include determining a time window required to raise the battery pack's temperature to a target pre-conditioning temperature. The method may further include comparing a time window with an estimated arrival time for the vehicle to reach the predicted destination and initiating pre-adjustment of the battery pack based on the comparison. Determining the presence of a charging station at the predicted destination may be based on aggregate data published by multiple other vehicles attempting to charge at the predicted destination. The prediction of the vehicle's destination may be based on the determination that no destination has been set in the vehicle's navigation function. The method may further include canceling scheduled or currently performed pre-adjustment of the battery pack based on a confidence score not reaching a threshold. The behavior may further be based on at least one of the following: the predicted location, the total distance driven in a day, the total distance driven since the last known charging event, the presence of other users or occupants in the vehicle, the price of recharging at a charging station at the predicted location, scheduled events and appointments stored in the user's personal computing device, the predicted driver of the vehicle, the remaining state of charge of the battery pack, or the availability of amenities near a charging station at the predicted location.

[0005] Other objects, advantages, and novel features of the invention will become apparent from the following detailed description of one or more preferred embodiments, taken in conjunction with the accompanying drawings. Attached Figure Description

[0006] Figure 1 An example system for predicting whether a vehicle should begin a battery pack preconditioning process, according to an embodiment of the present technical solution, is shown.

[0007] Figure 2 An example flow illustrating the process implemented by the travel change monitor according to an embodiment of the present technical solution is shown.

[0008] Figure 3 An example flow illustrating a process that can be implemented by a pre-adjustment scheduler according to an embodiment of the present technical solution is shown.

[0009] Figure 4 A computing device is shown according to an embodiment of the disclosed technical solution.

[0010] Figure 5 The network configuration according to an embodiment of the disclosed technical solution is shown.

[0011] Figure 6 Example network and system configurations are shown according to embodiments of the disclosed technical solutions. Detailed Implementation

[0012] As used herein, the term "vehicle" refers to an electric vehicle, a hybrid vehicle, or any vehicle that utilizes a battery pack, at least in part, to power its propulsion system. Hybrid vehicles, in addition to an internal combustion engine or hydrogen fuel cell, may also utilize a battery pack to provide propulsion.

[0013] As used herein, the term "DC fast charging station" refers to a type of fast charging that utilizes direct current (DC). However, other types of fast charging may be used without departing from the scope of this technical solution, provided that these other types can be used with or benefit from the vehicle pre-conditioning routine. For the sake of simplicity in the following discussion, "DC fast charging" will be used as an example type of fast charging, but other types of fast charging can be applied to the disclosed technical solution. Moreover, other types of charging may be used, although not necessarily considered "fast," if such charging routine can be used with or benefit from the vehicle pre-conditioning routine, whether applied to the vehicle's battery pack or to another vehicle component.

[0014] To enable DC fast charging of electric vehicles (EVs) at high power levels (such as 150 kW or greater), it is preferable to first perform a pre-conditioning routine on the vehicle's battery pack. This pre-conditioning routine may include reducing cooling and / or increasing the heat of the battery pack to intentionally raise the temperature of the associated batteries and battery cells. Reducing cooling can be achieved by reducing or stopping the flow of coolant, refrigerant, air, and / or the like, any of which can be thermally coupled to the vehicle's battery pack. Increasing the heating of the battery pack can mean actively heating via resistance heating technology, liquid heating via coolant, refrigerant, or air, and / or operating vehicle systems (such as one or more in the vehicle's engine) in an inefficient manner to raise the battery pack temperature. Raising the temperature of the battery pack allows the associated battery cells to absorb energy more quickly from the DC fast charging process without causing damage, and / or can extend the service life of the battery pack. Using a pre-conditioning process, the battery pack can be charged more fully within a given time window. Therefore, compared to DC fast charging without a pre-conditioning process, a pre-conditioning process can maximize or at least increase the EV's range within a given time window.

[0015] The difficulty in implementing pre-tuning in the past may have lay in determining the appropriate "trigger" to initiate pre-tuning of the EV. Examples of triggers for initiating the pre-tuning routine can include variations of the methods defined below.

[0016] "When navigation restarts." When a user explicitly sets their EV's navigation destination to a DC fast-charging station using a Human-Machine Interface (HMI), a trigger can be set to determine the appropriate time to begin pre-conditioning the battery pack before arriving at the fast-charging station. The HMI can take the form of a vehicle touchscreen, keypad, microphone, camera, gesture recognition sensor, etc., facilitating the transmission of user input to the vehicle's computing system. In this way, the battery pack can reach a threshold temperature that has increased upon arrival at the DC fast-charging station. It is important to note that the navigation destination can be set locally via the HMI, rather than via projected mode when using a personal communication device, smartphone, tablet, laptop, or similar device.

[0017] "At departure." A trigger can be established when the vehicle's computing system can notify the user of their intention to depart at a specific future time, while the vehicle can be connected to a power source (such as a charging adapter or charging station). The user can indicate this intention either via an HMI or using other methods (such as a software application running on a smartphone, tablet, laptop, desktop computer, or the like). The time period between the user's indication of their intention and the expected departure time determines whether fast charging should be expected to occur and whether pre-setting should be scheduled. Based on the length of the time period, the vehicle charging system can choose to fast charge for the entire time period, for a portion of the time period, or not fast charge at all.

[0018] Both "when navigation restarts" and "when departing" triggering may fail to capture a large number of anticipated or unforeseen circumstances, leaving users with suboptimal outcomes. Suboptimal outcomes could include additional time required for DC fast charging and / or the vehicle's battery pack not being heated to a high temperature and subsequently not being connected to a DC fast charging station. Incorrectly predicting when DC fast charging will occur and unnecessarily raising the battery pack's temperature can accelerate battery pack degradation over time, shortening its lifespan or even causing damage. Therefore, incorrect predictions about when to trigger the pre-conditioning process can be costly for EV users, both in terms of the inconvenience of additional downtime during recharging and premature battery pack replacement.

[0019] The computing system according to this technical solution can more accurately predict when a user intends to connect his / her EV to a DC fast charging station. This prediction can be made early enough to complete the battery pack pre-conditioning routine before connecting to the DC fast charging station at the travel destination. Pre-conditioning the battery pack can maximize or at least increase the energy throughput throughout the DC fast charging process and shorten the time required to restore the EV's battery capacity.

[0020] The trip management model can receive a given state and historical driving behavior data as input. The given state can include various parameters such as the current state of charge (SoC) of the battery pack, the current driver of the vehicle, the current vehicle efficiency per kilowatt-hour of distance, the vehicle model or type, date and time, calendar events, and similar parameters. Based on one or more of these inputs, the trip management model can generate a list data structure, such as tuples, which, for example, includes one or more predicted destinations for the user's EV. Each of the predicted destinations can be associated with a confidence score. The confidence score indicates the probability or degree of certainty that the predicted destination can be expected to be correct. The trip management model can generate this data using short-term memory (LSTM) networks, deep learning techniques, neural network-based techniques, machine learning techniques, heuristic techniques, and similar techniques.

[0021] The analytics cluster can receive bounding boxes of geographic coordinates, individual geographic coordinates with predefined radii, and / or equivalent data defining geographic regions as input. Based on one or more of these inputs, the analytics cluster can generate a list of DC fast charging stations by referencing databases, indexes, or other storage systems and applying filtering techniques at least in part based on geographic coordinates or geographic input data. The analytics cluster can respond in real time to changes in the vehicle charging infrastructure. For example, the analytics cluster can revise and / or regenerate its list of DC fast charging stations based on received data indicating that charging stations have been relocated, closed, modified to include new plug types, new charging capabilities, and / or operate according to revised schedules. The data that the analytics cluster can operate on may include fleet telemetry data collected from multiple vehicles, and may operate using only fleet telemetry data.

[0022] The user interface can allow the EV user to confirm and / or decline a predicted destination. For example, the user interface can present a specific predicted destination to the user and prompt the user to confirm or decline his or her intention to drive the EV to the predicted destination. The prompt can be displayed to the user via an HMI or forwarded to the user's personal communication device, such as a smartphone, tablet, laptop, and the like. Alternatively or additionally, the user interface can present the user with more general queries, such as whether the user plans to fast charge the EV and / or whether the user plans to visit a specific location.

[0023] A daemon can execute as a background process within the operating system environment of the EV's computing system. The daemon can issue commands to the EV's battery management system to begin pre-conditioning, poll the battery pack temperature, and poll the vehicle status. Vehicle status can be a subset of states utilized in the context of the trip management model discussed earlier, and includes one or more of the following: the battery pack's current state of charge (SoC), the vehicle's current driver, the current vehicle efficiency per kilowatt-hour of distance, the vehicle's model or type, date and time, calendar events, and the like. Vehicle status, along with other attributes and predictors, can be specifically designed to generate payloads for the trip management model. Either the trip change monitor and the pre-conditioning scheduler, which will be described subsequently, can be implemented as a daemon.

[0024] Figure 1 This illustration describes a system 100 according to an embodiment of the present technical solution, the system being used to predict whether a vehicle should initiate a battery pack pre-conditioning process. System 100 may include a cloud component 165, which can communicate with a gateway 125 via a network connection. The network connection can provide a wired or wireless direct connection. The network connection can be provided using any suitable physical interconnection and / or air modulation technologies and protocols that will be readily understood by those skilled in the art, including TCP / IP, digital cellular telephony, WiFi, etc. Near Field Communication (NFC) and the like. Gateway 125 can further communicate with one or more vehicles 130.

[0025] Cloud 165 may include an analytics cluster 105, a trip management model 110, a charging behavior model 115, and a reporting / event analysis component 120. Analytics cluster 105 may include computing and storage resources capable of performing data processing and storage. Analytics cluster 105 may include, for example, a NoSQL data storage structure for a real-time, second-accurate dataset of DC fast charging stations. The DC fast charging station dataset can be populated from various vehicle events and the previously discussed collected fleet vehicle telemetry data. A data structure called a “charging block” can be generated from the raw fleet vehicle telemetry data to capture when, where, and / or under what conditions the participating vehicles are charging or have already charged their respective battery packs. Table 1 provides an overview of sample data and / or metadata that can be stored in analytics cluster 105 and associated with each DC fast charging station record.

[0026]

[0027] Table 1

[0028] Analytics cluster 105 may include microservices that iterate over real-time (currently running) and historical charging sessions, and / or charging block data received by gateway 125 via a pre-stored data exchange mechanism. Microservices may run miniaturized models that can predict and classify charging station types using the metadata listed in Table 1. The consumption of the data in Table 1 can be performed using a GraphQL-driven application programming interface (API), which enables filtering of predicted DC fast charging stations by parameterized radius, search location, geographic region, and / or similar parameters. The metadata stored in analytics cluster 105, as shown in Table 1, can be used to compare DC fast charging stations to make recommendations to users, assess site availability or operational status, and similar parameters.

[0029] Trip management model 110 may include a cluster of computing resources, artificial intelligence (AI) models, and wrappers. The AI ​​models can be constructed from machine learning algorithms. Given n samples of location data for an ongoing trip, trip start time, and / or one or more user identifiers, trip management model 110 can predict possible destinations and generate confidence scores. Potential destinations and confidence scores can be generated and personalized based on the user driving the EV, the user's travel history, and the user's charging patterns. The predicted potential destinations can be in the form of a list of destinations that trip management model 110 predicts the user may be traveling to. The confidence score can be expressed as the probability or likelihood that the predicted destination is correct. In one embodiment, the confidence score can be expressed as a value between 0 and 1. Each destination in the destination list generated by trip management model 110 can be associated with its respective confidence score. The predictions generated by trip management model 110 can be continuously updated in real time during the trip. During the trip, trip management model 110 can receive driver behavior input and location data samples collected at regular intervals, irregular intervals, or event-triggered intervals. As more data can be collected during travel, this data can be used by the trip management model 110 to further refine the list of predicted destinations and improve the accuracy of predictions.

[0030] Trip management model 110 can persistently store or otherwise store baseline truth (ground reality) or baseline truth events at the end of each trip to remain relevant, accurate, and adaptive to changes in user behavior. Some examples of baseline truth that can be stored are the initially predicted travel time, the actual travel time, whether the actual destination was registered as a change from the previously entered destination, the SoC at the start and end of the trip, the kilowatt-hours used, the route distance, waypoints that formed the trip, and the like. Trip management model 110 can be periodically retrained based on baseline truth to further improve the accuracy of trip management model 110. Baseline truth can be objective empirical data generated during the trip, contrary to data that can be predicted, expected, or determined by inference.

[0031] Trip management model 110 can distinguish between users who can drive the EV and other users of the EV. Some users of the EV can be drivers, while others are not. The driving and / or charging behavior of the EV driver can be influenced by the presence of another user in the EV who may not be a driver. For example, when a child user may also be present, the driver may be less likely to recharge the EV at a DC fast charging station. An EV can have several drivers because it can be shared within homes, car-sharing platforms, rental car fleets, company vehicle fleets, and the like. Each driver can have different historical driving behavior, trip history, and charging behavior. As in the previous example, a user who is under the driving age may not be a driver but may still be considered an EV user for other purposes. Trip management model 110 can be based on seat presets, detected quality on the seat surface, and information from the vehicle's HMI. Pairing data, key fobs used to enter and / or start the EV, and other associated metadata are used to determine the current driver of the EV from all known users. Identifying the driver and other users can play a crucial role in modeling predicted destinations, confidence scores, and charging habits. Trip management model 110 can be incorporated into the EV system software using a simplified wrapper that works in conjunction with trip management model 110. The wrapper can match predicted destinations with DC fast charging stations and user charging habits based on previous charging behavior (including previous DC fast charging behavior, and more generally, including other factors). As a result of the matching, the wrapper can output one or more charging station destinations, each associated with a confidence score.

[0032] The report / event analysis component 120 can be used to verify the effectiveness of the pre-conditioning process disclosed according to this technical solution. The report / event analysis component 120 can provide key engineering feedback quantifying the effectiveness of the system 100 in the following aspects: providing accurate prediction of the vehicle's destination, whether the vehicle will be quickly charged upon arrival at the destination, and whether pre-conditioning should be arranged.

[0033] The determination of a user's charging habits at the predicted destination for vehicle 130 can be based on the results generated by charging habit model 115. Charging habit model 115 can be specific to each user of vehicle 130 and can capture a user's habit of utilizing DC fast charging based on historical user data. For example, charging habit model 115 can determine that a user has a habit of DC fast charging vehicle 130 when the state of charge of battery pack 160 falls within a defined range. This range could, for example, be a remaining capacity of battery pack 160 of less than 10%. Charging habit model 115 can also evaluate other factors in predicting the likelihood of a user charging based on factors such as total driving distance in a day, total driving distance since the last known charging event, date and time, presence of other users or occupants in the EV, current weather and / or temperature, price of recharging at a particular charging station, location of the charging station, scheduled events and appointments stored in the user's personal communication device, typical driving distance in a given day, predicted driver, and availability of specific amenities near the charging station (such as lounges, food and beverage, shopping, and parks). In this example, charging habit model 115 can utilize the user's historical driving and charging data to determine the likelihood that the user will quickly charge upon reaching a predicted and / or confirmed destination. Charging habit model 115 can be periodically retrained as more historical user data can be generated. In embodiments, charging habit model 115 can be implemented using neural networks with Long Short-Term Memory (LSTM) or other machine learning algorithms.

[0034] Vehicle 130 may be an EV and is powered by a battery pack 160, which may include one or more battery cells as described above. Vehicle 130 may have an operating system environment in which various software can be executed. Vehicle 130 can be understood as an edge device in relation to the topology of system 100. Trip change monitor 135 may execute a set of routines in response to various triggers. As discussed above, these triggers may prompt trip change monitor 135 to evaluate whether pre-conditioning of vehicle battery pack 160 should be scheduled. For example, such triggers may include: the start of a trip by setting or changing a navigation destination using the vehicle HMI, the start of a trip by the driver, when battery pack 160 decreases to a predetermined SoC, and similar situations. Trip change monitor 135 may monitor driving and navigation modes. Trip change monitor 135 may cooperate directly or indirectly with cloud 165. Other components of vehicle 130 may cooperate with cloud 165 by using trip change monitor 135 as an intermediary or gateway. The trip change monitor 135 can collect real-time driving data and continuously stream the current location of vehicle 130 to trip management model 110 in cloud 165 at regular or irregular intervals. In addition to the current location, trip management monitor 135 can also stream one of more past n samples of location data individually or in batches. Trip change monitor 135 can also schedule or cancel pre-conditioning of vehicle 130 battery pack 160 by adding requests to and / or removing requests from scheduling queue 140. Other components of vehicle 130 can “subscribe” to or otherwise communicate with scheduling queue 140 to receive continuous updates as requests are added to and / or removed from scheduling queue 140.

[0035] Figure 2The process 200 that the trip change monitor 135 can execute is illustrated below. The trip change monitor 135 can initiate the execution of process 200 based on the occurrence of one or more triggers defined by S205 and S215 that can lead to pre-adjustment of the vehicle battery pack 160. Attached to S205 and S215, process 200 can be triggered based on the battery pack SoC decreasing to a predetermined capacity (such as 70%, 60%, 50%, etc.). The trip change monitor 135 can detect the start of a trip for vehicle 130 in S205. The detection of the start of the trip in S205 can occur regardless of the state of the vehicle 130's navigation system. On the other hand, in S210, the navigation system can be checked to determine whether the destination has been set by the vehicle driver, another user, or via an operating system environment running within vehicle 130 or by another software application (such as a smartphone application) communicating with vehicle 130 externally. In one example, the vehicle navigation system destination can be set and / or changed via an HMI. The checks that can occur in S205 can also occur in S215 in response to a change in the navigation destination. If the change has already occurred in navigation using the HMI, process 200 can continue to S220, where it can be determined whether the navigation destination has been set to a DC fast charging station. If so, process 200 can proceed to S225 to use an existing pre-conditioning routine and determine whether and when to pre-condition the vehicle battery pack 160 when DC fast charging is expected.

[0036] If the destination is not yet set as a DC fast charging station, process 200 can continue from S220 to S235, where the analysis cluster 105 can be used to determine whether the vehicle can connect to a DC fast charging station and whether pre-conditioning should be arranged in S245. The trip change monitor 135 can provide the analysis cluster 105 with trip destinations and historical radius data, for example, set via the HMI in S210. The analysis cluster 105 can process the trip destination and historical radius data to assess whether the trip destination has a DC fast charging station and whether it will be available for vehicle 130. This assessment can be based on data aggregated from fleets that have recently charged at or attempted to charge at the trip destination. In one example, only public DC fast charging stations can be considered by the analysis cluster 105 when assessing whether a trip destination has an available DC fast charging station. In another example, as a result of being a customer of a retail establishment, a member of a club, an employee of a company, or a similar status, a user may use a private or restricted DC fast charging station.

[0037] The analysis cluster 105 can also determine the user's status, whether a reservation has been made at a fast charging station, whether the fast charging station is available, and / or whether the user is a member of the fast charging station network, to compile a list of available DC fast charging stations. This list can be returned to process 200, which can predict whether pre-conditioning should be scheduled in S245 upon arrival at the travel destination. The list returned to process 200 can be based on a selection of DC fast charging stations from real-time, second-accurate records of all known DC fast charging stations discussed above. The list can be selected by applying one or more filters attached to the travel destination and a heuristic radius sent from the travel change monitor 135, based on any one of the metadata elements shown in Table 1. Based on the list, the travel change monitor 135 can determine that DC fast charging is likely to occur and can schedule pre-conditioning of the battery pack 160 in S245.

[0038] The trip change monitor 135 schedules pre-conditioning by adding requests to the scheduling queue 140. The scheduling queue 140 can be implemented in various data structures and can facilitate communication between the trip change monitor 135, the pre-conditioning scheduler 145, and the battery management system 155. The battery management system 155 can perform functions such as monitoring the cell health of the battery pack 160, controlling the charge rate during regenerative braking and connection to a charging station, monitoring the battery pack temperature, and directly controlling the pre-conditioning process. The battery management system 155 can be directly controlled by the pre-conditioning scheduler 145, and otherwise can be isolated from components other than the battery pack 160. For example, the pre-conditioning scheduler 145 can issue commands to the battery management system 155 to start or stop pre-conditioning of the battery pack 160 based on the contents of the scheduling queue 140. In one embodiment, one or more of the trip change monitor 135, the pre-conditioning scheduler 145, and the battery management system 155 may not communicate directly with each other; instead, communication may occur only through the scheduling queue 140. For example, one component can write a request to scheduling queue 140, while another component can read that request from scheduling queue 140. Alternatively or additionally, one component can "publish" to scheduling queue 140, while another component can "subscribe" to scheduling queue 140 to receive continuous updates as new requests are added and / or completed. Each request in scheduling queue 140 can represent a pending transaction and can be described according to the outline listed in Table 2 below.

[0039]

[0040]

[0041] Table 2

[0042] Return to Figure 2 In the discussion of S235, the list returned from cloud 165 may be empty, and / or the analysis cluster 105 may determine that no available DC fast charging station is located at the travel destination or within the heuristic radius of the travel destination. In this case, DC fast charging of vehicle 130 is unlikely, so the travel change monitor 135 can simply cancel any pre-scheduled adjustments and / or abandonment processes 200.

[0043] If the travel destination may not be set in the HMI of vehicle 130, process 200 continues to S230, where location data sampling can begin during the trip. Location data sampling, status updates, events, and similar data can be periodically sent to cloud 165 in S255. Specifically, predictions from trip management model 110 and charging habit model 115 can be subscribed to by the HMI of vehicle 130. Cloud 165 can publish its predictions when it deems it necessary and based on whether sufficient data has been provided from vehicle 130 to publish predictions. By subscribing to cloud predictions instead of requesting predictions, the coupling between vehicle 130 and cloud 165 can be reduced. As described above, trip management model 110 and charging habit model 115 can use location data sampling from the trip to predict the destination of vehicle 130, confidence score, and the user's habit of DC fast charging vehicle 130's battery pack 160 if the predicted destination is reached. The predicted destination, DC fast charging habits, and DC fast charging station availability may be interrelated and / or interdependent. For example, a predicted destination (even if correct) may be incorrect when combined with a correct prediction of a user's current charging habits under current conditions, if the charging station dataset of analysis cluster 105 indicates that no DC fast charging station is currently available due to occupancy, service interruption, or similar reasons. Similarly, a user's charging habits may depend at least in part on the predicted destination. Therefore, the data obtained from each of analysis cluster 150, trip management model 110, and charging habit model 115 can be compared and cross-checked before the predictions are returned to process 200 for trip change monitor 135. Alternatively or additionally, the predictions from trip management model 110 and charging habit model 115 may each be provided to process 200 along with corresponding charging station availability data from analysis cluster 105. Process 200 can then perform an analysis comparing and cross-checking the prediction and availability data. In S265, process 200 may assess whether the predicted destination has been determined with a sufficient confidence score and whether at least one DC fast charging station is available to make it necessary to arrange pre-conditioning of battery pack 160 for the predicted destination. Other considerations that may occur in S265 include whether the DC fast charging station is public, whether DC fast charging is possible and / or operational, and whether the DC fast charging station includes a charging outlet compatible with vehicle 130. In one embodiment, the confidence score may be compared to a threshold. If the threshold is reached, process 200 may either arrange pre-conditioning in S275 or cancel pre-conditioning in S270.Even if pre-adjustment can be cancelled in S270, if the trip is still in progress, process 200 can continue to receive new predictions from cloud 165 based on the vehicle's subscription, as additional user data, trip status data, and location data can be collected. Subsequent predictions can prompt process 200 to revisit the pre-adjustment. As discussed earlier, it is important that process 200 cancels pre-adjustment to prevent unnecessary temperature increases in battery pack 160 if the predicted destination cannot be determined with the required confidence score. In cases where pre-adjustment could actually be scheduled according to S275, but the user of vehicle 130 subsequently does not connect vehicle 130 to a DC fast charging station, trip change monitor 135 can record the erroneous prediction and provide the associated data to cloud 165 to help retrain the machine learning model. The associated data could include, for example, association identifiers, the predicted charging location, the actual destination where vehicle 130 was parked, the duration of parking, the SoC of battery pack 160 at the end of the trip, and the actual distance traveled. Association identifiers can allow tracking of erroneous pre-adjustment predictions and associated baseline truth events in a single transaction.

[0044] Figure 3The process 300, which can be executed by a pre-tuning scheduler 145, is illustrated. The pre-tuning scheduler 145 can be implemented as a daemon process as discussed previously. The pre-tuning scheduler 145 can execute in parallel with the trip change monitor 135 and / or in a separate thread within the operating system environment of the vehicle 130. The pre-tuning scheduler 145 can be responsible for listening for pre-tuning requests from the trip change monitor 135 that have been added to the scheduling queue 140, and scheduling the pre-tuning at the appropriate time. The pre-tuning scheduler 145 can have exclusive control over directing the battery management system 155 and can be communicatively isolated from all other components (except the battery management system 155 and the scheduling queue 140). This makes the pre-tuning scheduler 145 less susceptible to, for example, unauthorized access. Process 300 can begin in S305 whenever the pre-tuning scheduler 145 can be invoked, and / or at regular or irregular intervals, and whenever the state of the scheduling queue 140 changes. In S310, process 300 can determine, by referring to scheduling queue 140, whether a pending pre-conditioning request has been scheduled by trip change monitor 135 or has not yet been scheduled. If no request is pending in scheduling queue 140, any pending or currently executing pre-conditioning requests to battery management system 155 can be cancelled in S315 to avoid unnecessary heating of battery pack 160. If a pending pre-conditioning is currently scheduled, process 300 can proceed to S330, where battery management system 155 can further confirm in S320 that the state of charge (SoC) of battery pack 160 is qualified. If so, in S325, process 300 can determine whether the current temperature of battery pack 160 is lower than the expected temperature for DC fast charging. If so, process 300 can identify the time window "t0" required to raise the temperature of battery pack 160 to the expected DC fast charging temperature. In S335, the Real-Time Traffic Information (RTTI) application programming interface (API) can be invoked to predict the Estimated Time of Arrival (ETA) or the duration of travel to the destination. RTTI can receive real-time traffic data via Gateway 125 or another secure network and allows estimation of the time it will take to travel along the route to the destination. The ETA can be specified as "t1", such as... Figure 3As shown in S340, process 300 can determine whether ETA(t1) is less than or equal to the current time “t” plus the time window “t0” plus the time window heuristic “h”. The time window heuristic “h” can be a time window that can compensate for errors (such as battery-specific offsets, calibration errors, and similar data). In one example, assuming that a call to RTTI reveals ETA(t1) to be 4:05 p.m., the time window (t0) to be 7 minutes, and the time window heuristic (h) to be 1 minute, then at the current time of 3:57 p.m., S340 can begin pre-adjustment. This can be seen by applying the formula shown in S340 and solving for the current time “t” such that when 4:05 p.m. <= (current time “t”) + 7 + 1, pre-adjustment begins. When this condition is met, process 300 can proceed to S345, where a pre-adjustment request can be sent to the battery management system 155.

[0045] In systems discussed herein that collect personal information about users, or in situations where personal information can be used, users may be given the opportunity to control whether programs or features collect user information (e.g., location data, driving behavior, destination, charging behavior, and other user preferences) or to control whether and / or how content more relevant to the user is received from content servers. Additionally, data may be processed in one or more ways before it is stored or used to remove or restrict personally identifiable information. For example, a user's identity may be processed so that personally identifiable information cannot be determined for the user, or the user's geographic location may be generalized to the place where location information is obtained (e.g., generalized to a city, zip code, or state) so that the user's specific location cannot be determined. Conversely, in situations where a user is interacting with known friends or acquaintances, some or all of the personal information may be selectively made available to other users. Therefore, users can control how information is collected about them and how the systems disclosed herein use that information.

[0046] The currently disclosed technical solutions can be implemented in various components and network architectures and used with various components and network architectures. Figure 4This is an example computing device 20 suitable for implementing embodiments of the currently disclosed technical solutions. Device 20 may be, for example, a desktop or laptop computer, a vehicle-based computer or electronic control unit, a console, a set-top box, or a mobile computing device (such as a smartphone, tablet, or similar device). Device 20 may include a bus 21 interconnecting the main components of computing device 20, such as a central processing unit 24, memory 27 (such as random access memory (RAM), read-only memory (ROM), flash RAM, or the like), a user display 22 (such as a display screen), a user input interface 26, fixed storage 23 (such as a hard disk drive, flash memory, and the like), a removable media component 25, and a network interface 29. The user input interface may include one or more controllers and associated user input devices, such as a keyboard, mouse, touchscreen, and the like. The removable media component is operable to control and receive optical discs, flash drives, and the like. The network interface is operable to communicate with one or more remote devices via a suitable network connection.

[0047] Bus 21 allows data communication between the central processing unit 24 and one or more memory components as previously noted (which may include RAM, ROM, and other memories). Typically, RAM is the main memory where the operating system and applications are loaded. The ROM or flash memory component may contain (among other code) a basic input-output system (BIOS) that controls basic hardware operations, such as interaction with peripheral components. Applications residing with computer 20 are generally stored on and accessed via a computer-readable medium, such as a hard disk drive (e.g., fixed storage 23), an optical drive, a floppy disk, or other storage media.

[0048] Fixed storage 23 may be integrated with computer 20, or it may be detached and accessed through other interfaces. Network interface 29 may provide direct connectivity to a remote server via a wired or wireless connection. Network interface 29 may use any suitable technologies and protocols that will be readily understood by those skilled in the art (including digital cellular telephony, WiFi, etc.). Near-field communication (NFC) and similar technologies can be used to provide such connectivity. For example, as described in more detail below, network interface 29 can allow a computer to communicate with other computers via one or more local area networks, wide area networks, or other communication networks.

[0049] Many other devices or components (not shown) can be connected in a similar manner (e.g., document scanners, digital cameras, etc.). Conversely, Figure 4 Not all components shown are required for the implementation of this disclosure. Components can be interconnected in different ways as shown. Computers (such as...) Figure 4The operation of the computer shown is readily known in the art and will not be discussed in detail in this application. The code implementing this disclosure may be stored in a computer-readable storage medium (such as memory 27, fixed storage 23, removable media 25 or one or more) or at a remote storage location.

[0050] Figure 5 An example network arrangement according to an embodiment of the disclosed technical solution is shown. One or more devices 10, 11 (such as local computers, smartphones, tablet computing devices, and similar devices) can be connected to other devices via one or more networks 7. Each device can be a computing device as described above. The network can be a local area network, a wide area network, the Internet, or any other suitable communication network or multiple networks, and can be implemented on any suitable platform (including wired and / or wireless networks). The devices can communicate with one or more remote devices (such as server 13 and / or database 15). The remote devices can be directly accessed by devices 10, 11, or one or more other devices can provide intermediate access, such as when server 13 provides access to resources stored in database 15. Devices 10, 11 can also access remote platform 17 or services provided by remote platform 17, such as cloud computing deployments and services. Remote platform 17 may include one or more servers 13 and / or database 15.

[0051] Figure 6 An example arrangement according to an embodiment of the disclosed technical solution is shown. One or more devices or systems 10, 11 (such as a remote service or service provider 11), and user device 10 (such as a local computer, smartphone, tablet computing device, and similar device) can be connected to other devices via one or more networks 7. The network can be a local area network, a wide area network, the Internet, or any other suitable communication network or multiple networks, and can be implemented on any suitable platform (including wired and / or wireless networks). Devices 10, 11 can communicate with one or more remote computer systems (such as processing unit 14, database 15, and user interface system 13). In some cases, devices 10, 11 can communicate with user interface system 13, which provides access to one or more other systems (such as database 15, processing unit 14, or the like). For example, user interface system 13 can be a user-accessible webpage that provides data from one or more computer systems. User interface 13 can provide different interfaces to different clients, such as human-readable webpages provided to web browser clients on user device 10, and machine-readable APIs or other interfaces provided to remote service clients 11.

[0052] User interface 13, database 15, and / or processing unit 14 may be part of an integrated system or may include multiple computer systems communicating via a private network, the Internet, or any other suitable network. One or more processing units 14 may be part of a distributed system (such as a cloud-based computing system, search engine, content delivery system, or the like), which may also include database 15 and / or user interface 13, or may communicate with the database and / or user interface. In some arrangements, machine learning system 5 may provide various predictive models, data analytics, or the like to one or more other systems 13, 14, 15.

[0053] More generally, various embodiments of the currently disclosed technical solutions may include computer-implemented processes and apparatus for implementing these processes, or may be implemented in the form of computer-implemented processes and apparatus for implementing these processes. Embodiments may also be implemented as a computer program product containing computer program code containing instructions in a non-transitory and / or tangible medium (such as a floppy disk, CD-ROM, hard disk drive, USB (Universal Serial Bus) drive, or any other machine-readable storage medium) such that when the computer program code is loaded into and executed by the computer, the computer becomes an apparatus for implementing embodiments of the disclosed technical solutions. Embodiments may also be implemented, for example, in the form of computer program code, whether stored in a storage medium, loaded into and / or executed by a computer, or transmitted via a transmission medium (such as via electrical wiring or cable laying, via optical fiber, or via electromagnetic radiation), such that when the computer program code is loaded into and executed by the computer, the computer becomes an apparatus for implementing embodiments of the disclosed technical solutions. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.

[0054] In some configurations, a computer-readable instruction set stored on a computer-readable storage medium can be implemented by a general-purpose processor, which can transform the general-purpose processor or a device containing the general-purpose processor into a dedicated device configured to implement or execute the instructions. Embodiments can be implemented using hardware, which may include processors, such as general-purpose microprocessors and / or application-specific integrated circuits (ASICs) that implement all or a portion of the technology according to embodiments of the disclosed technical solutions in hardware and / or firmware. The processor may be coupled to memory, such as RAM, ROM, flash memory, hard disk, or any other device capable of storing electronic information. The memory may store instructions suitable for execution by the processor to perform the technology according to embodiments of the disclosed technical solutions.

[0055] This technical solution improves the ability of computing systems connected to electric vehicles to predict when pre-conditioning of the associated battery pack should be performed during anticipated DC fast charging. The embodiments disclosed herein allow the computing system to predict a user's destination and whether the user intends to connect the electric vehicle to a DC fast charging station. This technical solution can facilitate these predictions without explicitly requesting this information from the user, thereby improving the convenience of the computing system. The embodiments disclosed herein can utilize historical data about the user's past experiences as well as new data generated during the trip. This data can be fed to one or more machine learning models, which can be periodically retrained to improve the accuracy of the predictions. The accuracy of the predictions can be further improved as more data can be collected continuously during the trip. By generating accurate predictions of when pre-conditioning of the electric vehicle battery pack should begin, the time required to recharge the battery pack can be reduced, thereby improving the user experience.

[0056] The foregoing disclosure has been set forth for illustrative purposes only and is not intended to be limiting. Since modifications to the disclosed embodiments incorporating the spirit and essence of the invention can be conceived by those skilled in the art, the invention should be construed as encompassing everything within the scope of the appended claims and their equivalents.

Claims

1. A system for pre-adjusting a vehicle's battery pack to support fast charging, the system comprising: processor; A memory that communicates with the processor stores a plurality of instructions executable by the processor to cause the system to perform the following steps: The detection indicates that the vehicle is about to move or that the vehicle's battery pack has been reduced to a predetermined capacity. Collect multiple samples of the vehicle's current location data; The multiple samples are transmitted to the trip management model (110). The trip management model (110) is used to predict multiple destinations of the vehicle based on the multiple samples; Using a charging habit model (115), the user's DC fast charging habits for the vehicle are determined based on the predicted multiple destinations and at least one of the following: Total distance driven since the last known charging incident; Are there other users in the vehicle? and The user's previous DC fast charging behavior; The availability data of charging stations is received by analyzing the cluster (105); Determine the confidence scores for the predicted destination and the identified habits; and The pre-conditioning of the battery pack is arranged based on the confidence score reaching a threshold and below: Availability of DC fast charging stations at one of the predicted destinations; and The user's habit of DC fast charging the vehicle at one of the predicted multiple destinations.

2. The system of claim 1, further comprising instructions executable by the processor to cause the system to perform the following steps: Determine if a charging station exists at the predicted destination.

3. The system according to claim 1, wherein, The pre-conditioning of the vehicle's battery pack is designed to raise the temperature of the battery pack.

4. The system of claim 1, further comprising instructions executable by the processor to cause the system to perform the following steps: Determine the estimated arrival time of the vehicle at the predicted destination; and When the vehicle is to begin pre-adjusting the battery pack, a pre-adjustment time prior to the estimated arrival time is determined.

5. The system of claim 1, further comprising instructions executable by the processor to cause the system to perform the following steps: Determine the time window required to raise the temperature of the battery pack to the target pre-adjusted temperature.

6. The system of claim 5, further comprising instructions executable by the processor to cause the system to perform the following steps: The time window is compared with the estimated arrival time of the vehicle at the predicted destination; and Based on the comparison, the battery pack is pre-adjusted.

7. The system according to claim 2, wherein, The system determines whether a charging station exists at the predicted destination based on aggregated data published by multiple other vehicles attempting to charge at the predicted destination.

8. The system according to claim 1, wherein, The instructions that the processor can execute to enable the system to predict the vehicle's destination are based on the determination that no destination has been set in the vehicle's navigation function.

9. The system of claim 1, further comprising instructions executable by the processor to cause the system to perform the following steps: The battery pack arrangement or currently performed pre-adjustment is cancelled based on the confidence score not reaching the threshold.

10. The system according to claim 1, wherein, The habit is further based on at least one of the following: Predicted location; Total distance driven in a day; The price for recharging at the predicted location's charging station; Scheduled events and appointments stored in the user's personal computing device; The predicted driver of the vehicle; The remaining state of charge of the battery pack; or Whether amenities are available near charging stations at the predicted locations.

11. A method for pre-adjusting a vehicle's battery pack to support fast charging, the method comprising: The detection indicates that the vehicle is about to move or that the vehicle's battery pack has been reduced to a predetermined capacity. Collect multiple samples of the vehicle's current location data; The multiple samples are transmitted to the trip management model (110). The trip management model (110) is used to predict multiple destinations of the vehicle based on the multiple samples; Using a charging habit model (115), the user's DC fast charging habits for the vehicle are determined based on the predicted multiple destinations and at least one of the following: Total distance driven since the last known charging incident; Are there other users in the vehicle? and The user's previous DC fast charging behavior; The availability data of charging stations is received by analyzing the cluster (105); Determine the confidence scores for the predicted destination and the identified habits; and The pre-conditioning of the battery pack is arranged based on the confidence score reaching a threshold and below: The availability of DC fast charging stations for one of the predicted destinations; and The user's habit of DC fast charging the vehicle at one of the predicted multiple destinations.

12. The method according to claim 11, wherein the method further comprises: Determine if a charging station exists at the predicted destination.

13. The method according to claim 11, wherein, The pre-conditioning of the vehicle's battery pack is designed to raise the temperature of the battery pack.

14. The method of claim 11, further comprising: Determine the estimated arrival time of the vehicle at the predicted destination; and When the vehicle is to begin pre-adjusting the battery pack, a pre-adjustment time prior to the estimated arrival time is determined.

15. The method according to claim 11, wherein the method further comprises: Determine the time window required to raise the temperature of the battery pack to the target pre-adjusted temperature.

16. The method of claim 15, further comprising: The time window is compared with the estimated arrival time of the vehicle at the predicted destination; and Based on the comparison, the battery pack is pre-adjusted.

17. The method according to claim 12, wherein, The determination of whether a charging station exists at the predicted destination is based on aggregated data published by multiple other vehicles attempting to charge at the predicted destination.

18. The method according to claim 11, wherein, The vehicle's destination prediction is based on the determination that no destination has been set in the vehicle's navigation function.

19. The method of claim 11, further comprising: The battery pack arrangement or currently performed pre-adjustment is cancelled based on the confidence score not reaching the threshold.

20. The method according to claim 11, wherein, The habit is further based on at least one of the following: Predicted location; Total distance driven in a day; The price for recharging at the predicted location's charging station; Scheduled events and appointments stored in the user's personal computing device; The predicted driver of the vehicle; The remaining state of charge of the battery pack; or Whether amenities are available near charging stations at the predicted locations.

Images