Public charging wait time estimation and prediction

Abstract

The present disclosure provides for "Public Charging Wait Time Estimation and Prediction." A prediction of wait time for an electric vehicle (EV) at a charging station is performed. A server receives a charger request from an EV, the charger request including at least a destination and a state of charge (SOC) value. An arrival rate of EVs to the charging station is determined based on at least one of: a vehicle density in a geofenced area around the charging station or SOC values of nearby EVs. A service rate of the charging station is determined based on historical charging event rates. A trained prediction model is applied to the request based on the arrival rate and the service rate to estimate a predicted wait time for the EV at the charging station. The predicted wait time is transmitted to a user interface associated with the EV.

Description

Technical Field

[0001] The various aspects of this disclosure generally relate to the estimation and prediction of common charging wait times based on a hybrid approach using physics-based models and data-driven techniques. Background Technology

[0002] Electric vehicle power supply equipment (EVSE) refers to the infrastructure and devices used to deliver electrical energy from the grid to electric vehicles (EVs) to recharge their batteries. EVSE includes components such as connectors, cables, communication protocols, and mechanisms that provide the power flow and ensure safe and efficient charging. Waiting times when using EVSE can vary significantly depending on factors such as charger type, charging speed, and station availability. Summary of the Invention

[0003] In one or more illustrative examples, a method for predicting the waiting time of an electric vehicle (EV) at a charging station includes: receiving a charger request from an EV at a server, the charger request including at least a destination and a state of charge (SOC) value; determining an arrival rate of the EV to the charging station based on at least one of: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining a service rate of the charging station based on historical charging event data; applying a trained prediction model to the request based on the arrival rate and the service rate to estimate a predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to a user interface associated with the EV.

[0004] In one or more illustrative examples, the trained prediction model is based on historical wait times determined using: Level 1 short trip identifiers using trip distance and odometer change thresholds; and Level 2 short trip identifiers using trip gear patterns to divide into sub-trips and evaluate the final sub-trips based on duration and odometer change.

[0005] In one or more illustrative examples, the method further includes: generating training data for the prediction model by: receiving charging event data at the server including plug-in timestamps associated with charging sessions of multiple EVs; retrieving multiple trips associated with the multiple EVs from a vehicle history database; for each EV: identifying a final trip that ended before the plug-in timestamp from the multiple trips; determining whether the final trip is a Level 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and the odometer reading of the final trip changes. The method further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip and a previous sub-trip or trip being usable as the preceding trip; and determining the historical waiting time as the difference between the end time of the final trip and the end time of the preceding trip in response to the final trip being a Level 1 short trip or a Level 2 short trip; wherein the historical waiting time is aggregated and used to train the prediction model.

[0006] In one or more illustrative examples, the method further includes: in response to the trip distance being less than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the preceding trip being less than an adjustment time threshold, excluding the final trip from the category of Level 1 short trips as an adjustment case.

[0007] In one or more illustrative examples, determining the Level 2 short trip includes: dividing the final trip into multiple sub-trips based on the gear mode; identifying the last sub-trip prior to the plug-in timestamp; and determining whether the last sub-trip is a Level 2 short trip based on the duration of the sub-trip being less than a Level 2 duration threshold and the odometer change of the sub-trip being less than or equal to a predefined Level 2 threshold.

[0008] In one or more illustrative examples, the segmentation is performed when the gear pattern matches a pattern of alternating parking and drive positions.

[0009] In one or more illustrative examples, the method further includes verifying whether the charger is available at the time of the plug-in timestamp by analyzing the charger occupancy status.

[0010] In one or more illustrative examples, the waiting time is recorded as zero in response to determining that at least one charger is available at the plug-in timestamp.

[0011] In one or more illustrative examples, the trained prediction model includes a queuing model, wherein the queuing model is one of an M / M / m model, an M / D / m model, or an M / G / m model.

[0012] In one or more illustrative examples, determining the arrival rate includes: assigning a charging probability to each EV within the geofenced area based on a SOC threshold; and weighting the arrival rate using the popularity score of the charging station.

[0013] In one or more illustrative examples, a server for predicting the waiting time of an electric vehicle (EV) at a charging station includes: a memory storing instructions for charger service; and one or more computing devices configured to execute the instructions to perform operations including: receiving a charger request from an EV, the charger request including at least a destination and a state of charge (SOC) value; determining an arrival rate of the EV to the charging station based on at least one of: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining a service rate of the charging station based on historical charging event data; applying a trained prediction model to the request based on the arrival rate and the service rate to estimate a predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to a user interface associated with the EV.

[0014] In one or more illustrative examples, the trained prediction model is based on historical wait times determined using: Level 1 short trip identifiers using trip distance and odometer change thresholds; and Level 2 short trip identifiers using trip gear patterns to divide into sub-trips and evaluate the final sub-trips based on duration and odometer change.

[0015] In one or more illustrative examples, the one or more computing devices are further configured to execute the instructions to perform operations to generate training data for the prediction model, the operations including: receiving charging event data at the server including plug-in timestamps associated with charging sessions of a plurality of EVs; retrieving a plurality of trips associated with the plurality of EVs from a vehicle history database; for each EV: identifying a final trip that ended before the plug-in timestamp from the plurality of trips; determining whether the final trip is a Level 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and The odometer change for the final trip is less than or equal to a predefined threshold; in response to the final trip not meeting the criteria for a Level 1 short trip, the method further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and in response to the final trip being a Level 1 short trip or a Level 2 short trip, the historical waiting time is determined as the difference between the end time of the final trip and the end time of the preceding trip; wherein the historical waiting time is aggregated and used to train the prediction model.

[0016] In one or more illustrative examples, the one or more computing devices are further configured to execute the instructions to perform an operation including: in response to the trip distance being lower than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the preceding trip being less than an adjustment time threshold, excluding the final trip from the category of Level 1 short trips as an adjustment condition.

[0017] In one or more illustrative examples, determining the Level 2 short trip includes: dividing the final trip into multiple sub-trips based on the gear mode; identifying the last sub-trip prior to the plug-in timestamp; and determining whether the last sub-trip is a Level 2 short trip based on the duration of the sub-trip being less than a Level 2 duration threshold and the odometer change of the sub-trip being less than or equal to a predefined Level 2 threshold.

[0018] In one or more illustrative examples, the segmentation is performed when the gear pattern matches a pattern of alternating parking and drive positions.

[0019] In one or more illustrative examples, the one or more computing devices are further configured to execute the instructions to perform operations including verifying whether the charger is available at the time of the plug-in timestamp by analyzing the charger occupancy status.

[0020] In one or more illustrative examples, the waiting time is recorded as zero in response to determining that at least one charger is available at the plug-in timestamp.

[0021] In one or more illustrative examples, the trained prediction model includes a queuing model, wherein the queuing model is one of an M / M / m model, an M / D / m model, or an M / G / m model.

[0022] In one or more illustrative examples, determining the arrival rate includes: assigning a charging probability to each EV within the geofenced area based on a SOC threshold; and weighting the arrival rate using the popularity score of the charging station.

