A vehicle reservation method and device based on predicted vehicle use time, a vehicle reservation equipment and a vehicle

Abstract

The application provides a vehicle preparation method and device based on predicted vehicle use time, equipment and vehicle. When it is determined that the vehicle parking position is a frequent parking position, the vehicle starting time corresponding to the frequent parking position is obtained. When the difference between the current time and the vehicle starting time is less than a preset time length, it is determined whether the vehicle has a vehicle preparation demand. When it is determined that the vehicle has a vehicle preparation demand, a vehicle preparation request is sent to a target user. After the user obtains the vehicle preparation request, the user can determine whether the vehicle needs to be prepared according to the actual demand, so as to remind the user to prepare the vehicle before use. Compared with the prior art, the present application adds a process of reminding the user to prepare the vehicle at a suitable time point, so that the user can be reminded to prepare the vehicle in time.

Description

Technical Field

[0001] This invention relates to the field of automotive control technology, and more specifically to a vehicle standby method, apparatus, equipment, and vehicle based on predicted vehicle usage time. Background Technology

[0002] With the continuous development of automotive technology, users' functional needs for automobiles are becoming increasingly diversified. The vehicle backup function has become one of the basic functions of a vehicle. In this solution, the so-called backup function refers to adjusting the interior temperature, seat temperature, and / or steering wheel temperature in advance before the user arrives at the vehicle location, so that the interior environment is in a comfortable state when the user uses the vehicle.

[0003] In existing solutions, the vehicle standby function is usually triggered by the user when using the vehicle. That is, when the user needs to use the vehicle, if the user predicts that the temperature inside the vehicle is too high or too low, the user will actively control the vehicle to enter standby mode. This standby mode is initiated by the user. If the user forgets to standby, the temperature inside the vehicle will be too high or too low when the user starts the vehicle, and the user will not be able to use the vehicle immediately. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a vehicle standby method, apparatus, device, and vehicle based on predicted vehicle usage time, so as to predict the user's vehicle usage time, determine whether there is a need for a standby vehicle before the usage time arrives, and send a standby vehicle request to the target user when there is a need for a standby vehicle.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] A vehicle standby method based on predicted vehicle usage time includes:

[0007] Get parking location;

[0008] Determine whether the parking location is a frequently parked location, where a frequently parked location refers to a location where the vehicle is parked more than a preset number of times.

[0009] When the parking location is a frequently parked location, obtain the historical start time of the vehicle corresponding to the frequently parked location;

[0010] The vehicle startup time is calculated based on the vehicle's historical startup time.

[0011] Determine whether the difference between the current time and the vehicle start time is less than a preset duration;

[0012] When the difference between the current time and the vehicle start time is less than a preset duration, the current in-vehicle environment parameters are obtained;

[0013] Based on the current in-vehicle environmental parameters, determine whether the vehicle needs a backup vehicle;

[0014] When a vehicle needs to be replaced, a replacement vehicle request is generated and sent to the target user.

[0015] Optionally, in the above-mentioned vehicle preparation method based on predicted vehicle usage time, determining whether the parking location is in a frequently parked location includes:

[0016] Determine whether the parking location is located within a preset frequent parking area, where the frequent parking area is an area where the number of times the user parks the vehicle exceeds a preset number;

[0017] When the parking location is located within a preset frequent parking area, it indicates that the parking location is a frequent parking location.

[0018] Optionally, in the above-mentioned vehicle standby method based on predicted vehicle usage time, the vehicle's standby requirement is determined based on the current in-vehicle environmental parameters.

[0019] Obtain the vehicle interior temperature from the current vehicle interior environment parameters; determine whether the vehicle interior temperature is within a preset temperature range;

[0020] When the interior temperature is within the preset temperature range, it indicates that the vehicle does not require a backup vehicle; when the interior temperature is not within the preset temperature range, it indicates that the vehicle requires a backup vehicle.

[0021] Optionally, in the above-mentioned vehicle standby method based on predicted vehicle usage time, when a vehicle has a standby requirement, a standby request is generated and sent to the target user, including:

[0022] When a vehicle needs to be put on standby, the standby time is calculated based on the current in-vehicle environmental parameters, the target in-vehicle environmental parameters, and the standby operating conditions. The standby operating conditions refer to the working status data of the vehicle system during the standby process. The vehicle system is used to adjust the in-vehicle environmental parameters. The standby time refers to the time it takes for the in-vehicle environmental parameters to reach the target in-vehicle environmental parameters after the vehicle system is started.

[0023] The reminder notification time is calculated based on the vehicle start time and the vehicle preparation time. The reminder notification time is located before the vehicle start time on the timeline, and the difference between the two is greater than the vehicle preparation time.

[0024] When the reminder notification time arrives, a vehicle standby request is generated and sent to the target user.

[0025] Optionally, in the above-mentioned vehicle standby method based on predicted vehicle usage time, calculating the reminder notification time based on the vehicle start time and the standby duration includes:

[0026] The time on the timeline that is a first preset duration before the vehicle start time is used as the reminder notification time. The first preset duration is the sum of the vehicle preparation time and the second preset duration, which is a fixed duration.

[0027] Optionally, in the above-mentioned vehicle standby method based on predicted vehicle usage time, calculating the vehicle startup time based on the vehicle's historical startup time includes:

