Vehicle request processing method and device

By calculating the braking distance and capacity loss rate of the target vehicle and adjusting the frequency of sending data requests to the server, the balance problem between the request frequency and the accumulation of requests on the server in the vehicle-road collaboration system is solved, and the real-time processing of data requests and the safety of vehicle driving is improved.

CN111866080BActive Publication Date: 2025-05-06TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202010567806.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-06-19
Publication Date
2025-05-06
Estimated Expiration
2040-06-19

AI Technical Summary

Technical Problem

In the field of vehicle-road collaboration, the system has end-to-end delay. Increasing the vehicle-side request frequency can reduce the delay, but due to network transmission delay, the request frequency cannot be increased unlimitedly. Otherwise, a large number of pending data requests will accumulate on the server side, seriously affecting the real-time processing of data requests by the server side.

Method used

By calculating the braking distance of the target vehicle, and based on the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server side that interacts with the target vehicle, the capacity loss rate corresponding to the data request sent by the target vehicle to the server side, and determine whether to reduce the frequency of the data request sent by the target vehicle according to the capacity loss rate and the number of data requests to be processed in the server side.

Benefits of technology

By adjusting the frequency of data requests sent by the target vehicle, the number of data requests pending on the server side is reduced, the timely processing of vehicle requests is ensured, and the real-time processing of vehicle requests is improved, thereby improving the safety of vehicle driving and reducing the occurrence of traffic accidents.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN111866080B_ABST
    Figure CN111866080B_ABST
Patent Text Reader

Abstract

The embodiments of the present application provide a method and device for processing vehicle requests. The vehicle communication method includes: calculating the braking distance of the target vehicle based on the driving parameters of the target vehicle on the target road section; determining the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side according to the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server side interacting with the target vehicle, wherein the loss tolerance rate is used to indicate the probability of tolerating the loss of the response data sent by the server side; determining whether to reduce the frequency of the target vehicle sending data requests according to the loss tolerance rate and the number of pending data requests on the server side. The technical solution of the embodiment of the present application can adjust the frequency of the target vehicle sending data requests, thereby reducing the number of pending data requests on the server side, and improving the real-time processing of vehicle requests.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the technical field of vehicle networking, and more specifically, to a method and device for processing vehicle requests. Background Art

[0002] In the field of vehicle-road collaboration, the system has end-to-end delay. Increasing the request frequency on the vehicle side can reduce the delay, but due to the network transmission delay, the request frequency cannot be increased indefinitely, otherwise a large number of pending data requests will accumulate on the server side, seriously affecting the real-time processing of data requests on the server side. Therefore, how to achieve the optimal balance between increasing the request frequency on the vehicle side and reducing the accumulation of server-side requests is one of the key issues faced by vehicle-road collaboration in reducing end-to-end delay. Summary of the invention

[0003] The embodiments of the present application provide a vehicle communication method and device, which can determine whether to reduce the frequency of data sending by the target vehicle to a certain extent according to the actual situation, thereby reducing the number of pending data requests on the server side, ensuring that the vehicle's requests can be processed in a timely manner, and improving the real-time processing of vehicle requests.

[0004] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0005] According to one aspect of an embodiment of the present application, a method for processing vehicle requests is provided, including: calculating a braking distance of a target vehicle on a target road section based on driving parameters of the target vehicle; determining a packet loss rate corresponding to a data request sent by the target vehicle to the server side according to the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of a server side interacting with the target vehicle, wherein the packet loss rate is used to indicate a probability of tolerating loss of response data sent by the server side; determining whether to reduce the frequency of data requests sent by the target vehicle according to the packet loss rate and the number of data requests to be processed in the server side.

[0006] According to one aspect of an embodiment of the present application, a vehicle request processing device is provided, including: a calculation unit, configured to calculate the braking distance of the target vehicle based on the driving parameters of the target vehicle on the target road section; a first determination unit, configured to determine the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side according to the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server side interacting with the target vehicle, wherein the loss tolerance rate is used to indicate the probability of tolerating the loss of response data sent by the server side; and a second determination unit, configured to determine whether to reduce the frequency of the target vehicle sending data requests according to the loss tolerance rate and the number of data requests to be processed in the server side.

[0007] In some embodiments of the present application, based on the aforementioned scheme, the first determination unit includes: a first calculation subunit, configured to, if the braking distance is less than the safe driving distance of the target section, calculate the loss tolerance corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target section and the packet loss rate of the server side interacting with the target vehicle; a second calculation subunit, configured to, if the braking distance is greater than or equal to the safe driving distance of the target section, calculate the loss tolerance corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target section, the packet loss rate of the server side interacting with the target vehicle, and the ratio of the braking distance to the safe driving distance.

[0008] In some embodiments of the present application, based on the above scheme, the first calculation subunit is configured as follows: if the braking distance is less than the safe driving distance of the target road section, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server is calculated according to the following formula: tolerate :

[0009] p tolerate =1-(1-p accident )(1-p loss )

[0010] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle.

[0011] In some embodiments of the present application, based on the above scheme, the second calculation subunit is configured as follows: if the braking distance is greater than or equal to the safe driving distance of the target road section, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server is calculated according to the following formula: tolerate :