[0023] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions for a charger service to predict the waiting time of an electric vehicle (EV) at a charging station. When executed by one or more computing devices of the charger server, the instructions cause the charger server to perform operations including: receiving charging event data at the server, including plug-in timestamps associated with charging sessions of a plurality of EVs; retrieving a plurality of trips associated with the plurality of EVs from a vehicle history database; for each EV, determining historical waiting time includes: identifying a final trip from the plurality of trips that ended before the plug-in timestamps; determining whether the final trip is a Class 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and the odometer change of the final trip is less than or equal to a predefined threshold; in response to the final trip not meeting the Class 1 short trip criteria, further including analyzing the gear mode of the final trip to determine the... The method includes determining whether the gear mode includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and in response to the final trip being a Level 1 or Level 2 short trip, determining the historical waiting time as the difference between the end time of the final trip and the end time of the preceding trip; receiving a charger request from an EV, the charger request including at least a destination and a state of charge (SOC) value; determining the arrival rate of the EV to the charging station based on at least one of the following: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining the service rate of the charging station based on historical charging event data; applying a model trained using the historical waiting time to the request based on the arrival rate and the service rate to estimate the predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to a user interface associated with the EV. Attached Figure Description

[0024] Figure 1 An exemplary system for performing public charging wait time estimation and prediction for charging vehicles is shown; Figure 2 A single-step charging curve without waiting is shown; Figure 3 The diagram shows a two-step charging curve that does indeed involve waiting; Figure 4 An exemplary delivery route of the vehicle is shown; Figure 5 A graph showing the distribution of travel distances for Level 1 short-distance trips is provided. Figure 6 An exemplary dataset for the first gear mode used in Level 2 analysis is shown; Figure 7 An exemplary dataset for the second gear mode used in level 2 analysis is shown; Figure 8 An example of splitting a trip into two parts is shown, where the second part is not a shorter trip; Figure 9 An example of splitting a trip into two parts is shown, where the second part is a shorter trip; Figure 10 A trip with multiple trip patterns is shown; Figure 11 An exemplary process for estimating and predicting public charging wait times is shown; Figure 12 An exemplary process for responding to a charger request is shown; and Figure 13 An exemplary computing device is shown for realizing various aspects of public charging wait time estimation and prediction. Detailed Implementation

[0025] Detailed embodiments of the invention are disclosed herein as needed; however, it should be understood that the disclosed embodiments are merely examples of the invention that can be embodied in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but only as representative bases for teaching those skilled in the art to employ the invention in various ways.

[0026] As EV adoption continues to rise, congestion at popular EV charging stations is increasingly frustrating drivers and presenting new challenges for charging point operators (CPOs). To alleviate charging anxiety for EV drivers, it is desirable to provide estimates of charger wait times. Providing near real-time predictions of wait times by leveraging streaming data could also offer drivers greater flexibility, allowing them to adjust their trips or planned activities while waiting.

[0027] Various aspects of this disclosure relate to a method for providing a digital service for public charging wait times. The method can provide wait time estimation using vehicle data, wait time adjustment using regional EV density data, and / or real-time wait time prediction upon arrival.

[0028] Waiting time estimation can include estimating EV public charging wait times by passively analyzing vehicle data rather than relying on driver surveys. Waiting time estimation can be indicated by identifying “short trips,” which refer to short-distance vehicle movement approaching the EVSE after waiting for a disconnected charger. By integrating vehicle geospatial information (e.g., Global Navigation Satellite System (GNSS) location) and trip data (including trip start / end times, gear position, and ignition status) with charging event data (such as charging start time), the system identifies these “short trips” representing the driver’s waiting time between arrival and charging. Additionally, waiting time estimation simultaneously cross-references EVSE flow status to eliminate outliers and improve accuracy.

[0029] Furthermore, the method enhances the customer experience by dynamically adjusting wait time estimates based on regional EV density data. When customers confirm their charging destination, the method integrates statistics with a backend queuing model. For a specific charging station, total dwell time is conceptualized as the sum of waiting time in the queue and charging service time.

[0030] This can include employing primary modeling techniques or data-driven approaches to estimate charging service time, depending on available data such as the type of vehicle currently being served, the target state of charge (SOC), and the EVSE charging performance status. Markov chains or deterministic systems can be used to model the service rate (μ) that reflects charging time.

[0031] The method can also open up geospatial areas and collect extensive xEV data. By assessing the density of EVs with low SOC driving nearby and specific service requests obtained through a third-party route selection system (e.g., the number of drivers who have identified the current charging station as their destination), the method can translate this information into a projected rate of arrival (λ).

[0032] Total dwell time can be modeled, and expected waiting times can be frequently updated for display on the customer's phone or vehicle human-machine interface (HMI). Upon the customer's arrival at the charging station, the method employs a combination of physics-based modeling techniques and data-driven approaches to deliver real-time waiting time updates.

[0033] If comprehensive information about the target State of Charge (SOC) for both currently servicing vehicles and waiting vehicles is available, deterministic wait time estimation can be performed. This model assumes that customers comply with charging regulations by unplugging their vehicles once the target SOC is reached. To improve accuracy, historical trends can be analyzed and incorporated into a time factor to provide indications of scenarios with long plug-in times and short charging durations, which could indicate longer wait times at charging stations.

[0034] In situations where target SOC information is unavailable but the number of vehicles in the queue is visible to customers, a data-driven approach can be relied upon. Initial wait time estimates can be enhanced by segmenting them based on the number of vehicles in the queue. This approach dynamically displays the wait time estimate for each position in the queue, allowing customers to better plan their activities while waiting. Furthermore, vehicle HMIs or telephone applications (such as FordPass) can be used to collect customer input regarding wait times for more accurate updates to current congestion conditions.

[0035] The method can also provide personalized recommendations for nearby amenities and activities based on predicted wait times, transforming charging waits into a more efficient and enjoyable experience. By leveraging real-time data and historical insights, the disclosed method optimizes the charging process and improves customer satisfaction.

[0036] Figure 1 An exemplary system 100 is shown for performing public charging wait time estimation and prediction for a charging vehicle 102. The vehicle 102, EVSE 104, mobile device 106, and charger monitoring server 112 can be configured to communicate via a communication network 108. Charger monitoring server 112 can be configured to receive vehicle history 114 from vehicle 102 and charger history 116 from EVSE 104. Using vehicle history 114 and charger history 116, a charger service 118 hosted by charger monitoring server 112 can be configured to generate charger wait times 120, which can be used to process charger requests 124 to provide charger recommendations 126 to users of vehicle 102 and / or mobile device 106. It should be noted that system 100 is merely an example, and examples with more, fewer, or differently positioned components may be used.

[0037] Vehicle 102 may include various types of automobiles, crossover multi-purpose vehicles (CUVs), sport multi-purpose vehicles (SUVs), trucks, recreational vehicles (RVs), boats, aircraft, or other mobile machines used for transporting people or goods. In many cases, vehicle 102 may be a battery electric vehicle (BEV) powered by a traction battery and one or more electric motors. As another possibility, vehicle 102 may be a hybrid electric vehicle powered by both an internal combustion engine, a traction battery, and one or more electric motors. Hybrid electric vehicles 102 may take various forms, such as series hybrid electric vehicles, parallel hybrid electric vehicles, or parallel / series hybrid electric vehicles. As the type and configuration of vehicle 102 can vary, the capabilities of vehicle 102 may vary accordingly. As some possibilities, vehicle 102 may have different capabilities in terms of passenger capacity, towing capacity and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with unique identifiers such as vehicle identification numbers (VINs), globally unique identifiers (GUIDs), customer or fleet accounts, etc.

[0038] The EVSE 104 can be configured to manage energy transfer between a power source and the vehicle 102. An external power source can provide direct current (DC) or alternating current (AC) power to the EVSE 104. The EVSE 104 can then have a charging connector for insertion into a corresponding charging port in the vehicle 102. The charging port can be any type of port configured to transfer power from the EVSE 104 to the vehicle 102. Alternatively, the EVSE 104 can be configured to transfer power using other methods, such as wireless inductive coupling. Regardless of the connection method, the EVSE 104 can include circuitry and controls for managing energy transfer between the power source and the vehicle 102.