[0028] Obtain the driving routes and historical driving times corresponding to the frequently stopped locations;

[0029] Obtain traffic information and predicted travel time for the driving route;

[0030] The vehicle start time is calculated based on the predicted time, the historical time, and the vehicle's historical start time.

[0031] Optionally, in the above-mentioned vehicle standby method based on predicted vehicle usage time, after generating and sending a standby request to the target user when a vehicle has a standby requirement, it further includes:

[0032] When the response result of the target user in response to the vehicle backup request is obtained, it is determined whether the vehicle needs to be backed up based on the response result.

[0033] When it is necessary to prepare the vehicle, control the vehicle to enter the standby state;

[0034] When vehicle preparation is detected as complete and the vehicle has not started, a notification message indicating that vehicle preparation is complete is sent to the target user.

[0035] A vehicle standby device based on predicted vehicle usage time includes:

[0036] The parking location determination unit is used to obtain the parking location and determine whether the parking location is a frequently parked location;

[0037] The start-up time calculation unit is used to obtain the historical start-up time of the vehicle corresponding to the frequent parking location when the parking location is a frequent parking location, and calculate the vehicle start-up time based on the historical start-up time of the vehicle.

[0038] The vehicle standby requirement determination unit is used to determine whether the difference between the current time and the vehicle start time is within a preset range; when the difference between the current time and the vehicle start time is within the preset range, it obtains the current in-vehicle environment parameters; and determines whether the vehicle has a standby requirement based on the current in-vehicle environment parameters.

[0039] The reminder unit is used to generate and send a vehicle standby request to the target user when the vehicle needs to be standby.

[0040] A vehicle standby device based on predicted vehicle usage time includes: a memory and a processor;

[0041] The memory is used to store programs;

[0042] The processor is used to execute the program to implement each step of the user departure time reminder method based on traffic conditions described above.

[0043] A vehicle includes the aforementioned backup vehicle device based on predicted vehicle usage time.

[0044] Based on the above technical solution, the solution provided by the embodiments of the present invention, when it is determined that the vehicle parking location is a frequently parked location, obtains the vehicle start time corresponding to the frequently parked location. When the difference between the current time and the vehicle start time is less than a preset duration, it is determined whether the vehicle needs to be prepared for use. When it is determined that the vehicle needs to be prepared for use, a preparation request is sent to the target user. After receiving the preparation request, the user can determine whether to prepare the vehicle according to their actual needs, thereby reminding the user to prepare the vehicle before use. Compared with the prior art, this solution adds a process of reminding the user to prepare the vehicle at an appropriate time, which can remind the user to prepare the vehicle in a timely manner. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating the vehicle preparation method based on predicted vehicle usage time disclosed in an embodiment of this application;

[0047] Figure 2 This is a flowchart illustrating a vehicle preparation method based on predicted vehicle usage time, as disclosed in another embodiment of this application.

[0048] Figure 3 This is a flowchart illustrating a vehicle preparation method based on predicted vehicle usage time, as disclosed in another embodiment of this application.

[0049] Figure 4 This is a flowchart illustrating a vehicle preparation method based on predicted vehicle usage time, as disclosed in another embodiment of this application.

[0050] Figure 5 This is a schematic diagram of the vehicle standby device based on predicted vehicle usage time disclosed in an embodiment of this application;

[0051] Figure 6 This is a schematic diagram of the structure of the standby vehicle device based on predicted vehicle usage time disclosed in an embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] In this solution, in order to promptly remind users to depart early when route congestion is predicted, thus preventing users from exceeding the time limit, this application discloses a vehicle standby method based on predicted usage time. This solution is based on the vehicle's parking location and vehicle start time, and before the vehicle start time arrives, it determines whether there is a need for a standby vehicle. When there is a need for a standby vehicle, a standby vehicle request is generated and sent to the target user.

[0054] For details, see Figure 1 This application discloses a vehicle standby method based on predicted vehicle usage time, the method comprising:

[0055] Step S101: Obtain the parking location.

[0056] The parking location refers to the position of the vehicle after it has been parked and the engine turned off. For example, this location could refer to the position where a user parks their vehicle after returning home from get off work.

[0057] Step S102: Determine whether the parking location is a frequently parked location.

[0058] In this solution, a frequently used parking location can be pre-determined. This location refers to a place where the user parks extremely frequently or repeatedly. For example, the frequently used parking location could be where the user parks their vehicle during their daily commute. This location can be automatically determined by the system based on the user's historical parking data, or it can be actively constructed by the user. A frequently used parking location can refer to a specific coordinate location or a range of areas. For instance, when the user has their own designated parking space, the frequently used parking location can be a specific coordinate location. When the user does not have their own parking space, they typically park their vehicle within a certain area, in which case the frequently used parking location could refer to a range centered on the user's residence or workplace.

[0059] When the frequently parked location is a range, determining whether a parking location is a frequently parked location can specifically include: determining whether the parking location is located within a preset frequently parked area. The frequently parked area is an area where the number of times a user parks their vehicle exceeds a preset number. The preset number can be set according to the user's needs, for example, it can be 100 times, 150 times, 200 times, etc. When the number of times a user parks in the same area exceeds the preset number, the parking area can be considered a frequently parked area. The parking area can refer to a circular area with a radius of 100 meters, 200 meters, or 300 meters, etc. When the parking location is within this area, it indicates that the parking location is a frequently parked location.