[0012] p tolerate =(1-(1-p accident )(1-p loss ))s / Δs

[0013] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle, s is the safe driving distance of the target road section, and Δs is the braking distance of the target vehicle.

[0014] In some embodiments of the present application, based on the aforementioned scheme, the second determination unit includes: a third calculation subunit, configured to calculate the accumulation rate of the pending data requests in the server side according to the number of pending data requests in the server side; and a determination reduction subunit, configured to determine to reduce the frequency of the target vehicle sending data requests if the loss rate is less than the accumulation rate.

[0015] In some embodiments of the present application, based on the aforementioned scheme, the third computing subunit is configured to: obtain the total number of data requests received by the server end within a preset time period, and the number of data requests that the server end has not responded to within the preset time period; calculate the ratio of the number of unresponded data requests to the total number of received data requests, and obtain the accumulation rate of pending data requests in the server end.

[0016] In some embodiments of the present application, based on the aforementioned scheme, the second determination unit is configured to: when determining to reduce the frequency of the target vehicle sending data requests, send an instruction to reduce the frequency of data requests to the controller of the target vehicle.

[0017] In some embodiments of the present application, based on the aforementioned scheme, the calculation unit is configured to calculate the braking distance of the target vehicle according to the speed, acceleration, maximum braking acceleration of the target vehicle on the target road section, and the reaction time of the driver or vehicle control system.

[0018] In some embodiments of the present application, based on the above solution, the calculation unit is configured to: calculate the braking distance Δs of the target vehicle according to the following formula:

[0019] Δs=(v host +a host Δt) 2 / (2a max )

[0020] Among them, v host is the speed of the target vehicle, a hostis the acceleration of the target vehicle, Δt is the reaction time of the driver or vehicle control system, a max is the maximum braking acceleration.

[0021] In the technical solutions provided in some embodiments of the present application, by calculating the braking distance of the target vehicle, and based on the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server side that interacts with the target vehicle, the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side is determined, and according to the loss tolerance rate and the number of pending data requests on the server side, it is determined whether to reduce the frequency of data sent by the target vehicle. From the above scheme, it can be seen that the embodiments of the present application take into account actual factors such as the historical traffic accident rate, the packet loss rate on the server side, and the driving status of the vehicle in the actual scene, and can determine whether to reduce the frequency of data sent by the target vehicle according to the actual situation, thereby reducing the number of pending data requests on the server side, ensuring that the vehicle's request can be processed in time, and improving the real-time processing of the vehicle request, thereby improving the safety of vehicle driving and reducing the occurrence of traffic accidents.

[0022] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0024] Figure 1 A schematic diagram showing an application environment in which the technical solution of the embodiment of the present application can be applied;

[0025] Figure 2 A flowchart showing a method for processing a vehicle request according to an embodiment of the present application is shown;

[0026] Figure 3 A flowchart showing a method for processing a vehicle request according to an embodiment of the present application is shown;

[0027] Figure 4 A flowchart showing a method for processing a vehicle request according to an embodiment of the present application is shown;

[0028] Figure 5 A flowchart showing a method for processing a vehicle request according to an embodiment of the present application is shown;

[0029] Figure 6 A block diagram of a vehicle request processing device according to an embodiment of the present application is shown;

[0030] Figure 7 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0031] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more comprehensive and complete and fully convey the concept of example embodiments to those skilled in the art.

[0032] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0033] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0034] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0035] First, the nouns involved in the embodiments of the present application are introduced:

[0036] Vehicle Infrastructure Cooperative Systems (IVICS) is a development direction of Intelligent Transportation Systems (ITS). The IVICS uses advanced wireless communications and new generation Internet technologies to implement all-round dynamic real-time information interaction between vehicles and roads, and conducts active vehicle safety control and road cooperative management based on the collection and integration of dynamic traffic information in all time and space, fully realizing the effective coordination of people, vehicles and roads, ensuring traffic safety, and improving traffic efficiency, thus forming a safe, efficient and environmentally friendly road traffic system.

[0037] The method provided in this application can be applied to Internet of Things systems such as Internet of Vehicles, Intelligent Transportation Systems, Vehicle-Road Collaboration Systems, and Safety Assisted Driving Systems. The method provided in this application can also be applied to products such as automotive cloud, Internet of Vehicles, Vehicle-Road Collaboration, Safety Assisted Driving, and Autonomous Driving. For example, the exemplary embodiments provided below in this application are applied to vehicle-road collaborative systems as an example.

[0038] For easier understanding, see Figure 1 , Figure 1 The diagram shows an architecture of an application environment to which the technical solution of the embodiments of the present application can be applied.

[0039] like Figure 1 As shown, the system architecture 100 may include a roadside device 101, a GPU server 102, a server 103, and a vehicle 104. The roadside device 101 and the GPU server 102 may be connected via a network, the GPU server 102 may be connected to the server 103 via a network, and the vehicle 104 may also communicate with the server 103. The network includes but is not limited to a wireless or wired network, the wired network may be a metropolitan area network, a local area network, a fiber optic network, etc., and the wireless network may be a mobile communication network (e.g., at least one of 2G, 3G, 4G, or 5G) or a wireless fidelity network (Wireless Fidelity, WiFi).