[0039] Mobile device 106 may be any of various types of portable computing devices, such as cellular phones, tablet computers, smartwatches, laptop computers, portable music players, or other devices with processing and communication capabilities. Mobile device 106 may include one or more processors configured to execute computer instructions, and storage media thereon capable of holding computer-executable instructions and / or data.

[0040] Mobile device 106 may also include various wireless transceivers, such as Bluetooth or Bluetooth Low Energy (BLE) transceivers, and transceivers for communication via communication network 108. As some non-limiting examples, communication network 108 may include one or more interconnected communication networks, such as the Internet, cable television distribution networks, satellite link networks, local area networks, and telephone networks. Vehicle 102 may also include a telematics control unit (TCU) 110. TCU 110 may include network hardware configured to facilitate communication between vehicle 102 and other devices of system 100. For example, TCU 110 may include a cellular modem or otherwise access a cellular modem configured to facilitate communication with communication network 108.

[0041] Charger location server 112 may be an example of a networked computing device, which vehicle 102, EVSE 104, and / or mobile device 106 can access via communication network 108. Charger monitoring server 112 may be configured to receive charger data 116 from EVSE 104 (e.g., as part of a billing process for EVSE 104 usage or as a separate process). In another example, vehicle 102 may monitor its EVSE 104 usage and may send its charger history 116 to charger monitoring server 112 via communication network 108.

[0042] Vehicle history 114 may include usage information about vehicle 102. This usage information may include, for example, the location of vehicle 102 over time, the time when vehicle 102 changes from park to drive, and the time when vehicle 102 changes from drive to park.

[0043] Charger history 116 may include information about vehicle 102's use of EVSE 104. As some non-limiting examples, this information may include: the time when EVSE 104 began charging vehicle 102, the time when EVSE 104 stopped charging vehicle 102, the average charge rate of vehicle 102, the time-varying charge rate of vehicle 102, the identifier of EVSE 104, the identifier of vehicle 102, whether any problems occurred during the charging of vehicle 102, the cost per kWh of charging, etc. Charger history 116 may also include information about vehicle 102 utilizing EVSE 104. For example, charger history 116 may also include the identifier of vehicle 102 (e.g., VIN, GUID, user account, etc.), the brand, model, and / or type of vehicle 102, the age of vehicle 102, the battery health status of vehicle 102, the mileage of vehicle 102, the initial charge level of vehicle 102, and the final charge level of vehicle 102.

[0044] Charger service 118 can be an example of an application executed by charger monitoring server 112. As explained in further detail herein, charger service 118 can be configured to receive vehicle history 114 and charger history 116, generate charger wait times 120, and use those generated charger wait times 120 to notify vehicle 102 of timing. In the example, wait times 120 can be used to respond to charger request 124 with a charger recommendation 126 tailored to the vehicle 102 to be charged (e.g., optimal timing).

[0045] This article discusses in detail other aspects of the charger waiting time 120. These aspects may include (i) detecting charging scenarios, (ii) identifying the type of waiting scenario, (iii) calculating Level 1 and Level 2 short-distance trips, and (iv) performing the waiting time 120 calculation. Each of these is discussed in turn.

[0046] When a customer goes to EVSE 104 to charge their vehicle 102, two main different scenarios may occur. As one possibility, at least one EVSE 104 may be available at the charging station. If so, the customer can charge immediately. As another possibility, all EVSE 104s may be in use, and the customer may need to wait for one EVSE to become available before charging.

[0047] These two scenarios can be categorized as single-step charging (no waiting) and two-step charging (waiting). In single-step charging, the customer drives directly to EVSE 104 and begins charging. In two-step charging, the customer drives to the charging station, parks or stops, and waits for EVSE 104 to become available. Then, the customer moves vehicle 102 again, this time to EVSE 104 to begin charging.

[0048] Figure 2 A single-step charging curve 200 without waiting is shown. The single-step charging curve 200 depicts the spatial-temporal coordinates of a customer's journey to charge their vehicle 102, with space vertically downwards on the left and time horizontally across on the right. The curve begins at an initial position (marked spatially as "Somewhere" and temporally as "Start of Journey 1"), then proceeds to a charging station (marked spatially as "EVSE Charging Point" and temporally as "End of Journey 1"), and begins charging the vehicle. After charging, the vehicle 102 resumes driving and leaves the charging station (marked temporally as "Start of Journey 2").

[0049] Figure 3A two-step charging curve 300 is shown, which does indeed involve waiting. The two-step charging curve 300 again depicts the spatial-temporal coordinates of a customer's journey to charge their vehicle 102, with space vertically downwards on the left and time horizontally across on the right. Similar to a single-step charging scenario, the customer starts from an initial position but ends their first journey in a parking area near the charging station instead of at EVSE 104 because EVSE 104 is not available upon arrival (marked spatially as "Parking Area" and temporally as "End of Journey 1"). The customer waits in the parking area. Once EVSE 104 becomes available, the customer moves vehicle 102 to EVSE 104 (marked temporally as "Start of Journey 2"), stops at EVSE 104 (marked temporally as "End of Journey 2"), and continues charging vehicle 102. After completing the charging process, the customer leaves the charging station (marked temporally as "Start of Journey 3"). In this scenario, the time between the end of Journey 1 and the end of Journey 2 is considered the waiting time. Compared to the first scenario, this is the extra time that customers must spend at EVSE 104.

[0050] To model the waiting time for instances of single-step charging scenarios, a unique journey is used to model the waiting time. However, for instances of two-step charging scenarios, the waiting time for these cases is calculated based on the timestamp of the journey preceding the corresponding charging step.

[0051] In the two-step charging scenario (waiting situation), the final journey before charging is from the parking area near the charging station to EVSE 104. This means that this journey is likely to be very short. Therefore, the goal is to identify the short journey before charging and then calculate the waiting time 120 accordingly.

[0052] Figure 4 An exemplary delivery journey 400 of vehicle 102 is shown. As illustrated, two journeys are captured, each corresponding to a single ignition cycle. For example, this pattern could occur when delivering a pizza, where vehicle 102 exits through a door to deliver the pizza, then re-enters, but remains on throughout the entire time.