[0060] In the technical solution disclosed in this embodiment, it can also be determined whether the parking location is a frequently parked location by the following method: Obtain the time points of vehicle start-up from the same location in historical driving data. If the start-up time points have an error within a preset time period (e.g., 30 minutes or other durations), they are considered to have similar time points. For example, the time points of vehicle start-up from the same location are [15:00, 15:01, 15:01, 15:02, 15:02, 15:04, 15:05, 15:09, 15:14, 15:15, 15:05]. :20,115:25,15:31,15:31,15:32,15:34; Take the time points within the 30 minutes of [15:01-15:31] as the time interval for starting the vehicle; Remove the time points with the fewest occurrences [15:00,15:32,15:34]; Take relevant data from the nearest preset time period (30 days): Calculate the value of the number of starts within the time interval / the total number of starts at the current location. When the calculation result is greater than or equal to a preset ratio (80% or other preset ratios), the current parking location of the vehicle is considered a frequent parking location.

[0061] In this solution, considering that users need to strictly clock in and out at work, it is necessary to remind them to leave in a timely manner. However, since there is no requirement for users to arrive home after get off work, the frequently parked locations can be further restricted. For example, in this solution, users can pre-set their company location and residential location. When a frequently parked location is detected to be close to the company location, its frequent parking location marker can be removed. Here, "close to the company location" can refer to a range within a preset radius centered on the company location.

[0062] Of course, in this embodiment, when statistical analysis of historical driving data reveals multiple frequent parking locations, a prompt can be issued to the user. Based on the user's selection, the frequent parking location to be monitored is determined as the frequent parking location used in step S102, thereby enabling the user to customize the frequent parking location. At the same time, the user can also actively configure the corresponding driving route for each frequent parking location. The driving route can be a navigation route extracted from an electronic map. That is, when setting a frequent parking location, the user can first navigate to a route on the electronic map, then save and configure the route for the frequent parking location, using the route as the driving route corresponding to the frequent parking location.

[0063] Step S103: When the parking location is a frequently parked location, obtain the vehicle's historical start time corresponding to the frequently parked location.

[0064] In this step, when a vehicle's parking location is detected to be a frequently parked location, the historical start time of the vehicle corresponding to that location can be obtained. This historical start time can be obtained by analyzing driving data associated with the frequently parked location in historical driving data. For example, in historical driving data, if the probability of the vehicle traveling along a certain route after starting is greater than a preset threshold when the vehicle is parked at the frequently parked location (e.g., 60%, 70%, or 80%), then that route can be considered the route corresponding to the frequently parked location. The average historical start time of the vehicle corresponding to that route is the historical start time of the vehicle corresponding to the frequently parked location, and the average travel time of that route is the historical travel time corresponding to the frequently parked location. The historical travel time refers to the time taken by the user to reach the destination of the route from its starting point in the historical driving data; this historical travel time can be an average value. Alternatively, the route can refer to the route actively configured by the user for the frequently parked location in the previous step.

[0065] Step S104: Calculate the vehicle startup time based on the vehicle's historical startup time.

[0066] In this step, when determining the vehicle's historical start time, without considering other factors, the vehicle's historical start time can be used as the vehicle's next start time. The vehicle start time is the predicted time for the user to start the vehicle next time. For example, if the vehicle's historical start time is usually 8:00 AM, then without considering other interfering factors, the calculated vehicle start time will also be 8:00 AM.

[0067] In the technical solution disclosed in this embodiment, in addition to calculating the vehicle startup time as described above, a trained analysis model can also be used to predict the vehicle startup time. This analysis model is trained using historical data, which may include a preset time period (e.g., the time period between the current time and a preset time, where the preset time can refer to any value such as 30 days, 60 days, or 100 days). Specifically, the historical data used to train the analysis model may include: vehicle VIN, date (month and day), day of the week, date specificity, weather on that day, GPS positioning each time the vehicle is powered on, and vehicle startup time (hour and minute). The date specificity may include whether it is a weekday, the first weekday after a weekend, the last weekday before a weekend, the first weekday after a holiday, the last weekday before a holiday, or the first weekday after a holiday. This data can be manually labeled or obtained using existing third-party data. The weather conditions may include light rain, moderate rain, heavy rain, light snow, etc. Moderate snow, heavy snow, hail, dense fog, etc.; Before training, the vehicle can be divided into multiple historical data sets based on the GPS positioning. The distance difference between the GPS positioning of the corresponding vehicle when it is powered on in different historical data sets is not greater than a preset distance. The analysis model is trained by self-learning using historical data from different historical data sets. During the training process, the input data is the vehicle VIN, date (month and day), day of the week, date special characteristics (holidays, weekdays), weather of the day, and GPS positioning of the vehicle each time it is powered on. The output data is the vehicle's start time (hour and minute) each time. At this time, an analysis model matching different GPS positioning can be obtained. When specifically predicting the vehicle's start time, the analysis model used to perform this prediction can be determined based on the GPS positioning of the vehicle when it was most recently powered off. Then, the vehicle VIN, date, day of the week, date special characteristics, and weather of the day corresponding to the current moment can be obtained. The vehicle VIN, date, day of the week, date special characteristics, and weather of the day are input into the analysis model to predict the start time. In this scheme, the GPS positioning error reported each time the power is turned off and on is considered to be within a preset distance (600 meters) and can be counted as a location. When obtaining GPS positioning, the GPS information in the CAN signal is selected first. If there is no GPS information in the CAN signal each time the power is turned off and on, the GPS information in the travel embedded point can be used.