[0040] The roadside equipment 101 (Road Side Unit, RSU) can be used to complete the task of sensing the surrounding environment of the area where the vehicle 104 is located. The roadside equipment 101 is a device installed on the side of the road and has a sensing function. The roadside equipment 101 can be a monitoring camera, a roadside radar, a roadside sensing unit, a pressure sensor, a temperature sensor, etc. Exemplarily, the roadside equipment 101 can provide road condition information for the vehicle-road cooperative system. The road condition information includes at least one of the real-time status information of traffic lights, traffic signs, vehicle distance information, road video information, vehicle pictures, vehicle license plates, vehicle driving status, and real-time road condition information. For example, the road condition information can be, traffic signs: speed limit signs, instruction signs; vehicle license plates: vehicle license plates are identified according to monitoring cameras; vehicle driving status: a vehicle is driving from east to west at a speed of 1 kilometer per hour; real-time road condition information: there are too many vehicles on a certain road section and the driving speed is too slow, which is a congested road section.

[0041] The GPU server 102 is a fast, stable, and flexible computing server based on GPU (Graphics Processing Unit) that is applied to various scenarios such as video encoding and decoding, deep learning, and scientific computing. The GPU server 102 can analyze information such as videos detected by the roadside device 101.

[0042] The server 103 is any server with data processing and data storage functions. The server 103 may be a cloud server, which can provide simple and efficient computing services with elastically scalable processing capabilities. The cloud server may be, but is not limited to, an edge cloud server, which can provide a cloud-based service environment and computing capabilities in a wireless access network close to the vehicle 104. It may be an independent server, or other hardware modules or software modules that can provide edge computing services or process edge computing services.

[0043] The vehicle 104 is provided with an on-board unit (OBU), which can send data requests to the edge / cloud server 103 through vehicle wireless communication technology. The on-board unit mainly realizes data transmission with the edge / cloud server based on V2X technology (vehicle to X; vehicle-to-the-outside information exchange). A processing module can be provided inside the on-board unit.

[0044] V2X (Vehicle to X) communication technology is a key technology for future intelligent transportation systems. It enables real-time communication between vehicles, vehicles and base stations, base stations and base stations, and vehicles and roadside equipment, thereby obtaining a series of vehicle-road traffic information related to vehicle-road collaboration, such as real-time road conditions, road information, and pedestrian information, thereby improving driving safety, reducing congestion, improving traffic efficiency, and providing in-vehicle entertainment information.

[0045] It should be understood that Figure 1 The number of roadside devices 101, GPU servers 102, servers 103, and vehicles 104 in the figure is only for illustration. According to the implementation requirements, there may be any number of roadside devices 101, GPU servers 102, servers 103, and vehicles 104. For example, the GPU server 102 or the server 103 may be a server cluster composed of multiple servers.

[0046] like Figure 1 As shown, in the field of vehicle-road collaboration, the system has an end-to-end delay T, where T = A1 + X1 + A2 + X2 + A3 + A4 + X4 + A5, X1 represents the network delay from the roadside device 101 to the GPU server 102, X2 represents the network delay from the GPU server 102 to the server 103, X3 represents the uplink network delay from the vehicle 104 to the server 103, X4 represents the downlink network delay from the server 103 to the vehicle 104, A1 represents the event sensing time, A2 represents a frame of data processing event, A3 represents the request delay of the vehicle 104, A4 represents the algorithm processing event, and A5 represents the UI processing time, where A1 = 90ms, A2 = 50-70ms, and A4 < 10ms.

[0047] In the field of vehicle-road collaboration, although increasing the request frequency on the vehicle side can reduce latency, it is limited by network transmission latency (X3+X4 time) and cannot be increased indefinitely, otherwise there will be requests piled up on the server side. How to achieve the best balance between increasing the request frequency on the vehicle side and reducing the request pile-up on the server side is one of the key issues facing vehicle-road collaboration in reducing end-to-end latency.

[0048] The technical solution of the embodiment of the present application can solve this problem. The embodiment of the present application can determine whether to reduce the frequency of data sent by the target vehicle based on actual factors such as the historical traffic accident rate, the packet loss rate on the server side, the vehicle driving status, etc. in the actual scenario, so as to achieve a balance between the vehicle request frequency and the server-side request accumulation, thereby ensuring that the vehicle's request can be processed in a timely manner, improving the real-time processing of the vehicle request, thereby improving the safety of vehicle driving and reducing the occurrence of traffic accidents.

[0049] The vehicle request processing method provided in the embodiment of the present application may be executed by the server 103, and accordingly, the vehicle request processing device may be disposed in the server 103. Alternatively, the vehicle request processing method provided in the embodiment of the present application may also be executed by an on-board unit deployed in the vehicle 104, and accordingly, the vehicle request processing device may be disposed in the on-board unit of the vehicle 104.

[0050] In one embodiment of the present application, vehicle 104 is a target vehicle on a target road section. Server 103 can calculate the braking distance of vehicle 104 based on the driving parameters of vehicle 104. After calculating the braking distance of vehicle 104, the loss tolerance rate corresponding to the data request sent by vehicle 104 to server 103 can be determined based on the braking distance of vehicle 104, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of server 103. The loss tolerance rate is used to indicate the probability that vehicle 104 can tolerate the loss of response data sent by server 103. After determining the loss tolerance rate of vehicle 104, server 103 can determine whether vehicle 104 needs to reduce the frequency of sending data requests based on the loss tolerance rate and the number of data requests to be processed in the cloud server.