[0053] There can be two levels for identifying short trips and therefore waiting situations. The basic principle behind this two-level short trip identification lies in the way trip summaries are defined and identified. Trip identification is based on power mode alarms. A trip begins when a "Power Mode Start Alarm" is received, and ends when a "Power Mode End Alarm" is received. The Power Mode Start Alarm is triggered when the customer starts vehicle 102 or opens (and in some cases, such as entering vehicle 102 via the driver's door). The Power Mode End Alarm is triggered when the engine of vehicle 102 is turned off and / or the driver's door is opened and closed.

[0054] In a two-step charging scenario where there are two trips before charging (one from the initial location to a parking area near the charging station, and the second from the parking space to the charger), if the customer opens / closes the driver's side door or starts / stops the engine, the charger service 118 can define a power mode start alarm and a power mode end alarm, and identify the two separate trips. Based on the identification of the two trips, the charger service 118 is able to check the last trip before charging to see if it is a short trip.

[0055] On the other hand, when arriving at a congested charging location, a customer might wait in vehicle 102 without turning the engine on / off or opening / closing the doors. In this case, the power mode start and end alarms may not be triggered. Instead, only one long trip from its initial location to EVSE 104 is identified, rather than two separate trips, even though the customer may be waiting in vehicle 102 near the charging station, which may not meet the short trip criteria defined above. For these cases, a Level 2 short trip identification is implemented to prevent false negatives.

[0056] As used in this paper, a Class 1 short-distance trip is defined as shown in equation (1):

[0057] in: It is a predefined travel distance; and This is a predefined change in the trip odometer.

[0058] It can be set up based on vehicle data and / or infrastructure. and Therefore, these values ​​can vary depending on the implementation. In a non-restrictive example, for illustration, It could be 64 meters, and It can be one odometer unit.

[0059] In response to identifying Level 1 short-distance trips, adjustments can be indicated by confirming the waiting time (120) and trip distance. For example, if... Travel distance < 1 meter and Waiting time < 1 minute This is likely an adjustment situation rather than a genuine waiting situation, where vehicle 102 is already at the charger but requires adjustment to properly plug in, which explains why the trip distance and waiting time 120 are so short. These adjustment situations can be removed from the Level 1 short trip calculation and excluded from the calculation of waiting time 120.

[0060] Figure 5 A graph 500 shows the distribution of travel distances for Level 1 short-distance trips. As can be seen, it has... Distance < 1 rice A large portion of the itinerary was marked as an adjustment.

[0061] For cases where the Level 1 condition for short trips is not met, the method proceeds to a Level 2 check. Where trip summaries are not separated due to the absence of a power mode start / end alarm, the method can use gear information from vehicle 102 (e.g., from vehicle history 114) to identify those trips.

[0062] This can happen when, for various reasons, a customer decides to remain in vehicle 102 with the engine running. Examples include hot summer days when a customer keeps vehicle 102 running to use the air conditioning, or cold days when they need heat. Ideally, when a customer has to wait, they would put their vehicle 102 in park mode rather than drive mode if they don't turn it off. Therefore, the charger service 118 can use the gear mode to identify these situations (where the power mode start / end alarm is not triggered), break long trips into smaller segments, and then determine if the last trip before charging is a short trip to identify the waiting time 120.

[0063] To understand how the travel can be broken down into smaller travel segments, different gear positions can be observed for each travel segment. The first position can typically be defined by an ordered sequence of gear positions: Park, Drive, Park, or (P, D, P). The second position can be defined by an ordered sequence of gear positions: Park, Drive, Park, Drive, Park, or (P, D, P).

[0064] Figure 6 An exemplary dataset for the first mode is shown. This first mode is the simplest gear shifting pattern during the trip. The customer starts vehicle 102, shifts to drive, and vehicle 102 enters power mode. Upon reaching the destination, the customer shifts to park and ends the trip.

[0065] Figure 7An exemplary dataset for the second mode is shown. This second mode can occur when a customer utilizes multiple driving and parking sequences. In this scenario, the customer starts the car, changes gear from "Park" to "Drive," drives for a period of time, then stops and puts the gear back in "Park," and after a period of time, they start driving again. This switching between "Park" and "Drive" can occur multiple times, so the mode can potentially be extended to many repetitive transitions, such as: (P, D, P, D, …, D, P).

[0066] A similar gearing pattern can be observed when a driver starts driving from an initial position (D), proceeds to a congested charging station, waits in a running vehicle 102 with the gear in park (P), and then drives toward an EVSE 104 once it becomes available. In this example, the gearing pattern would look like: (P,D, P, D, P). This pattern can be broken down into two smaller trips, such as (P, D, P) and (P, D, P), where the latter trip is checked against the conditions of the shorter trip.

[0067] Therefore, the operations for Level 2 identification include (i) extracting the gear mode of the trip before charging; (ii) checking whether there is more than one driving session in the gear mode; (iii) dividing the trip into smaller trips such that each trip has only one driving session; and (iv) checking the last trip to see if it is a short trip and calculating the waiting time 120 accordingly.

[0068] Ideally, the Level 2 short-distance travel standard should match the Level 1 standard. However, due to differences in data availability (such as the temporal resolution of GNSS values ​​during the trip), the standards for Level 2 identification may differ. It's possible that only the start and end GNSS values ​​of the trip provided in the trip summary are received, rather than GNSS values ​​for points in between. Therefore, after breaking the trip into smaller segments, intermediate GNSS values ​​may not be usable for calculating the straight-line distance between the start and end points of these smaller trips for use as a short-distance travel standard. Therefore, trip duration can be used instead. If the driver is traveling from a parking space very close to a charging station to the EVSE 104, the travel time should not be long. Therefore, in this specific case, using trip duration instead of distance is reasonable.

[0069] If the final journey before charging after a malfunction occurs while using the gear mode satisfies the condition of equation (2), then it is considered a short journey:

[0070] in: It is a predefined travel distance; and This is a predefined change in the trip odometer.

[0071] It can be set up based on vehicle data and / or infrastructure. and Therefore, these values ​​can vary depending on the implementation. In a non-restrictive example, for illustration, It can be 5 minutes, and It can be a single odometer unit (e.g., or the same as that used for Level 1 trip determination). (Another consistent value). It should be noted that these values ​​may differ from Level 1, for example, due to differences in data availability.

[0072] Figure 8 Example 800 shows a trip being broken down into two, where the second trip is not a short trip. As can be seen, the termination of the trip does not meet the criteria for a Level 2 short trip.

[0073] Figure 9 Example 900 shows a trip divided into two parts, where the second part is a short trip. As can be seen, ending the interrupted trip here does indeed meet the criteria for a Level 2 short trip.

[0074] The waiting time of 120 for turning is calculated according to equation (3) after marking the short trip (using level 1 or level 2 marking technology):

[0075] In this formula, for level 1 and level 2 cases, End time of the trip It will be the same. The trip summary to the plug-in attempt matches the end of the last trip before charging. However, for the two levels of identification, End time of the previous trip It may be slightly different.

[0076] For Level 1 short-distance trips End time of the previous trip This refers to the end time of the second-to-last trip (from the trip summary) before attempting to plug in. However, for Level 2 short trips, the second-to-last trip is defined before charging after the trip from the trip summary is divided into smaller trips using gear information.

[0077] When breaking down a trip, each smaller trip may contain only one driving sequence. For example, Figure 10The diagram illustrates a journey with the pattern (P, D, P, D, P), meaning that following the logic used to define the journey, it can be divided into two smaller journeys, such as (P, D, P) and (P, D, P). The final (P, D, P) sequence will be the last journey before charging, which we will call journey 2, and the first (P, D, P) is the penultimate journey, which we can call journey 1. Therefore, the end of journey 1 will be... End time of the previous trip The first "Park" signal after the last "Drive" signal in Trial 1 can be used as the end of Trial 1. The start of Trial 2 is the first occurrence of "Drive" in the last trip (here, Trial 2), and the end of Trial 2 is the same as the end of the trip from the trip summary. Finally, the "end of Trial 1" (i.e., forward End time of the trip ) and "the end of trip 2" (i.e., End time of the trip ) can be used for waiting time calculation, as shown in equation (3) above.

[0078] This method can be further generalized to consider scenarios where customers make multiple short trips before initiating charging. For example, if a driver arrives at a congested charging station and makes several minor relocations (e.g., from one parking space to another or within the area around the station) before finally starting charging, these trips can be collectively considered as a waiting time of 120. In such scenarios, the total waiting time of 120 can be calculated as the difference between the end of the last trip before charging and the end of the last major (long-distance) trip before these short trips. By aggregating these short trips into a single waiting period, we can more accurately reflect the customer experience at congested charging stations, thus ensuring the algorithm remains robust across different charging scenarios.

[0079] Turning to wait time adjustments using regional EV density data, many methods model public charging wait times as queuing models. In mathematical queuing theory, Little's Law, John Little's theorem, states the long-run average number of customers in a stationary system. Equal to the long-term average effective rate of arrival Multiply by the average time a customer spends in the system Expressed algebraically, the law is:

[0080] To make this long-term static system more realistic in the real world, queuing models can be classified as M / M / m, M / G / m, or M / D / m models. In this context, the first "M" stands for Markov chain, indicating that it can be modeled as a Poisson process in terms of arrival rate. The second letter "M," "G," or "D" represents the Markov chain service distribution, the general service distribution, or the deterministic service distribution, respectively. The last "m" represents the number of servers, which in this case is EVSE 104.

[0081] Using M / M / m as an example, this assumes the exponential arrival interval and service time, as well as multiple servers. We can formulate the estimate of the wait time as follows:

[0082] in: This refers to the quantity of EVSE 104; It is the arrival rate of 102 vehicles per minute, and It is a service rate of 102 vehicles per minute.

[0083] Therefore, if the average arrival rate and average service speed If available, the wait time of 120 can be estimated. Reverse engineering methods can be used because a data-driven wait time estimate of 120 is more accurate than a theoretical equation. Assuming the customer has already started their journey, the expected arrival rate can be determined based on available information. For service time, EVSE 104 stream data can be used as a source to extract charging events, the duration of which is used to calculate service time.

[0084] Next, a geospatial fence with thresholds is established around the charging station. Based on the number of EVs with a SOC below 20%, a charging probability can be assigned to each EV. For example, if the SOC is below 10%, it can be assumed that a customer is heading to that location, so the probability is 100%. If the SOC is below 30%, a 50% probability can be assigned. This allows the charging service 118 to calculate the probability of charging in the next... Within minutes The expected number of EVs, of which It is the customer's travel time.

[0085] The expected number of vehicles 102 arriving at the selected charging station can be formulated as follows:

[0086] in: This indicates the expected number of EVs that have arrived at the selected charging station by the time the current driver arrives; This is the number of confirmed EVs currently waiting, either from a trip planner app or as known to the charging station. Indicates the number of EVs within the selected geographic spatial region; It is the state of charge of the m-th EV battery; and It is the current popularity score of the charging station, because a geographic area can contain multiple charging stations.

[0087] This can be converted into arrival rates and used to fine-tune the offline estimated wait time 120. A wait time score can be assigned for cases where the adjusted wait time 120 is significantly higher than historical data, thus alerting EV drivers to reschedule their trips.

[0088] Therefore, the EV public charging wait time 120 can be estimated by passively analyzing vehicle 102 data rather than relying on driver surveys. Furthermore, this method fine-tunes the arrival rate of vehicle 102 using EV density. Compared to statistical methods, this can be converted into a score to warn drivers when extremely high wait times 120 are expected. Additionally, a three-phase wait time estimation and prediction method is provided by utilizing both physics-based and data-driven service time calculations.

[0089] Figure 11 An exemplary process 1100 for estimating and predicting public charging wait times is illustrated. In various examples, process 1100 may be performed by system 100 and specifically by charger monitoring server 112 performing charger service 118. Charger monitoring server 112 may have received vehicle history 114 from vehicle 102 and charger history 116 from EVSE 104 to perform process 1100. Process 1100 enables system 100 to determine, for a given charging event, whether a wait has occurred before plugging in, and if so, to accurately calculate the corresponding wait time 120 based on structured vehicle 102 and charger telemetry.

[0090] At operation 1102, charger service 118 identifies the first plug-in attempt based on charger history 116. This identification may include querying charging event data to extract the initial plug-in timestamp associated with each charging session for each vehicle 102. The plug-in attempt is associated with metadata including the timestamp, vehicle identifier (e.g., VIN), EVSE 104 identifier, plug-in SOC, and charging session details such as rate and duration. The extracted records form a "plug-in table" for subsequent analysis.

[0091] At operation 1104, charger service 118 retrieves and structures trip data from vehicle history 114. In the example, trips can be sorted in ascending order by start timestamp and partitioned by VIN. Lag and lead window functions can be applied to obtain the end time of the previous trip and the start time of the next trip for each vehicle 102, respectively. The resulting dataset (referred to as the "trip schedule") includes timestamps, GNSS coordinates, odometer readings, and other trip-level telemetry.

[0092] At operation 1106, charger service 118 combines the plug-in meter and trip meter to associate each plug-in attempt with its previous trip. This combination can be performed by matching the VIN and ensuring that the plug-in time is greater than or equal to the end time of the previous trip and less than or equal to the start time of the next trip. The resulting combination table associates each plug-in attempt with the relevant trip context for subsequent short trip and wait time analysis.

[0093] At operation 1108, charger service 118 determines whether the last trip prior to the plugging event constitutes a short trip under the Class 1 standard. Specifically, the trip is considered a Class 1 short trip if (i) the calculated GNSS distance between the trip's origin and destination is less than 64 meters, and (ii) the change in odometer reading during the trip is less than or equal to one unit. The distance between GNSS coordinates is calculated using geospatial functions (e.g., via BIG query) based on the latitude and longitude of the trip's origin and destination.

[0094] If these Level 1 criteria are met, at operation 1112, charger service 118 continues to assess whether the identified trip represents an adjustment situation, i.e., a scenario where vehicle 102 is already positioned at EVSE 104 but is slightly moved to facilitate plugging in. The trip is classified as an adjustment situation if (i) the GNSS distance is less than 1 meter and (ii) the time between the end of the current trip and the end of the previous trip is less than 1 minute. Adjustment situations are excluded from the waiting time estimate.

[0095] At operations 1110 and 1112, charger service 118 evaluates the results of the Level 1 short-trip identification. If a valid Level 1 short-trip is detected (not an adjustment case), control proceeds to operation 1114.

[0096] At operation 1114, charger service 118 calculates the estimated waiting time 120 as the difference between the end time of the final trip before charging and the end time of the previous trip. For the Level 1 case, both timestamps are obtained from the trip summary table and represent well-defined trip boundaries.

[0097] At operation 1116, charger service 118 verifies whether the charger is available at the time of the plug-in event. This is determined by checking the EVSE 104 stream status within charger history 116 to identify the occupancy status of chargers at the station at the plug-in timestamp. If all chargers are occupied, it is inferred that the customer has been waiting before charging.

[0098] At operation 1118, in response to determining that no EVSE 104 is available, the waiting time 120 calculated at operation 1114 is finally determined and stored as waiting time 120. This value can be used to update the predictive queuing model, notify the recommendation system, or be presented to the user via HMI or mobile application interface.

[0099] If, at operation 1116, the charger service 118 determines that the charger is available when plugged in (i.e., the customer does not need to wait), control proceeds to operation 1120. Furthermore, if it is found at operation 1112 that the Level 1 travel is an adjustment travel, control also proceeds to operation 1120. At operation 1120, the charger service 118 indicates that the waiting time 120 is zero. This indication can be stored in the same data structure used for waiting time statistics and can be passed to downstream services, such as a recommendation engine that considers charging efficiency. Then, process 1100 ends.

[0100] If at least one EVSE 104 is determined to be available during the plug-in time at operation 1116, then charger service 118 proceeds to operation 1120, where the waiting time 120 is recorded as zero.

[0101] If no Level 1 short trip is detected at operation 1110, control proceeds to operation 1122, where charger service 118 performs Level 2 short trip identification based on gear position data. In this path, the associated table is further combined with gear position telemetry (e.g., TCU4G data), which includes a sequence of gear position states (e.g., Park, Drive, Park) recorded during the trip.

[0102] At operation 1122, charger service 118 analyzes the gear pattern of the final long-distance trip before charging to detect a Drive-Park-Drive (PDP) pattern. The presence of this pattern indicates that the customer may have been waiting near the charging location with the engine running and then moved vehicle 102 when the charger became available. The trip is divided into one or more sub-trips, each defined by a single (P, D, P) sequence.

[0103] At operation 1124, the final sub-trip prior to the plugging event is evaluated by charger service 118 under the Level 2 short-range travel criterion. A sub-trip is considered a Level 2 short-range travel if (i) the duration of the sub-trip is less than 5 minutes (300 seconds) and (ii) the odometer change is less than or equal to one unit. Since there is no intermediate GNSS resolution in the segmented sub-trips, these relaxed criteria are used instead of GNSS distance.

[0104] At operation 1126, if a valid Level 2 short trip is detected, control proceeds to operation 1114, and the waiting time 120 is calculated using the timestamps derived from the segmented trip structure. Specifically, the waiting time 120 is calculated as the difference between the end time of the final (P, D, P) sub-trip and the end time of the previous (P, D, P) sub-trip. If no valid Level 2 short trip is found at operation 1126, the system proceeds to operation 1120, where the waiting time 120 is recorded as zero, and process 1100 terminates.

[0105] Figure 12 An exemplary process 1200 for responding to charger request 124 is illustrated. In various examples, process 1200 may be executed by system 100 and specifically by charger monitoring server 112 that performs charger service 118. Process 1200 enables system 100 to utilize the waiting time 120 determined for each vehicle 102 based on Level 1 and Level 2 short-distance trip identification using process 1100 as ground-based real-time data for training a prediction model. The prediction model can be used to generate real-time waiting time predictions in response to an incoming charger request 124.

[0106] At operation 1202, charger service 118 receives charger request 124 from vehicle 102. The request may originate from a controller on vehicle 102, such as an energy management or navigation controller, or from a user mobile device 106 connected to vehicle 102. Charger request 124 includes at least the destination corresponding to one or more EVSEs 104 and the SOC value of the battery of vehicle 102. In some examples, charger request 124 may also include estimated arrival time of the destination, route data, or other contextual metadata derived from a trip planning service.

[0107] At operation 1204, charger service 118 determines the EVSE 104 arrival rate of vehicle 102 to the charging station identified in charger request 124. To calculate this arrival rate, charger service 118 may first establish a geospatial fence around the destination charging station, such as a circular region of interest centered on the station with a predefined radius. Charger service 118 then queries recent and current vehicle 102 telemetry data, such as GNSS location and SOC value, from vehicles 102 operating within the geofenced area. Charger service 118 assigns a charging probability to each nearby vehicle 102 based on its SOC, where a lower SOC value corresponds to a higher probability of upcoming charging activity. For example, a vehicle 102 with an SOC value below 10% may be assigned a 100% charging probability, while a vehicle 102 with an SOC value below 30% may be assigned a 50% probability. In some examples, the arrival rate may also be weighted by a popularity score associated with the destination station, such as a score reflecting its historical usage frequency relative to nearby stations. When a destination is confirmed to be available from a third-party trip planner (e.g., a navigation application), the charger service 118 can also incorporate such data, thereby improving the accuracy of the predicted arrival rate λ.

[0108] At operation 1206, charger service 118 determines the service rate at the destination station. The service rate can be calculated based on historical charging session data obtained from charger history 116. Charger service 118 identifies past charging events at the relevant EVSE 104, extracts the start and end times of those sessions, and calculates the corresponding charging duration. Where available, these durations can be normalized based on vehicle 102 characteristics (e.g., battery size or brand / model), charger type (e.g., Level 2 or DC Fast), and environmental conditions (e.g., temperature). Charger service 118 can aggregate these durations to derive an average or expected service time, and then take the reciprocal of that time to calculate the average service rate μ of vehicle 102 per unit time. In some examples, variance metrics can also be stored to support more advanced queuing models, such as M / G / m. If streaming performance data is available to EVSE 104, such as real-time charging throughput or reported errors, the service rate can be adjusted to reflect current operating conditions.

[0109] At operation 1208, charger service 118 applies a trained prediction model to estimate the predicted waiting time 120 for requesting vehicle 102. The prediction model may include queuing theory components, such as an M / M / m model, an M / D / m model, or an M / G / m model, where the number of servers (m) corresponds to the EVSE 104 at the station. The arrival rate λ and service rate μ determined in operations 1204 and 1206 are applied as parameters to this model. Alternatively or additionally, charger service 118 may invoke a machine learning model that has been trained on historical vehicle 102 and charger behavior using waiting time 120 labels generated via the aforementioned Level 1 and Level 2 trip segmentation processes. The selected model generates a personalized waiting time prediction for requesting vehicle 102 based on predicted queue length, expected flow rate, and other contextual information. The model may also incorporate real-time charger availability status or apply scores specific to congestion scenarios.

[0110] At operation 1210, the charger service 118 transmits a predicted waiting time 120 to the vehicle 102. The predicted waiting time 120 may be included in a charger recommendation 126 and transmitted via the vehicle 102's TCU 110 or a connected mobile device 106. The waiting time 120 may be displayed via the vehicle 102's user interface (e.g., dashboard or central display) or within a mobile application executed by the mobile device 106. In some cases, the charger recommendation 126 may include additional context, such as queue length, nearby alternative stations, or available amenities. After transmitting the recommendation, process 1200 ends.

[0111] Figure 13 An exemplary computing device 1302 is shown for implementing various aspects of public charging wait time estimation and prediction. (Reference) Figure 13 And refer to Figures 1 to 12Examples of such computing devices 1302 may include vehicle 102, EVSE 104, mobile device 106, communication network 108, TCU 110, and charger monitoring server 112. Computing device 1302 typically includes computer-executable instructions, which may be executable by one or more computing devices 1302. Computer-executable instructions can be compiled or interpreted according to computer programs created using various programming languages ​​and / or technologies, individually or in combination, including but not limited to Java™, C, C++, C#, Visual Basic, Python, Perl, etc. Generally, a processor (e.g., a microprocessor) receives instructions, for example, from memory, computer-readable media, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Various computer-readable media may be used to store and transmit such instructions (such as instructions for charger service 118 and charger application 122) as well as other data (such as vehicle history 114, charger history 116, charger wait time 120, charger request 124, and charger recommendation 116).

[0112] As shown in the figure, computing device 1302 may include processor 1304, which is operatively connected to storage device 1306, network device 1308, output device 1310, and input device 1312. It should be noted that this is merely an example, and computing device 1302 with more, fewer, or different components may be used.

[0113] Processor 1304 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, processor 1304 is a system-on-a-chip (SoC) that integrates the functionality of a CPU and a GPU. The SoC may optionally include other components, such as storage device 1306 and networking device 1308, into a single integrated device. In other examples, the CPU and GPU are connected to each other via peripheral connectivity devices, such as high-speed peripheral component interconnect (PCI) or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing unit that implements an instruction set, such as x86, ARM, Power, or a family of microprocessor instruction sets without interlocking pipelines (MIPS).

[0114] Regardless of the details, during operation, processor 1304 executes stored program instructions retrieved from storage device 1306. The stored program instructions accordingly include software that controls the operation of processor 1304 to perform the operations described herein. Storage device 1306 may include both non-volatile memory devices and volatile memory devices. Non-volatile memory includes solid-state memory, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is disabled or loses power. Volatile memory includes static and dynamic random access memory (RAM) that stores program instructions and data during operation of system 100.

[0115] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device 1310. The output device 1310 may include a graphics or visual display device, such as an electronic display screen, projector, printer, or any other suitable device for reproducing a graphic display. As another example, the output device 1310 may include an audio device, such as a speaker or headphones. As yet another example, the output device 1310 may include a tactile device, such as a mechanically elevable device, which in one example may be configured to display Braille or another physical output element that can be touched to provide information to a user.

[0116] Input device 1312 may include any of a variety of devices that enable computing device 1302 to receive control input from a user. Examples of suitable input devices 1312 for receiving human-machine interface input may include a keyboard, mouse, trackball, touchscreen, microphone, graphics tablet, etc.

[0117] Network device 1308 may each include any of a variety of means that enable the described components to send and / or receive data over a network and from external devices. Examples of suitable network devices 1308 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a Bluetooth or BLE transceiver, or other network adapters or peripheral interconnects that may be useful for receiving large amounts of data in an efficient manner.

[0118] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes, etc., are described as occurring in a certain ordered order, such processes can be practiced by performing the described steps in a different order than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating specific embodiments and should in no way be construed as limiting the claims.

[0119] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. It is anticipated and expected that the techniques discussed herein will evolve in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and variations are possible with this application.

[0120] All terms used in the claims are intended to give their broadest reasonable structure and their general meaning as would be understood by one of skill in the art described herein, unless explicitly indicated otherwise herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as one or more of the elements indicated by the recitation.

[0121] An abstract of this disclosure is provided to allow the reader to quickly determine the nature of this technical disclosure. It should be understood that the abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, various features are grouped together in various embodiments for the purpose of making the disclosure fluent. This approach of the disclosure should not be construed as reflecting an intention to require more features than expressly stated in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, wherein each claim is itself a separately claimed subject matter.

[0122] According to the present invention, a method for predicting the waiting time of an electric vehicle (EV) at a charging station includes: receiving a charger request from an EV at a server, the charger request including at least a destination and a state of charge (SOC) value; determining an arrival rate of the EV to the charging station based on at least one of: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining a service rate of the charging station based on historical charging event data; applying a trained prediction model to the request based on the arrival rate and the service rate to estimate a predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to a user interface associated with the EV.

[0123] In one aspect of the invention, the trained prediction model is based on historical waiting times determined using: a Level 1 short trip identifier using trip distance and odometer change thresholds; and a Level 2 short trip identifier using trip gear patterns to divide into sub-trips and evaluate the final sub-trip based on duration and odometer change.

[0124] In one aspect of the invention, the method includes: generating training data for the prediction model by: receiving charging event data at a server including plug-in timestamps associated with charging sessions of a plurality of EVs; retrieving a plurality of trips associated with the plurality of EVs from a vehicle history database; for each EV: identifying a final trip that ended before the plug-in timestamp from the plurality of trips; determining whether the final trip is a Level 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and the odometer reading of the final trip is small. The method is defined as follows: The method is either equal to or greater than a predefined threshold; in response to the final trip not meeting the Level 1 short trip criterion, it further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and in response to the final trip being a Level 1 short trip or a Level 2 short trip, a historical waiting time is determined as the difference between the end time of the final trip and the end time of the preceding trip; wherein the historical waiting time is aggregated and used to train the prediction model.

[0125] In one aspect of the invention, the method includes: in response to the trip distance being lower than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the preceding trip being less than an adjustment time threshold, excluding the final trip from the category of Level 1 short trips as an adjustment condition.

[0126] In one aspect of the invention, determining the Level 2 short trip includes: dividing the final trip into multiple sub-trips based on the gear mode; identifying the last sub-trip prior to the plug-in timestamp; and determining whether the last sub-trip is a Level 2 short trip based on the duration of the sub-trip being less than a Level 2 duration threshold and the odometer change of the sub-trip being less than or equal to a Level 2 predefined threshold.

[0127] In one aspect of the invention, the segmentation is performed when the gear mode matches a pattern of alternating parking and driving positions.

[0128] In one aspect of the invention, the method includes verifying whether the charger is available at the time of the plug-in timestamp by analyzing the charger occupancy status.

[0129] In one aspect of this invention, in response to determining that at least one charger is available at the plug-in timestamp, the waiting time is recorded as zero.

[0130] In one aspect of the invention, the trained prediction model includes a queuing model, wherein the queuing model is one of an M / M / m model, an M / D / m model, or an M / G / m model.

[0131] In one aspect of the invention, determining the arrival rate includes: assigning a charging probability to each EV within the geofence area based on a SOC threshold; and weighting the arrival rate using the popularity score of the charging station.

[0132] According to the present invention, a server for predicting the waiting time of an electric vehicle (EV) at a charging station is provided, comprising: a memory storing instructions for charging service; and one or more computing devices configured to execute the instructions to perform operations including: receiving a charging request from an EV, the charging request including at least a destination and a state of charge (SOC) value; determining an arrival rate of the EV to the charging station based on at least one of: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining a service rate of the charging station based on historical charging event data; applying a trained prediction model to the request based on the arrival rate and the service rate to estimate a predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to a user interface associated with the EV.

[0133] According to an embodiment, the trained prediction model is based on historical waiting times determined using: Level 1 short trip identifiers using trip distance and odometer change thresholds; and Level 2 short trip identifiers using trip gear patterns to divide into sub-trips and evaluate the final sub-trip based on duration and odometer change.

[0134] According to an embodiment, the one or more computing devices are further configured to execute the instructions to perform operations to generate training data for the prediction model, the operations including: receiving charging event data at the server including plug-in timestamps associated with charging sessions of a plurality of EVs; retrieving a plurality of trips associated with the plurality of EVs from a vehicle history database; for each EV: identifying a final trip that ended before the plug-in timestamp from the plurality of trips; determining whether the final trip is a Level 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and the final trip is a Level 1 short trip. The odometer change for the trip is less than or equal to a predefined threshold; in response to the final trip not meeting the criteria for a Level 1 short trip, the method further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and in response to the final trip being a Level 1 short trip or a Level 2 short trip, the historical waiting time is determined as the difference between the end time of the final trip and the end time of the preceding trip; wherein the historical waiting time is aggregated and used to train the prediction model.

[0135] According to an embodiment, the one or more computing devices are further configured to execute the instructions to perform an operation, the operation including: in response to the trip distance being lower than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the previous trip being less than an adjustment time threshold, excluding the final trip from the category of Level 1 short trips as an adjustment condition.

[0136] According to an embodiment, determining the Level 2 short trip includes: dividing the final trip into multiple sub-trips based on the gear mode; identifying the last sub-trip before the plug-in timestamp; and determining whether the last sub-trip is a Level 2 short trip based on the duration of the sub-trip being less than a Level 2 duration threshold and the odometer change of the sub-trip being less than or equal to a Level 2 predefined threshold.

[0137] According to an embodiment, the segmentation is performed when the gear mode matches a pattern of alternating parking and driving positions.

[0138] According to an embodiment, the one or more computing devices are further configured to execute the instructions to perform operations including: verifying whether the charger is available at the time of the plug-in timestamp by analyzing the charger occupancy status; and recording the waiting time as zero in response to determining that at least one charger is available at the plug-in timestamp.

[0139] According to an embodiment, the trained prediction model includes a queuing model, wherein the queuing model is one of an M / M / m model, an M / D / m model, or an M / G / m model.

[0140] According to an embodiment, determining the arrival rate includes: assigning a charging probability to each EV within the geofence area based on a SOC threshold; and weighting the arrival rate using the popularity score of the charging station.

[0141] According to the present invention, a non-transitory computer-readable medium is provided having instructions for a charger service for predicting the waiting time of an electric vehicle (EV) at a charging station, the instructions causing the charger server to perform operations when executed by one or more computing devices of the charger server, the operations including: receiving charging event data at the server including plug-in timestamps associated with charging sessions of a plurality of EVs; retrieving a plurality of trips associated with the plurality of EVs from a vehicle history database; for each EV, determining the historical waiting time includes: identifying a final trip from the plurality of trips that ended before the plug-in timestamps; determining whether the final trip is a Class 1 short trip following a previous trip based on one or more of the following: the trip distance of the final trip is less than a threshold, and the odometer change of the final trip is less than or equal to a predefined threshold; in response to the final trip not meeting the Class 1 short trip criteria, further including analyzing the gear pattern of the final trip to determine the gear. The pattern includes whether the bit mode includes a final sub-trip that meets the criteria for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and in response to the final trip being a Level 1 or Level 2 short trip, determining the historical waiting time as the difference between the end time of the final trip and the end time of the preceding trip; receiving a charger request from an EV, the charger request including at least a destination and a state of charge (SOC) value; determining the arrival rate of the EV to the charging station based on at least one of the following: vehicle density in a geofenced area surrounding the charging station or the SOC value of nearby EVs; determining the service rate of the charging station based on historical charging event data; applying a model trained using the historical waiting time to the request based on the arrival rate and the service rate to estimate the predicted waiting time of the EV at the charging station; and transmitting the predicted waiting time to the user interface associated with the EV.

Claims

1. A method for predicting the waiting time of an electric vehicle (EV) at a charging station, comprising: The server receives a charger request from the EV, the charger request including at least the destination and the state of charge (SOC) value; The arrival rate of the EV to the charging station is determined based on at least one of the following: vehicle density in the geofenced area surrounding the charging station or the SOC value of nearby EVs. The service rate of the charging station is determined based on historical charging event data. A trained prediction model is applied to the request based on the arrival rate and the service rate to estimate the predicted waiting time of the EV at the charging station; as well as The predicted waiting time is transmitted to the user interface associated with the EV.

2. The method of claim 1, wherein the trained prediction model is based on historical waiting times determined using the following: Level 1 short-distance trip identification using travel distance and odometer change thresholds; and Use a Level 2 short trip identifier that divides the trip gear pattern into sub-trips and evaluates the final sub-trip based on duration and odometer changes.

3. The method of claim 1, further comprising generating training data for the prediction model by: The server receives charging event data including plug-in timestamps associated with charging sessions of multiple EVs. Retrieve multiple trips associated with the multiple EVs from the vehicle history database; For each EV: The final trip that ended before the plug-in timestamp is identified from the plurality of trips; Whether the final trip is a Level 1 short trip following the previous trip is determined based on one or more of the following: the trip distance of the final trip is less than a threshold and the odometer change of the final trip is less than or equal to a predefined threshold; In response to the final trip not meeting the Level 1 short trip standard, the method further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the standard for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and In response to the final trip being a Class 1 short trip or a Class 2 short trip, the historical waiting time is determined as the difference between the end time of the final trip and the end time of the previous trip; The historical waiting times are aggregated and used to train the prediction model.

4. The method of claim 3, further comprising: In response to the trip distance being lower than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the preceding trip being less than an adjustment time threshold, the final trip is excluded from the category of Level 1 short trips as an adjustment case.

5. The method of claim 3, wherein determining the level 2 short-distance trip comprises: Based on the gear mode, the final travel is divided into multiple sub-travels; The last sub-trip prior to the plug-in timestamp; as well as Whether the last sub-trip is a Level 2 short trip is determined based on the fact that the duration of the sub-trip is less than the Level 2 duration threshold and the odometer change of the sub-trip is less than or equal to the Level 2 predefined threshold.

6. The method of claim 5, wherein the segmentation is performed when the gear mode matches a pattern of alternating parking and drive positions.

7. The method of claim 3, further comprising verifying whether the charger is available at the time of the plug-in timestamp by analyzing the charger occupancy status.

8. The method of claim 7, wherein the waiting time is recorded as zero in response to determining that at least one charger is available at the plug-in timestamp.

9. The method of claim 1, wherein the trained prediction model includes a queuing model, wherein the queuing model is one of an M / M / m model, an M / D / m model, or an M / G / m model.

10. The method of claim 1, wherein determining the arrival rate comprises: Based on the SOC threshold, a charging probability is assigned to each EV within the geofence area; as well as The arrival rate is weighted using the popularity score of the charging station.

11. A server for predicting the waiting time of an electric vehicle (EV) at a charging station, comprising: The memory stores instructions for the charger service; as well as One or more computing devices are configured to execute the instructions to perform operations, the operations including: Receive a charger request from an EV, the charger request including at least the destination and state of charge (SOC) value. The arrival rate of the EV to the charging station is determined based on at least one of the following: vehicle density in the geofenced area surrounding the charging station or the SOC value of nearby EVs. The service rate of the charging station is determined based on historical charging event data. A trained prediction model is applied to the request based on the arrival rate and the service rate to estimate the predicted waiting time of the EV at the charging station. The predicted waiting time is transmitted to the user interface associated with the EV.

12. The server of claim 11, wherein the trained prediction model is based on historical latency determined using the following: Level 1 short-distance trip identification using travel distance and odometer change thresholds; and Use a Level 2 short trip identifier that divides the trip gear pattern into sub-trips and evaluates the final sub-trip based on duration and odometer changes.

13. The server of claim 11, wherein the one or more computing devices are further configured to execute the instructions to perform operations to generate training data for the prediction model, the operations including: The server receives charging event data including plug-in timestamps associated with charging sessions of multiple EVs. Retrieve multiple trips associated with the multiple EVs from the vehicle history database; For each EV: The final trip that ended before the plug-in timestamp is identified from the plurality of trips; Whether the final trip is a Level 1 short trip following the previous trip is determined based on one or more of the following: the trip distance of the final trip is less than a threshold and the odometer change of the final trip is less than or equal to a predefined threshold; In response to the final trip not meeting the Level 1 short trip standard, the method further includes analyzing the gear pattern of the final trip to determine whether the gear pattern includes a final sub-trip that meets the standard for a Level 2 short trip, the final sub-trip being usable as the final trip, and a previous sub-trip or trip being usable as the preceding trip; and In response to the final trip being a Class 1 short trip or a Class 2 short trip, the historical waiting time is determined as the difference between the end time of the final trip and the end time of the previous trip; The historical waiting times are aggregated and used to train the prediction model.

14. The server of claim 13, wherein the one or more computing devices are further configured to execute the instructions to perform an operation, the operation including: In response to the trip distance being lower than an adjustment distance threshold and the difference between the end time of the final trip and the end time of the preceding trip being less than an adjustment time threshold, the final trip is excluded from the category of Level 1 short trips as an adjustment case.

15. The server of claim 13, wherein determining the Level 2 short-distance trip includes: Based on the gear mode, the final travel is divided into multiple sub-travels; The last sub-trip prior to the plug-in timestamp; as well as Whether the last sub-trip is a Level 2 short trip is determined based on the fact that the duration of the sub-trip is less than the Level 2 duration threshold and the odometer change of the sub-trip is less than or equal to the Level 2 predefined threshold. The segmentation is performed when the gear mode matches a pattern of alternating parking and driving positions.

Images