[0068] Step S105: Determine whether the difference between the current time and the vehicle start time is less than a preset duration.

[0069] Once the vehicle start time is determined, the current time needs to be monitored based on that start time. Specifically, to ensure the vehicle is ready before the user gets in, it's necessary to determine whether the vehicle needs to be prepared before the start time arrives. The preset duration can be a fixed duration, such as 5 minutes, 10 minutes, or 15 minutes. That is, in this step, it's determined whether the time difference between the current time and the vehicle start time is less than the preset duration. If it is less than the preset duration, it's necessary to determine whether the vehicle needs to be prepared. If it is not less than the preset duration, the difference between the two needs to be monitored further.

[0070] Step S106: Obtain current in-vehicle environmental parameters;

[0071] In this step, when the difference between the current time and the vehicle start time is less than a preset duration, it indicates that the user's car usage time is approaching. At this time, in order to provide the user with a comfortable driving environment, it is necessary to obtain the in-vehicle environmental parameters at the current moment. In this solution, the in-vehicle environmental parameters may include, but are not limited to, in-vehicle ambient temperature, in-vehicle seat temperature, steering wheel temperature, concentration of harmful gases in the vehicle, etc.

[0072] Step S107: Determine whether the vehicle needs a backup vehicle based on the current in-vehicle environment parameters.

[0073] After obtaining the current in-vehicle environmental parameters, it is possible to determine whether the vehicle needs to be used as a backup vehicle by comparing the current in-vehicle environmental parameters with the target parameters. Taking the in-vehicle temperature as an example, if the current in-vehicle environmental parameters show an in-vehicle temperature of 40°C, while the target in-vehicle temperature is 25°C-29°C, it can be determined by comparing the two that the vehicle needs to be used as a backup vehicle.

[0074] Furthermore, when the in-vehicle environment parameter is the in-vehicle temperature, considering that the outdoor temperature varies with different seasons, users' clothing habits also differ. For example, in the hot summer, users wear light clothing, and when preparing the car, controlling the in-vehicle temperature at around 27°C will make users feel comfortable. In the cold winter, users wear thicker clothing, and if the in-vehicle temperature is still controlled at around 27°C when preparing the car, users will feel that the in-vehicle temperature is too high. Therefore, it can be seen that the target in-vehicle temperature varies with different external environments, thus providing users with appropriate car preparation strategies under different external environments.

[0075] Specifically, in the above solution, obtaining the target vehicle interior temperature can include:

[0076] ① Obtain the average daytime temperature of the area where the vehicle is located within a preset time period.

[0077] In this step, the vehicle's location refers to its current location, which can be a county, district, or city. Once the vehicle's location is determined, the average daily temperature for a preset time period can be obtained. This preset time period can be the average daily temperature over the three days prior to the current time. Based on the average daily temperature, the user's clothing index can be determined, and the clothing index can be used to determine the user's desired interior temperature. In this solution, a mapping relationship between the average daily temperature and the clothing index can be established in advance, and then a mapping relationship between the average daily temperature and the desired interior temperature can be established. Thus, after obtaining the average daily temperature, the corresponding desired interior temperature can be obtained. Alternatively, the clothing index for the vehicle's location on that day can be obtained directly from an electronic map system, and then the corresponding desired interior temperature can be determined directly based on the clothing index.

[0078] ② Obtain the target vehicle interior temperature that matches the daytime average temperature.

[0079] The higher the average daytime temperature, the cooler the user's clothing, and the higher the target vehicle interior temperature value; conversely, the lower the average daytime temperature, the thicker the user's clothing, and the lower the target vehicle interior temperature value.

[0080] Step S108: When a vehicle has a backup vehicle requirement, generate and send a backup vehicle request to the target user.

[0081] In this step, when it is determined that there is a need for a backup vehicle, a backup vehicle request can be sent to the target user. The target user can refer to the communication terminal of the vehicle's driver. In this solution, the binding relationship between the vehicle and the driver's communication terminal can be stored in advance. When there is a need for a backup vehicle, the communication method of the target user can be retrieved directly through this relationship, and the backup vehicle request can be sent to the target user based on the communication method. After receiving the vehicle standby request, the user can determine whether standby operation is needed based on the request. If standby is needed, the user can send a confirmation command; if standby is not needed, the user can choose not to send a confirmation command or send a negative command. When the system using this method generates and sends a standby request to the target user, it detects the target user's response. Upon receiving the target user's response to the standby request, the system can determine whether standby is necessary. If the user sends a confirmation command, it indicates that standby is needed, and the vehicle is put into standby mode. Furthermore, to help the user understand the standby status and schedule their vehicle usage time appropriately, when standby is detected as complete and the vehicle is not started, a notification message indicating standby completion is sent to the target user. In this solution, vehicle startup refers to the vehicle's engine or electric motor entering the startup state. The reason for sending the notification message indicating vehicle preparation completion when the vehicle is not started is that if the vehicle has already started, it means the user is already in the vehicle, and sending a notification message to the user at this point would be meaningless. Therefore, the notification message indicating vehicle preparation completion can only be sent to the target user when the vehicle is not started. Furthermore, to help the user accurately determine whether vehicle preparation needs to be initiated, the current in-vehicle environmental parameters can be loaded into the vehicle preparation request. The user can then more accurately determine whether vehicle preparation needs to be initiated based on the current in-vehicle environmental parameters in the request.