[0051] In one embodiment of the present application, if the server 103 can calculate the accumulation rate of the pending data requests based on the number of pending data requests, in one embodiment, the accumulation rate can be calculated based on the ratio of the number of data requests that the server 103 has not responded to within a preset time period to the total number of data requests received by the server 103 within the preset time period. After calculating the accumulation rate of the pending data requests, if the server 103 determines that the loss rate is less than the accumulation rate, it can determine to reduce the frequency of the vehicle 104 sending data requests.

[0052] The implementation details of the technical solution of the embodiment of the present application are described in detail below:

[0053] Figure 2 A flowchart showing a method for processing a vehicle request according to an embodiment of the present application is shown, referring to Figure 2 As shown, the method for processing the vehicle request includes:

[0054] Step S210, calculating a braking distance of the target vehicle based on the driving parameters of the target vehicle on the target road section;

[0055] Step S220, determining a packet loss rate corresponding to a data request sent by the target vehicle to the server according to the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server interacting with the target vehicle, wherein the packet loss rate is used to indicate a probability of tolerating the loss of response data sent by the server;

[0056] Step S230: Determine whether to reduce the frequency of the target vehicle sending data requests according to the data loss tolerance rate and the number of data requests to be processed in the server.

[0057] These steps are described in detail below.

[0058] In step S210, a braking distance of the target vehicle is calculated based on the driving parameters of the target vehicle on the target road section.

[0059] Specifically, the target road section includes a target vehicle. The braking distance of the target vehicle refers to the distance the target vehicle travels from a current state to a complete stop. The driving parameters of the target vehicle may be any parameter information that can describe the driving state, for example, the vehicle's driving speed, driving acceleration, and driving direction angle.

[0060] The execution entity may obtain the driving parameters of the target vehicle on the target road section, and calculate the braking distance of the target vehicle based on the driving parameters.

[0061] In one embodiment, the driving parameters acquired by the execution subject may be the speed, acceleration, maximum braking acceleration, and reaction time of the driver or control system of the target vehicle, and the braking distance of the target vehicle is calculated based on these driving parameters. In this embodiment, step S210 specifically includes:

[0062] The braking distance of the target vehicle is calculated based on the speed, acceleration, maximum braking acceleration of the target vehicle on the target road section, and the reaction time of the driver or the vehicle control system.

[0063] It should be noted that, although the maximum braking acceleration is related to the specific road friction, it can be considered that the road friction is almost unchanged within a period of time, so the maximum braking acceleration in this embodiment does not take into account the change of the road friction.

[0064] In one embodiment, the braking distance Δs of the target vehicle may be calculated according to the following formula 1:

[0065] Δs=(v host +a host Δt) 2 / (2a max ) Formula 1

[0066] Among them, v host is the speed of the target vehicle, a host is the acceleration of the target vehicle, Δt is the reaction time of the driver or vehicle control system, and a max is the maximum braking acceleration.

[0067] In step S220, based on the braking distance, the safe driving distance of the target road section, the historical traffic accident rate of the target road section, and the packet loss rate of the server that interacts with the target vehicle, the packet loss rate corresponding to the data request sent by the target vehicle to the server is determined. The packet loss rate is used to indicate the probability of tolerating the loss of response data sent by the server.

[0068] Because there are regulations on the safe driving distance for vehicles on different types of road sections, the safe driving distance for the target section can be directly obtained according to the section type of the target section. The section types may include expressway sections, first-level sections, second-level sections, third-level sections, fourth-level sections, etc. For example, the safe driving distance for vehicles on expressway sections is 150 meters.

[0069] In addition, the executing entity can also obtain the historical traffic accident rate of the target road section from the traffic management department, that is, the probability of a traffic accident occurring on the target road section.

[0070] In addition, the execution entity can also count the packet loss rate on the server side. The packet loss rate can be counted in the following way: after the server side responds to the data request of the target vehicle, if the server side does not receive a confirmation response from the target vehicle within a preset time, then it is considered that the packet has been lost. The packet loss rate is the total number of packet losses on the server side divided by the total number of times the server side responds to data requests.

[0071] After obtaining parameters such as braking distance, safe driving distance, historical traffic accident rate and packet loss rate, the execution entity can calculate the packet loss rate corresponding to the data request sent by the target vehicle to the server based on these parameters.

[0072] It should be explained that the loss tolerance rate is used to indicate the probability of tolerating the loss of response data sent by the server. Response data loss may be that the target vehicle does not receive the response data from the server. At the same time, if the target vehicle does not receive the response data from the server within a preset time period, but receives the response data from the server after the preset time period, it can also be considered as response data loss.

[0073] It is understandable that the purpose of the target vehicle making a data request to the server is to obtain response data, so that the target vehicle can avoid traffic accidents and improve driving safety based on the obtained response data. The target vehicle can tolerate the loss of response data within a range less than the tolerance loss rate, because the loss of response data may not affect the safe driving of the target vehicle. However, when the probability of response data loss is greater than or equal to the tolerance loss rate, it must be a situation of response data loss that the target vehicle cannot tolerate, because the loss of response data at this time is very likely to affect the safe driving of the target vehicle and even cause a traffic accident.