[0082] As can be seen from the above solution, when the vehicle parking location is determined to be a frequently parked location, the solution obtains the vehicle start time corresponding to that frequently parked location. When the difference between the current time and the vehicle start time is less than a preset duration, it determines whether the vehicle needs to be prepared for use. Once it is determined that the vehicle needs to be prepared for use, a preparation request is sent to the target user. After receiving the preparation request, the user can determine whether to prepare the vehicle based on their actual needs, thus reminding the user to prepare the vehicle before use. Compared with the existing technology, this solution adds a process of reminding the user to prepare the vehicle at an appropriate time, which can remind the user to prepare the vehicle in a timely manner.

[0083] In this embodiment, the in-vehicle environmental parameters may include one or more monitoring parameters. For example, they may include the in-vehicle ambient temperature, in-vehicle seat temperature, steering wheel temperature, concentration of harmful gases in the vehicle, etc. In this solution, the in-vehicle ambient temperature can be used as an example to introduce the process of determining whether the vehicle needs to be prepared for standby.

[0084] Step S201: Obtain the in-vehicle temperature from the current in-vehicle environment parameters.

[0085] In this step, the acquired in-vehicle environment data may contain multiple data points. In this solution, one or two data points can be monitored for vehicle standby. For example, some users have higher requirements and need to monitor data such as seat temperature, steering wheel temperature, concentration of harmful gases in the vehicle, and in-vehicle temperature, while other users have lower requirements and only need to monitor the in-vehicle temperature. Therefore, in this step, after acquiring the current in-vehicle environment parameters, a target parameter needs to be extracted from these parameters. In this embodiment, the target parameter is the in-vehicle temperature. The specific parameters used as target parameters can be pre-configured by the user.

[0086] Step S202: Determine whether the interior temperature is within the preset temperature range.

[0087] In this step, after obtaining the target parameter, the target parameter is compared with the preset conditions that match the target parameter to determine whether the target parameter meets the preset conditions. If the preset conditions are met, it indicates that the vehicle does not need a backup vehicle; otherwise, it indicates that the vehicle needs a backup vehicle.

[0088] In this step, taking the vehicle interior temperature as an example, after obtaining the vehicle interior temperature, it is compared with a pre-marked preset temperature range. The preset temperature range is a comfortable temperature range that is pre-configured by the user or automatically configured by the system. For example, in this solution, the range can be 25℃-29℃. When the vehicle interior temperature falls within this range, it indicates that there is no need for a backup vehicle. When it does not fall within this range, it indicates that there is a need for a backup vehicle.

[0089] In this embodiment, to ensure the vehicle's interior environment is optimal when the user gets in, the timing of sending the vehicle preparation request to the user needs to be appropriately set. This prevents a situation where the user receives the request and immediately notifies the vehicle to prepare, but the preparation is not yet complete when the user needs to use the vehicle. For this, see [link to relevant documentation]. Figure 3 In the above scheme, when a vehicle needs to be kept in reserve, a vehicle reserve request is generated and sent to the target user, including:

[0090] Step S301: Calculate the vehicle standby time based on the current in-vehicle environment parameters, the target in-vehicle environment parameters, and the standby operating conditions;

[0091] When a vehicle needs to be put on standby, the standby time needs to be calculated in order to reasonably set the time when the standby request is sent. When calculating the standby time, it can be calculated based on the current in-vehicle environmental parameters, the target in-vehicle environmental parameters, and the standby operating conditions. The standby operating conditions refer to the working status data of the vehicle system during the standby process. The vehicle system is used to adjust the in-vehicle environmental parameters. For example, the vehicle system can be a vehicle air conditioner. The standby operating conditions refer to the output power, working level, and other data of the air conditioning system during the standby process. The standby time refers to the time it takes for the in-vehicle environmental parameters to reach the target in-vehicle environmental parameters after the vehicle system is started.

[0092] In another embodiment of the technical solution disclosed in this application, considering that the standby effect of different vehicles during the standby process varies, even under the same standby conditions, the time required to reach the target in-vehicle environmental parameter may differ. For example, as the air conditioning system ages or the air conditioning filter gradually becomes clogged, the heating and cooling capacity of the air conditioning system will gradually decrease. In this case, even if the in-vehicle temperature is adjusted under the same air conditioning conditions, the time taken by the air conditioning system with different degrees of aging and filter clogging will be different. Therefore, in this embodiment, the standby time calculated based on the in-vehicle environmental parameter, the target environmental parameter, and the standby conditions may further include: obtaining the change curve of the in-vehicle environmental parameter under the standby conditions with the standby time during the standby process; calculating the time required for the in-vehicle environmental parameter to reach the target environmental parameter during the standby process based on the change curve, and recording the time taken as the standby time. In this embodiment, the change curve is dynamically updated to ensure the reliability of the standby time calculation result.

[0093] Step S302: Calculate the reminder notification time based on the vehicle start time and the vehicle standby time.

[0094] Once the vehicle standby time is determined, the time for sending the vehicle standby request is determined based on the vehicle standby time and the vehicle start time. In this application, in order to ensure that the in-vehicle environment has reached its optimal state when the user uses the vehicle, the time between the time for sending the vehicle standby request and the vehicle start time must be at least greater than the vehicle standby time. Only when it is greater than the vehicle standby time can sufficient standby time be provided for the vehicle. That is, the time of the reminder notification is located before the vehicle start time on the timeline, and the difference between the two is greater than the vehicle standby time.

[0095] Step S303: When the reminder notification time arrives, generate and send a vehicle standby request to the target user.

[0096] Once the reminder notification time is determined, the current time is monitored. When the current time reaches the reminder notification time, a vehicle standby request is sent to the target user.

[0097] In the technical solution disclosed in this embodiment, considering that the target user does not receive the vehicle standby request immediately, but only sees it after a period of time, even if the user immediately controls the vehicle to standby, the vehicle's internal environment will not be in optimal condition when the vehicle starts. Therefore, in this solution, the reminder notification time can be advanced on the timeline. Specifically, in this embodiment, a first preset time period on the timeline before the vehicle starts can be used as the reminder notification time. The first preset time period is the sum of the standby time period and a second preset time period, where the second preset time period is a fixed duration, such as 5 minutes, 6 minutes, 7 minutes, or 8 minutes, etc. In another technical solution disclosed in an embodiment, a standby request can also be generated and sent to the user immediately when it is determined that the vehicle needs standby. In this scenario, if the response result indicates that the vehicle needs to be prepared, immediately preparing the vehicle might result in a situation where the vehicle is ready but the start-up time has not yet arrived, leading to a waste of vehicle energy. To address this, when the response result indicates that the vehicle needs to be prepared, it can be determined whether the time between the current time and the vehicle start-up time is greater than the preparation time. If it is greater than the preparation time, the process continues to wait; if it is not greater than the preparation time, the vehicle is put into preparation mode. This ensures that the vehicle is ready just as the user needs to use it, thus preventing the energy waste caused by immediately preparing the vehicle when the response result indicates that it needs to be prepared.

[0098] In the scheme disclosed in this embodiment, the driving routes corresponding to the frequently parked locations are generally fixed. For example, for company employees who drive to and from get off work, both the parking location after get off work and the parking location after work can be considered as the frequently parked locations. The user uses a fixed driving route to and from get off work every day. If the determined frequently parked location is the user's parking location after get off work, then the user is highly likely to use that same route the next time they start their vehicle. To ensure they can clock in on time, the user needs to rationally arrange the vehicle's start time based on the traffic conditions along different routes. For example, if the user finds the route congested, they need to leave earlier. In this case, the user's actual vehicle start time is earlier than the vehicle's historical start time. If the vehicle standby demand detection continues based on the historical start time, it may result in the vehicle not being ready when the user needs to use the vehicle. For this, see [link to relevant documentation]. Figure 4The method described above calculates the vehicle startup time based on the vehicle's historical startup time, which may specifically include:

[0099] Step S401: Obtain the driving route and historical driving time corresponding to the frequently stopped locations.

[0100] In this step, after determining that the parking location is a frequently parked location, the driving route corresponding to the frequently parked location and the historical time taken for the driving route are obtained. Once the driving route is determined, it is used as the driving route that the user will use the next time they start the vehicle.

[0101] Step S402: Obtain the road condition information and predicted travel time for the driving route.

[0102] Once the driving route is determined, traffic information for that route can be obtained through an electronic map system. This traffic information may include information on road congestion, road construction, and real-time vehicle accident information along the route. This traffic information can be collected through a real-time electronic map. In other words, the system used in this solution can be associated with an electronic map system. Once the driving route is determined, the electronic map system can obtain the corresponding traffic information and the corresponding predicted travel time. The predicted travel time can be the travel time for the driving route predicted by the electronic map system.

[0103] Step S403: Calculate the vehicle start time based on the predicted time duration, the historical time duration, and the vehicle's historical start time.

[0104] In this step, after the predicted time, historical time, and historical vehicle start time are determined, it is necessary to predict the vehicle start time for the next vehicle start. Here, the vehicle start time refers to the latest departure time that the user can reach the destination of the route on time under the current road conditions. If the historical time is less than the predicted time, the time difference between the predicted time and the historical time can be calculated first, and then the historical vehicle start time can be advanced by the time node corresponding to the time difference along the time axis as the vehicle start time. This vehicle start time is the latest departure time that the user can reach the destination of the route on time.

[0105] At this time, when sending a vehicle standby request, the road condition information of the driving route, the predicted travel time, and the calculated vehicle start time can be loaded into the vehicle standby request so that the user can more accurately control the departure time.

[0106] Of course, considering that users have different driving habits, their speed, overtaking, and yielding behavior on the driving route will also be different. Therefore, there will be a certain deviation between the actual time taken by the user and the predicted time. This deviation can be corrected by using a preset coefficient.