[0074] In step S230, it is determined whether to reduce the frequency of the target vehicle sending data requests according to the data loss tolerance rate and the number of data requests to be processed in the server.

[0075] In the relevant existing technology, the vehicle generally initiates data requests to the server at a fixed frequency. If the server does not respond or fails to respond, the vehicle will repeat the data request. However, if the vehicle repeatedly initiates data requests, the number of pending data requests on the server may continue to increase. The increase in the number of pending data requests will not only increase the processing load on the server, but also affect the timeliness of data request processing, causing data request delays and losses. Therefore, it is very necessary to balance the relationship between the frequency of the vehicle sending data requests to the server and the number of pending requests on the server.

[0076] Specifically in this step, the execution entity can determine whether to reduce the frequency of the target vehicle sending data requests based on the loss tolerance rate and the number of pending data requests on the server side, so that the request frequency of the target vehicle and the number of pending requests on the server side are in a balanced state.

[0077] It is understandable that the more pending requests there are on the server side, the worse the real-time performance of the data request will be. The real-time performance of the data request will directly affect the data request and cause data request errors. The loss tolerance is the probability of tolerating the loss of response data sent by the server side, that is, the tolerable data request error. It can be seen that based on the loss tolerance and the number of pending data requests on the server side, it can be determined whether to reduce the frequency of the target vehicle sending data requests, so as to achieve a balance between the request frequency of the target vehicle and the number of pending requests on the server side.

[0078] Based on the technical solution of the above embodiment, by calculating the braking distance of the target vehicle, and based on the braking distance, the safe driving distance of the target section, the historical traffic accident rate of the target section, and the packet loss rate of the server end interacting with the target vehicle, the loss tolerance rate corresponding to the data request sent by the target vehicle to the server end is determined, and according to the loss tolerance rate and the number of pending data requests on the server end, it is determined whether to reduce the frequency of data sent by the target vehicle. The embodiment of the present application takes into account actual factors such as the historical traffic accident rate, the packet loss rate on the server end, and the driving status of the vehicle in actual scenarios, and can determine whether to reduce the frequency of data sent by the target vehicle according to actual conditions, thereby reducing the number of pending data requests on the server end, so that the server end can process vehicle data requests more in real time, ensuring the real-time processing of vehicle requests, thereby improving the safety of vehicle driving and reducing the occurrence of traffic accidents.

[0079] In one embodiment of the present application, the calculation of the loss tolerance rate may be based on a comparison result between the braking distance of the target vehicle and the safe driving distance of the target road section, and different calculation methods may be selected for calculation based on the comparison results of the two, such as Figure 3As shown, step S220 specifically includes steps S2201 and S2202, which are described in detail as follows:

[0080] Step S2201: If the braking distance is less than the safe driving distance of the target road section, the packet loss rate corresponding to the data request sent by the target vehicle to the server is calculated according to the historical traffic accident rate of the target road section and the packet loss rate of the server interacting with the target vehicle.

[0081] The braking distance indicates the driving distance for the target vehicle to stop completely from the current state. If the braking distance is less than the safe driving distance of the target road section, it means that the target vehicle will have enough time to react after receiving the response data from the server. At this time, the data request sent by the target vehicle to the server can have a larger loss tolerance. The loss tolerance can be calculated based on the historical traffic accident rate of the target road section and the packet loss rate of the server.

[0082] In one embodiment, the loss rate p corresponding to the data request sent by the target vehicle to the server can be calculated according to the following formula 2: tolerate :

[0083] p tolerate =1-(1-p accident )(1-p loss ) Formula 2

[0084] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle.

[0085] It should be noted that p accident is the historical traffic accident rate of the target road section, then it can be approximately considered that 1-p accident is the probability that the target vehicle requests data that will not cause a traffic accident, that is, the probability of the response data sent by the server, 1-p loss It can be approximately considered as the non-packet loss rate, so (1-p accident )(1-p loss ) can be roughly considered as the probability that the response data sent by the server will not be lost, and 1-(1-p accident )(1-p loss ) can be expressed as the tolerable probability of loss of response data sent by the server.

[0086] Step S2202: If the braking distance is greater than or equal to the safe driving distance of the target section, the packet loss rate corresponding to the data request sent by the target vehicle to the server is calculated based on the historical traffic accident rate of the target section, the packet loss rate of the server interacting with the target vehicle, and the ratio of the braking distance to the safe driving distance.

[0087] If the braking distance is greater than or equal to the safe driving distance of the target road section, it means that the target vehicle does not have enough time to react after receiving the response data from the server. At this time, the corresponding loss rate of the data request sent by the target vehicle to the server side is smaller. At the same time, because the target vehicle is equally likely to appear anywhere on the target road section, when the target vehicle brakes, the target vehicle is also equally likely to stop anywhere on the target road section. That is, the position of the target vehicle at the end of braking is uniformly distributed in the driving direction of the target vehicle. The greater the difference between the braking distance and the driving safety distance, the less safe it is. Therefore, when the braking distance is greater than or equal to the safe driving distance of the target road section, the loss rate can be calculated based on the historical traffic accident rate of the target road section, the packet loss rate of the server side, and the ratio of the braking distance to the safe driving distance.