[0107] When it is necessary to correct the predicted time using a preset coefficient, the preset coefficient can be calculated based on historical driving data analysis. Specifically, the predicted time and actual time of navigation routes in the user's historical navigation data can be statistically analyzed to calculate the ratio of the predicted time to the actual time for each navigation session. The average value of these ratios can be taken as the preset coefficient. At this point, the predicted time can be corrected based on the preset coefficient, and the corrected predicted time can be used as the predicted time for calculating the vehicle start time.

[0108] This embodiment discloses a vehicle standby device based on predicted vehicle usage time. For the specific working content of each unit in the device, please refer to the content of the above method embodiment.

[0109] The following describes the vehicle standby device based on predicted vehicle usage time provided in the embodiments of the present invention. The vehicle standby device based on predicted vehicle usage time described below can be referred to in correspondence with the vehicle standby method based on predicted vehicle usage time described above.

[0110] This embodiment discloses a vehicle standby device based on predicted vehicle usage time. For the specific working content of each unit in the device, please refer to the content of the above method embodiment.

[0111] The following describes the vehicle standby device based on predicted vehicle usage time provided in the embodiments of the present invention. The vehicle standby device based on predicted vehicle usage time described below can be referred to in correspondence with the vehicle standby method based on predicted vehicle usage time described above.

[0112] See Figure 5 The device may include: a parking position determination unit 10, a start time calculation unit 20, a vehicle standby requirement determination unit 30, and a reminder unit 40;

[0113] The parking location determination unit 10, corresponding to the above method steps S101 and S102, is used to obtain the parking location and determine whether the parking location is a frequent parking location.

[0114] The start-up time calculation unit 20, corresponding to the above method steps S103 and S104, is used to obtain the vehicle's historical start-up time corresponding to the frequent parking location when the parking location is a frequent parking location, and calculate the vehicle start-up time based on the vehicle's historical start-up time.

[0115] The vehicle standby requirement judgment unit 30, corresponding to the above method steps S105-S107, is used to determine whether the difference between the current time and the vehicle start time is within a preset range; when the difference between the current time and the vehicle start time is within the preset range, the current in-vehicle environment parameters are obtained; and based on the current in-vehicle environment parameters, it is determined whether the vehicle has a standby requirement.

[0116] The reminder unit 40, corresponding to step S108 of the above method, is used to generate and send a backup vehicle request to the target user when the vehicle has a backup vehicle requirement.

[0117] The parking location determination unit 10, the start time calculation unit 20, the vehicle standby requirement determination unit 30, and the reminder unit 40 are also used to execute the detailed implementation schemes described in the above method embodiments, which will not be repeated here.

[0118] Figure 6 The hardware structure diagram of the standby vehicle device based on predicted vehicle usage time provided in the embodiment of the present invention is shown below. Figure 6 As shown, it may include: at least one processor 100, at least one communication interface 200, at least one memory 300 and at least one communication bus 400;

[0119] In this embodiment of the invention, the number of processor 100, communication interface 200, memory 300, and communication bus 400 is at least one, and the processor 100, communication interface 200, and memory 300 communicate with each other through communication bus 400; obviously, Figure 6 The communication connections shown for the processor 100, communication interface 200, memory 300, and communication bus 400 are optional.

[0120] Optionally, the communication interface 200 can be an interface of a communication module, such as the interface of a GSM module;

[0121] Processor 100 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0122] The memory 300 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0123] Specifically, processor 100 is used for:

[0124] Get parking location;

[0125] Determine whether the parking location is a frequently parked location, where a frequently parked location refers to a location where the vehicle is parked more than a preset number of times.

[0126] When the parking location is a frequently parked location, obtain the historical start time of the vehicle corresponding to the frequently parked location;

[0127] The vehicle startup time is calculated based on the vehicle's historical startup time.

[0128] Determine whether the difference between the current time and the vehicle start time is less than a preset duration;

[0129] When the difference between the current time and the vehicle start time is less than a preset duration, the current in-vehicle environment parameters are obtained;

[0130] Based on the current in-vehicle environmental parameters, determine whether the vehicle needs a backup vehicle;

[0131] When a vehicle needs to be replaced, a replacement vehicle request is generated and sent to the target user.

[0132] The processor is also used to execute the specific steps disclosed in the other method embodiments described above, which will not be repeated here.

[0133] Corresponding to the above-mentioned device, this application also discloses a vehicle and a server, which can be equipped with the vehicle standby device based on predicted vehicle usage time as described in the above embodiments, and the device can be integrated into the vehicle computer.