[0088] In one embodiment, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server can be calculated according to the following formula 3: tolerate :

[0089] p tolerate =(1-(1-p acciden t)(1-p loss ))s / Δs Formula 3

[0090] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle, s is the safe driving distance of the target road section, and Δs is the braking distance of the target vehicle.

[0091] It should be noted that p accident is the historical traffic accident rate of the target road section, then it can be approximately considered that 1-p accident is the probability that the target vehicle requests data that will not cause a traffic accident, that is, the probability of the response data sent by the server, 1-p loss It can be approximately considered as the non-packet loss rate, so (1-p accident )(1-p loss ) can be roughly considered as the probability that the response data sent by the server will not be lost, and 1-(1-p accident )(1-p loss) can be expressed as the tolerable probability of loss of response data sent by the server. However, if Δs>s, the loss rate should be corrected to s / Δs times the loss rate in the safe case, that is, (1-(1-p accident )(1-p loss ))s / Δs.

[0092] In one embodiment of the present application, the accumulation rate of pending requests on the server side can be calculated based on the number of pending requests on the server side. The accumulation rate can be used to indicate the proportion of the number of pending requests to the number of requests received on the server side. The higher the accumulation rate, the worse the real-time performance of the data request. The real-time performance of the data request directly affects the data request and causes data request errors. The loss tolerance rate is the data request error that the target vehicle can tolerate. Therefore, the accumulation rate on the server side must be less than or equal to the loss tolerance rate in order for the target vehicle to tolerate such a situation. Figure 4 As shown, step S230 specifically includes steps S2301 and S2302, which are described in detail as follows:

[0093] Step S2301: Calculate the accumulation rate of the data requests to be processed in the server according to the number of the data requests to be processed in the server.

[0094] Specifically, pending data requests refer to data requests that have not been responded to by the server, that is, data requests that have not returned response data to the data requester. These pending data requests can be understood as being accumulated on the server. Therefore, the accumulation rate of pending data requests can be calculated based on the number of pending data requests on the server.

[0095] In one embodiment, the method for calculating the accumulation rate of pending data requests can be real-time detection and calculation, that is, detecting the number of unprocessed data requests on the server side at the current moment, and the sum of processed data requests and unprocessed data requests at the current moment, then the accumulation rate of pending data requests can be obtained = the number of unprocessed data requests at the current moment / the sum of processed data requests and unprocessed data requests at the current moment.

[0096] In another embodiment, the method for calculating the accumulation rate of pending data requests may also be to detect and calculate within a preset time period, such as Figure 5 As shown, step S2301 specifically includes steps S23011 to S23012, which are described in detail as follows:

[0097] Step S23011, obtaining the total number of data requests received by the server within a preset time period, and the number of data requests not responded to by the server within the preset time period.

[0098] The preset time period may be any preset time period, for example, the preset time period is 1 minute, and the total number of data requests received by the server within the preset time period and the number of data requests not responded to by the server within the preset time period are obtained.

[0099] Step S23012: Calculate the ratio of the number of unresponded data requests to the total number of received data requests to obtain the accumulation rate of pending data requests in the server.

[0100] After obtaining the number of unresponded data requests and the total number of received data requests, the ratio of the number of unresponded data requests to the total number of received data requests may be calculated, thereby obtaining an accumulation rate of pending data requests on the server side.

[0101] Continue to see Figure 4 , step S2302, if the loss tolerance rate is less than the accumulation rate, determine to reduce the frequency of the target vehicle sending data requests.

[0102] The accumulation rate can be used to indicate the proportion of pending requests. The higher the proportion of pending data requests, that is, the higher the accumulation rate of pending data requests on the server side, the worse the real-time performance of data requests. The real-time performance of data requests directly affects data requests and causes data request errors. Therefore, the worse the real-time performance of data requests is, the larger the data request errors are. The loss tolerance rate is used to indicate the data request errors that the target vehicle can tolerate. That is to say, the accumulation rate of pending data requests on the server side must be less than or equal to the loss tolerance rate to be tolerated by the target vehicle. When the accumulation rate is greater than the loss tolerance rate, it means that the accumulation rate of pending data requests on the server side is too high and the data request errors are too large, which exceeds the tolerable range. Therefore, it can be determined to reduce the frequency of data requests sent by the target vehicle, so that the accumulation rate of pending data requests on the server side can be controlled to avoid the accumulation rate being too high beyond the tolerable range.

[0103] On the contrary, if the accumulation rate is less than or equal to the loss rate, it is within a tolerable range. Therefore, it can be determined not to reduce the frequency of the target vehicle sending data requests.

[0104] In one embodiment of the present application, the method for processing a vehicle request further includes:

[0105] In the case where it is determined to reduce the frequency of the data request sent by the target vehicle, an instruction to reduce the frequency of the data request is sent to a controller of the target vehicle.

[0106] Specifically, when the accumulation rate is greater than the loss tolerance rate, it means that the accumulation rate of pending data requests on the server side is too high and the data request error is too large, exceeding the tolerable range. Therefore, it can be determined to reduce the frequency of data requests sent by the target vehicle. When it is determined to reduce the frequency of data requests sent by the target vehicle, an instruction to reduce the frequency of data requests can be sent to the controller of the target vehicle, so that the controller of the target vehicle can control the frequency of sending data requests until the accumulation rate of pending data requests on the server side is less than or equal to the loss tolerance rate.

[0107] The technical solution of the embodiment of the present application takes into account actual factors such as the historical traffic accident rate, the packet loss rate on the server side, the driving status of the vehicle, etc. in actual scenarios. The technical solution is based on the tolerable loss rate of the response data sent by the server side and the accumulation rate of pending requests on the server side. When the accumulation rate is greater than the loss rate, it is determined to reduce the frequency of the target vehicle sending data requests. When the frequency of the target vehicle sending data requests is reduced, the number of pending data requests on the server side is also reduced accordingly, thereby reducing the accumulation rate. The accumulation rate of pending data requests on the server side is reduced, thereby correspondingly improving the real-time processing of vehicle requests.

[0108] In order to verify the effect brought by the embodiment of the present application, the ratio of the accumulation rate of pending data requests on the server side when the technical solution of the embodiment of the present application is used to process vehicle requests to the accumulation rate of pending data requests on the server side when the prior art is used to process vehicle requests is further statistically analyzed through experiments. As shown in Table 1, a total of 10 experiments were conducted. The experimental results show that the accumulation rate of pending data requests on the server side in the prior art is higher than the accumulation rate of pending data requests on the server side in the embodiment of the present application, which further illustrates that the technical solution of the embodiment of the present application can adjust the frequency of data requests sent by the target vehicle according to actual conditions, thereby reducing the number of pending data requests on the server side, that is, reducing the accumulation rate of pending requests on the server side, thereby improving the real-time processing of vehicle requests to a certain extent.

[0109]

[0110]

[0111] Table 1

[0112] The following describes an apparatus embodiment of the present application, which can be used to execute the vehicle communication method in the above-mentioned embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the above-mentioned embodiment of the vehicle communication method of the present application.

[0113] Figure 6 A block diagram of a vehicle communication device according to an embodiment of the present application is shown, referring to Figure 6 As shown, a vehicle request processing device 600 according to an embodiment of the present application includes: a calculation unit 602 , a first determination unit 604 and a second determination unit 606 .

[0114] Among them, the calculation unit 602 is configured to calculate the braking distance of the target vehicle based on the driving parameters of the target vehicle on the target section; the first determination unit 604 is configured to determine the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side according to the braking distance, the safe driving distance of the target section, the historical traffic accident rate of the target section, and the packet loss rate of the server side interacting with the target vehicle, and the loss tolerance rate is used to indicate the probability of tolerating the loss of response data sent by the server side; the second determination unit 608 is configured to determine whether to reduce the frequency of data requests sent by the target vehicle according to the loss tolerance rate and the number of data requests to be processed in the server side.

[0115] In some embodiments of the present application, the first determination unit 602 includes: a first calculation subunit, configured to calculate the loss tolerance corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target section and the packet loss rate of the server side interacting with the target vehicle if the braking distance is less than the safe driving distance of the target section; a second calculation subunit, configured to calculate the loss tolerance corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target section, the packet loss rate of the server side interacting with the target vehicle, and the ratio of the braking distance to the safe driving distance if the braking distance is greater than or equal to the safe driving distance of the target section.

[0116] In some embodiments of the present application, the first calculation subunit is configured to: if the braking distance is less than the safe driving distance of the target road section, calculate the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formula: tolerate :

[0117] p tolerate =1-(1-p accident )(1-p loss )

[0118] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle.

[0119] In some embodiments of the present application, the second calculation subunit is configured to: if the braking distance is greater than or equal to the safe driving distance of the target road section, calculate the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formula: tolerate :

[0120] p tolerate =(1-(1-p accident )(1-p loss ))s / Δs

[0121] Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle, s is the safe driving distance of the target road section, and Δs is the braking distance of the target vehicle.

[0122] In some embodiments of the present application, the second determination unit 606 includes: a third calculation subunit, configured to calculate the accumulation rate of the pending data requests in the server side according to the number of pending data requests in the server side; and a determination reduction subunit, configured to determine to reduce the frequency of the target vehicle sending data requests if the loss rate is less than the accumulation rate.

[0123] In some embodiments of the present application, the third computing subunit is configured to: obtain the total number of data requests received by the server within a preset time period, and the number of data requests not responded to by the server within the preset time period; calculate the ratio of the number of unresponded data requests to the total number of received data requests, and obtain the accumulation rate of pending data requests in the server.

[0124] In some embodiments of the present application, the second determination unit 606 is configured to: in the case of determining to reduce the frequency of the target vehicle sending data requests, send an instruction to reduce the frequency of data requests to the controller of the target vehicle.

[0125] In some embodiments of the present application, the calculation unit 602 is configured to calculate the braking distance of the target vehicle based on the speed, acceleration, maximum braking acceleration of the target vehicle on the target road section, and the reaction time of the driver or the vehicle control system.

[0126] In some embodiments of the present application, the calculation unit 602 is configured to calculate the braking distance Δs of the target vehicle according to the following formula:

[0127] Δs=(v host +a host Δt) 2 / (2a max )