[0134] For ease of description, the above system is described by dividing it into various modules based on their functions. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0135] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0136] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0137] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0138] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0139] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle standby method based on predicted vehicle usage time, characterized in that, include: Get parking location; Determine whether the parking location is a frequently parked location, where a frequently parked location refers to a location where the vehicle is parked more than a preset number of times. When the parking location is a frequently parked location, obtain the historical start time of the vehicle corresponding to the frequently parked location; An analytical model is used to predict the vehicle's start-up time. The input data of the analytical model are the vehicle's VIN, the date corresponding to the current time, the day of the week, the date's special characteristics, and the weather of the day. The output data of the analytical model is the vehicle's start-up time. The analytical model is trained using the vehicle's VIN, date, day of the week, date's special characteristics, the weather of the day, the GPS positioning when the vehicle is powered on each time, and the vehicle's start-up time each time. Determine whether the difference between the current time and the vehicle start time is less than a preset duration; When the difference between the current time and the vehicle start time is less than a preset duration, the current in-vehicle environment parameters are obtained; Based on the current in-vehicle environmental parameters, determine whether the vehicle needs a backup vehicle; When a vehicle needs to be available for standby, a standby request is generated and sent to the target user. The vehicle startup time is calculated based on the vehicle's historical startup time, including: Obtain the driving routes and historical driving times corresponding to the frequently stopped locations; Obtain traffic information and predicted travel time for the driving route; Calculate the time difference between the predicted time and the historical time, and then advance the historical vehicle start time along the time axis to the time node corresponding to the time difference as the vehicle start time.

2. The vehicle standby method based on predicted vehicle usage time according to claim 1, characterized in that, Determining whether a parking location is in a frequently parked area includes: Determine whether the parking location is located within a preset frequent parking area, where the frequent parking area is an area where the number of times the user parks the vehicle exceeds a preset number; When the parking location is located within a preset frequent parking area, it indicates that the parking location is a frequent parking location.

3. The vehicle standby method based on predicted vehicle usage time according to claim 1, characterized in that, Based on the current in-vehicle environmental parameters, determine whether the vehicle needs a backup vehicle; Obtain the vehicle interior temperature from the current vehicle interior environment parameters; determine whether the vehicle interior temperature is within a preset temperature range; When the interior temperature is within the preset temperature range, it indicates that the vehicle does not require a backup vehicle; when the interior temperature is not within the preset temperature range, it indicates that the vehicle requires a backup vehicle.

4. The vehicle standby method based on predicted vehicle usage time according to claim 1, characterized in that, When a vehicle requires backup, a backup request is generated and sent to the target user, including: When a vehicle needs to be put on standby, the standby time is calculated based on the current in-vehicle environmental parameters, the target in-vehicle environmental parameters, and the standby operating conditions. The standby operating conditions refer to the working status data of the vehicle system during the standby process. The vehicle system is used to adjust the in-vehicle environmental parameters. The standby time refers to the time it takes for the in-vehicle environmental parameters to reach the target in-vehicle environmental parameters after the vehicle system is started. The reminder notification time is calculated based on the vehicle start time and the vehicle preparation time. The reminder notification time is located before the vehicle start time on the timeline, and the difference between the two is greater than the vehicle preparation time. When the reminder notification time arrives, a vehicle standby request is generated and sent to the target user.

5. The vehicle standby method based on predicted vehicle usage time according to claim 4, characterized in that, The reminder notification time is calculated based on the vehicle start time and the vehicle standby time, including: The time on the timeline that is a first preset duration before the vehicle start time is used as the reminder notification time. The first preset duration is the sum of the vehicle preparation time and the second preset duration, which is a fixed duration.

6. The vehicle standby method based on predicted vehicle usage time according to claim 1, characterized in that, When a vehicle requires a backup vehicle, after generating and sending a backup vehicle request to the target user, the process also includes: When the response result of the target user in response to the vehicle backup request is obtained, it is determined whether the vehicle needs to be backed up based on the response result. When it is necessary to prepare the vehicle, control the vehicle to enter the standby state; When vehicle preparation is detected as complete and the vehicle has not started, a notification message indicating that vehicle preparation is complete is sent to the target user.

7. A vehicle standby device based on predicted vehicle usage time, characterized in that, include: The parking location determination unit is used to obtain the parking location and determine whether the parking location is a frequently parked location; The start-up time calculation unit is used to obtain the historical start-up time of the vehicle corresponding to the frequent parking location when the parking location is a frequent parking location, and to use an analysis model to predict the start-up time of the vehicle. The input data of the analysis model are the vehicle VIN, the date, day of the week, date characteristics, and weather of the day. The output data of the analysis model is the vehicle start-up time. The analysis model is trained by the vehicle VIN, date, day of the week, date characteristics, weather of the day, GPS positioning when the vehicle is powered on each time, and the start-up time of the vehicle each time. The vehicle standby requirement judgment unit is used to determine whether the difference between the current time and the vehicle start time is within a preset range; when the difference between the current time and the vehicle start time is within the preset range, the current in-vehicle environmental parameters are obtained. Based on the current in-vehicle environmental parameters, determine whether the vehicle needs a backup vehicle; The reminder unit is used to generate and send a vehicle standby request to the target user when the vehicle needs to be standby. The vehicle startup time is calculated based on the vehicle's historical startup time, including: Obtain the driving routes and historical driving times corresponding to the frequently stopped locations; Obtain traffic information and predicted travel time for the driving route; Calculate the time difference between the predicted time and the historical time, and then advance the historical vehicle start time along the time axis to the time node corresponding to the time difference as the vehicle start time.

8. A vehicle standby device based on predicted vehicle usage time, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement each step of the vehicle standby method based on predicted vehicle usage time as described in any one of claims 1-6.

9. A vehicle, characterized in that, Includes the backup vehicle device based on predicted vehicle usage time as described in claim 8.

Images