[0128] Among them, v host is the speed of the target vehicle, a host is the acceleration of the target vehicle, Δt is the reaction time of the driver or vehicle control system, a max is the maximum braking acceleration.

[0129] Figure 7 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0130] It should be noted that Figure 7 The computer system 700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0131] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 702 or the program loaded from the storage part 708 to the random access memory (RAM) 703, such as executing the method described in the above embodiment. In the RAM 703, various programs and data required for system operation are also stored. The CPU 701, ROM 702 and RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0132] The following components are connected to the I / O interface 1705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that a computer program read therefrom is installed into the storage section 708 as needed.

[0133] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 709, and / or installed from a removable medium 711. When the computer program is executed by a central processing unit (CPU) 701, various functions defined in the system of the present application are executed.

[0134] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0135] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0136] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0137] As another aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by an electronic device, the electronic device implements the method described in the above embodiment.

[0138] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0139] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation methods of the present application.

[0140] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0141] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for processing a vehicle request, characterized in that: The method comprises: Calculating a braking distance of the target vehicle based on the speed, acceleration, maximum braking acceleration of the target vehicle on the target road section, and a reaction time of a driver or a vehicle control system; If the braking distance is less than the safe driving distance of the target road section, then the loss tolerance rate corresponding to the data request sent by the target vehicle to the server is calculated according to the historical traffic accident rate of the target road section and the packet loss rate of the server interacting with the target vehicle; if the braking distance is greater than or equal to the safe driving distance of the target road section, then the loss tolerance rate corresponding to the data request sent by the target vehicle to the server is calculated according to the historical traffic accident rate of the target road section, the packet loss rate of the server interacting with the target vehicle, and the ratio of the braking distance to the safe driving distance. The loss tolerance rate is used to indicate the probability of tolerating the loss of the response data sent by the server; Calculating the accumulation rate of the data requests to be processed in the server according to the number of the data requests to be processed in the server; If the loss tolerance rate is less than the accumulation rate, it is determined to reduce the frequency of the target vehicle sending data requests; if the loss tolerance rate is greater than or equal to the accumulation rate, the frequency of the target vehicle sending data requests is kept unchanged.

2. The method according to claim 1, characterized in that If the braking distance is less than the safe driving distance of the target road section, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server is calculated according to the following formula: tolerate : p tolerate =1-(1-p accident )(1-p loss ) Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle.

3. The method according to claim 1, characterized in that If the braking distance is greater than or equal to the safe driving distance of the target road section, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server is calculated according to the following formula: tolerate : p tolerate =(1-(1-p accident )(1-p loss ))s / Δs Among them, p accident is the historical traffic accident rate of the target road section, p loss is the packet loss rate of the server interacting with the target vehicle, s is the safe driving distance of the target road section, and Δs is the braking distance of the target vehicle.

4. The method according to claim 1, characterized in that Calculating the accumulation rate of the data requests to be processed in the server according to the number of the data requests to be processed in the server includes: Obtaining the total number of data requests received by the server within a preset time period, and the number of data requests not responded to by the server within the preset time period; The ratio of the number of unresponded data requests to the total number of received data requests is calculated to obtain an accumulation rate of pending data requests in the server.

5. The method according to claim 1, characterized in that The method further comprises: In the case where it is determined to reduce the frequency of the data request sent by the target vehicle, an instruction to reduce the frequency of the data request is sent to a controller of the target vehicle.

6. The method according to claim 1, characterized in that The braking distance Δs of the target vehicle is calculated according to the following formula: Δs=(v host +a host Δt) 2 / (2a max ) Among them, v host is the speed of the target vehicle, a host is the acceleration of the target vehicle, Δt is the reaction time of the driver or vehicle control system, a max is the maximum braking acceleration.

7. A vehicle request processing device, characterized in that: The device comprises: a calculation unit configured to calculate a braking distance of the target vehicle based on a speed, an acceleration, a maximum braking acceleration of the target vehicle on the target road section, and a reaction time of a driver or a vehicle control system; The first determination unit is configured to calculate the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target road section and the packet loss rate of the server side interacting with the target vehicle if the braking distance is less than the safe driving distance of the target road section; if the braking distance is greater than or equal to the safe driving distance of the target road section, calculate the loss tolerance rate corresponding to the data request sent by the target vehicle to the server side according to the historical traffic accident rate of the target road section, the packet loss rate of the server side interacting with the target vehicle, and the ratio of the braking distance to the safe driving distance, wherein the loss tolerance rate is used to indicate the probability of tolerating the loss of the response data sent by the server side; A second determining unit is configured to calculate an accumulation rate of the data requests to be processed in the server according to the number of the data requests to be processed in the server; If the loss tolerance rate is less than the accumulation rate, it is determined to reduce the frequency of the target vehicle sending data requests; if the loss tolerance rate is greater than or equal to the accumulation rate, the frequency of the target vehicle sending data requests is kept unchanged.

8. A computer device, characterized in that: include: a memory, wherein a computer program is stored in the memory; A processor, used to load the computer program to implement the vehicle request processing method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the method for processing a vehicle request according to any one of claims 1 to 6.

Citation Information

Patent Citations

  • Information sending frequency optimization method based on vehicle driving situation field model in Internet of Vehicles

    CN110505601A