CN111866080A - Vehicle request processing method and device - Google Patents

Vehicle request processing method and device Download PDF

Info

Publication number
CN111866080A
CN111866080A CN202010567806.4A CN202010567806A CN111866080A CN 111866080 A CN111866080 A CN 111866080A CN 202010567806 A CN202010567806 A CN 202010567806A CN 111866080 A CN111866080 A CN 111866080A
Authority
CN
China
Prior art keywords
target vehicle
rate
vehicle
server
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010567806.4A
Other languages
Chinese (zh)
Inventor
侯琛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010567806.4A priority Critical patent/CN111866080A/en
Publication of CN111866080A publication Critical patent/CN111866080A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G08G1/0129—Traffic data processing for creating historical data or processing based on historical data
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications

Abstract

The embodiment of the application provides a vehicle request processing method and device. The vehicle communication method includes: calculating a braking distance of a target vehicle on a target road section based on a driving parameter of the target vehicle; determining a loss tolerance 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 the server side interacting with the target vehicle, wherein the loss tolerance rate is used for representing the probability of tolerating the loss of response data sent by the server side; and determining whether the frequency of sending data requests by the target vehicle is reduced or not according to the loss tolerance rate and the number of the data requests to be processed in the server side. According to the technical scheme, the frequency of the data requests sent by the target vehicle can be adjusted, the number of the data requests to be processed at the server side is reduced, and the processing real-time performance of the vehicle requests is improved.

Description

Vehicle request processing method and device
Technical Field
The application relates to the technical field of vehicle networking, in particular to a vehicle request processing method and device.
Background
In the field of vehicle-road cooperation, the system has end-to-end delay, the delay can be reduced by increasing the vehicle-end request frequency, but the system is limited by network transmission delay and cannot increase the request frequency without limit, otherwise, a large number of data requests to be processed are accumulated at the server end, and the real-time performance of the server end for processing the data requests is seriously influenced. Therefore, how to obtain the optimal balance between the improvement of the vehicle-end request frequency and the reduction of the server-end request accumulation is one of the key problems facing the cooperative reduction of the vehicle-road from the end-to-end delay.
Disclosure of Invention
The embodiment of the application provides a vehicle communication method and device, so that whether the frequency of data transmission of a target vehicle is reduced or not can be determined at least to a certain extent according to actual conditions, the number of data requests to be processed at a server side is reduced, the requests of the vehicle can be guaranteed to be processed in time, and the processing real-time performance of the vehicle requests is improved.
Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.
According to an aspect of an embodiment of the present application, there is provided a method for processing a vehicle request, including: calculating a braking distance of a target vehicle on a target road section based on a driving parameter of the target vehicle; determining a loss tolerance 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 the server side interacting with the target vehicle, wherein the loss tolerance rate is used for representing the probability of tolerating the loss of response data sent by the server side; and determining whether the frequency of sending data requests by the target vehicle is reduced or not according to the loss tolerance rate and the number of the data requests to be processed in the server side.
According to an aspect of an embodiment of the present application, there is provided a vehicle request processing apparatus including: a calculation unit configured to calculate a braking distance of a target vehicle on a target road segment based on a driving parameter of the target vehicle; a first determining unit, configured to determine, according to the braking distance, the safe driving distance of the target road segment, the historical traffic accident rate of the target road segment, and a packet loss rate of a server interacting with the target vehicle, a capacity loss rate corresponding to a data request sent by the target vehicle to the server, where the capacity loss rate is used to indicate a probability that response data sent by the server can be tolerated to be lost; and the second determining unit is configured to determine whether to reduce the frequency of the data requests sent by the target vehicle according to the loss tolerance and the number of the data requests to be processed in the server side.
In some embodiments of the present application, based on the foregoing scheme, the first determining unit includes: the first calculating subunit is configured to calculate a loss tolerance rate corresponding to a data request sent by the target vehicle to the server according to a historical traffic accident rate of the target road section and a packet loss rate of a server interacting with the target vehicle if the braking distance is smaller than the safe driving distance of the target road section; and the second calculating subunit is configured to calculate, if the braking distance is greater than or equal to the safe driving distance of the target road segment, a loss tolerance rate corresponding to a data request sent by the target vehicle to the server according to a historical traffic accident rate of the target road segment, a packet loss rate of a server interacting with the target vehicle, and a ratio of the braking distance to the safe driving distance.
In some embodiments of the present application, based on the foregoing solution, the first calculating subunit is configured to: if the braking distance is smaller than the safe driving distance of the target road section, calculating the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formulatolerate：
ptolerate＝1-(1-paccident)(1-ploss)
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossThe packet loss rate of the server side interacting with the target vehicle is obtained.
In some embodiments of the present application, based on the foregoing solution, the second calculating subunit is configured to: if the braking distance is greater than or equal to the safe driving distance of the target road section, calculating the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formulatolerate：
ptolerate＝(1-(1-paccident)(1-ploss))s/Δs
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossAnd the packet loss rate of a server side interacting with the target vehicle is s, the safe driving distance of the target road section is s, and the braking distance of the target vehicle is delta s.
In some embodiments of the present application, based on the foregoing scheme, the second determining unit includes: the third computing subunit is configured to compute the accumulation rate of the data requests to be processed in the server side according to the number of the data requests to be processed in the server side; and the determining and reducing subunit is configured to determine to reduce the frequency of the data sending request of the target vehicle if the loss tolerance rate is smaller than the accumulation rate.
In some embodiments of the present application, based on the foregoing scheme, the third calculation subunit is configured to: acquiring the total amount of data requests received by the server end in a preset time period and the quantity of data requests which are not responded by the server end in the preset time period; and calculating the ratio of the number of the unresponsive data requests to the total number of the received data requests to obtain the accumulation rate of the data requests to be processed in the server side.
In some embodiments of the present application, based on the foregoing scheme, the second determining unit is configured to: in a case where it is determined to reduce the frequency at which the target vehicle transmits data requests, an indication to reduce the frequency of data requests is transmitted to a controller of the target vehicle.
In some embodiments of the present application, based on the foregoing solution, the computing unit is configured to: and calculating the braking distance of the target vehicle according to the speed, the acceleration and the maximum braking acceleration of the target vehicle on the target road section and the reaction time of a driver or a vehicle control system.
In some embodiments of the present application, based on the foregoing solution, the computing unit is configured to: calculating a braking distance Δ s of the target vehicle according to the following formula:
Δs＝(vhost+ahostΔt)2/(2amax)
Wherein v ishostIs the speed of the target vehicle, ahostFor the acceleration of the target vehicle, Δ t is the reaction time of the driver or the vehicle control system, amaxThe maximum braking acceleration.
In the technical solutions provided in some embodiments of the present application, a loss tolerance rate corresponding to a data request sent by a target vehicle to a server is determined by calculating a braking distance of the target vehicle, based on the braking distance, a safe driving distance of a target road segment, a historical traffic accident rate of the target road segment, and a packet loss rate of the server interacting with the target vehicle, and whether to reduce a frequency of sending data by the target vehicle is determined according to the loss tolerance rate and a number of data requests to be processed in the server. According to the scheme, the practical factors such as the historical traffic accident rate, the packet loss rate of the server side, the vehicle running state and the like in the practical scene are considered, whether the frequency of data transmission of the target vehicle is reduced or not can be determined according to the practical situation, the number of data requests to be processed of the server side is further reduced, the requests of the vehicle can be processed in time, the processing instantaneity of the vehicle requests is improved, the safety of vehicle driving is improved, and the traffic accidents are reduced.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:
FIG. 1 shows a block diagram of an application environment to which the technical solution of the embodiment of the present application can be applied;
FIG. 2 shows a flow diagram of a method of processing a vehicle request according to one embodiment of the present application;
FIG. 3 shows a flow diagram of a method of processing a vehicle request according to one embodiment of the present application;
FIG. 4 shows a flow diagram of a method of processing a vehicle request according to one embodiment of the present application;
FIG. 5 shows a flow diagram of a method of processing a vehicle request according to one embodiment of the present application;
FIG. 6 shows a block diagram of a processing device of a vehicle request according to an embodiment of the present application;
FIG. 7 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
First, terms referred to in the embodiments of the present application are described:
vehicle Infrastructure Cooperative Systems (IVICS) is a development direction of Intelligent Transportation Systems (ITS). The vehicle-road cooperative system adopts the advanced wireless communication, new generation internet and other technologies, implements vehicle-vehicle and vehicle-road dynamic real-time information interaction in all directions, develops vehicle active safety control and road cooperative management on the basis of full-time dynamic traffic information acquisition and fusion, fully realizes effective cooperation of human and vehicle roads, ensures traffic safety, improves traffic efficiency, and thus forms a safe, efficient and environment-friendly road traffic system.
The method provided by the application can be applied to Internet of things systems such as the Internet of vehicles, intelligent transportation systems, vehicle road cooperative systems and safety driving assistance systems. The method provided by the application can also be applied to products such as automobile cloud, Internet of vehicles, vehicle road coordination, safe auxiliary driving and automatic driving. For example, the following exemplary embodiments provided herein are applied to a vehicle-road coordination system as an example.
For ease of understanding, please refer to fig. 1, which shows a structural diagram of an application environment to which the technical solution of the embodiment of the present application can be applied.
As shown in fig. 1, system architecture 100 may include a roadside device 101, a GPU server 102, a server 103, and a vehicle 104. The roadside apparatus 101 and the GPU server 102 may be connected via a network, the GPU server 102 may be connected via a network to the server 103, 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 network, etc., and the wireless network may be a mobile communication network (e.g., at least one of 2G, or 3G, or 4G, or 5G) or a wireless fidelity (WiFi) network.
Road Side Unit 101 (RSU) may be used to accomplish the task of sensing the environment surrounding the area in which vehicle 104 is located. The roadside apparatus 101 is a device installed at the roadside and having a sensing function, and the roadside apparatus 101 may be a surveillance camera, a roadside radar, a roadside sensing unit, a pressure sensor, a temperature sensor, or the like. For example, the roadside apparatus 101 may provide road condition information for the vehicle-road cooperation system. The road condition information comprises at least one of signal lamp real-time state information, traffic signs, vehicle distance information, road video information, vehicle pictures, vehicle numbers, vehicle running states and road condition real-time information. For example, the traffic information may be, traffic sign: speed limit signs and indication signs; vehicle number plate: identifying the number plate of the vehicle according to the monitoring camera; vehicle driving state: a certain vehicle runs from east to west at the speed of 1 kilometer per hour; real-time road condition information: the road section is a congested road section due to the fact that vehicles on the road section are too many and the running speed is too slow.
The GPU server 102 is a fast, stable, and flexible computing server that is applied to various scenes such as video encoding and decoding, deep learning, and scientific computing based on a GPU (Graphics Processing Unit), and the GPU server 102 may analyze information such as video detected by the roadside device 101.
The server 103 is any server having 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 capability, and the cloud server may be, but is not limited to, an edge cloud server, which can provide a cloud service environment and computing capability in a wireless access network close to the vehicle 104, may be an independent server, or may be another hardware module or software module capable of providing edge computing services or processing edge computing services.
An On Board Unit (OBU) is provided inside the vehicle 104, and the OBU may send a data request to the edge/cloud server 103 through a vehicle wireless communication technology. The vehicle-mounted unit is mainly based on a V2X technology (vehicloet X; information exchange of a vehicle to the outside) to realize data transmission with the edge/cloud server. The processing module can be arranged inside the vehicle-mounted unit.
The V2X (Vehicle to X) communication technology is the key technology of the future intelligent transportation system. The vehicle-mounted road traffic information system enables real-time communication between vehicles, between vehicles and a base station, between the base station and between the vehicles and road side equipment, so that a series of road traffic information such as real-time road conditions, road information and pedestrian information which are related to the cooperation of the vehicles and the road are obtained, driving safety is improved, congestion is reduced, traffic efficiency is improved, vehicle-mounted entertainment information is provided, and the like.
It should be understood that the number of roadside devices 101, GPU servers 102, servers 103, and vehicles 104 in fig. 1 are merely illustrative. There may be any number of roadside devices 101, GPU servers 102, servers 103, and vehicles 104, as desired for implementation. For example, GPU server 102 or server 103 may be a server cluster composed of a plurality of servers.
As shown in fig. 1, in the field of vehicle-road coordination, there is an end-to-end delay T in the system, where T is a1+ X1+ a2+ X2+ A3+ a4+ X4+ A5, X1 represents a network delay from the roadside device 101 to the GPU server 102, X2 represents a network delay from the GPU server 102 to the server 103, X3 represents an uplink network delay from the vehicle 104 to the server 103, X4 represents a downlink network delay from the server 103 to the vehicle 104, a1 represents an event exposure time, a2 represents a frame of data processing event, A3 represents a request delay from the vehicle 104, a4 represents an algorithm processing event, A5 represents a UI processing time, where a1 is 90ms, a2 is 50-70ms, and a4 is less than 10 ms.
In the field of vehicle-road cooperation, although the delay can be reduced by increasing the request frequency of the vehicle end, the delay is limited by network transmission delay (X3+ X4 time), the request frequency cannot be increased without limit, otherwise, the request is accumulated at the server end. How to obtain the optimal balance between the improvement of the vehicle-end request frequency and the reduction of the server-end request accumulation is one of the key problems facing the cooperative reduction of the vehicle road and the end-to-end delay.
According to the technical scheme, whether the frequency of data transmission of the target vehicle is reduced or not can be determined according to actual factors such as historical traffic accident rate, server-side packet loss rate and vehicle running state in an actual scene, so that balance is obtained between vehicle request frequency and server-side request accumulation, the vehicle request can be timely processed, the processing real-time performance of the vehicle request is improved, the vehicle driving safety is improved, and traffic accidents are reduced.
The processing method of the vehicle request provided by the embodiment of the application can be executed by the server 103, and accordingly, a processing device of the vehicle request can be arranged in the server 103. Or the processing method of the vehicle request provided by the embodiment of the present application may also be executed by an on-board unit disposed in the vehicle 104, and accordingly, the processing device of the vehicle request may be provided in the on-board unit of the vehicle 104.
In an embodiment of the application, the vehicle 104 is a target vehicle on a target road segment, the server 103 may calculate a braking distance of the vehicle 104 based on the driving parameters of the vehicle 104, after the braking distance of the vehicle 104 is calculated, a loss tolerance rate corresponding to a data request sent by the vehicle 104 to the server 103 may be determined according to the braking distance of the vehicle 104, a safe driving distance of the target road segment, a historical traffic accident rate of the target road segment, and a packet loss rate of the server 103, the loss tolerance rate being used to indicate a probability that the vehicle 104 can tolerate the loss of response data sent by the server 103, and after the loss tolerance rate of the vehicle 104 is determined, the server 103 may determine whether the vehicle 104 needs to reduce the frequency of sending the data request based on the loss tolerance rate and the number of data requests to be processed in the cloud server.
In an embodiment of the present application, if the server 103 may calculate a stacking rate of the data requests to be processed according to the number of the data requests to be processed, in an embodiment, the stacking rate may be calculated according to a ratio of an amount of data requests that the server 103 does not respond to in a preset time period to a total amount of data requests that the server 103 receives in the preset time period, and after the stacking rate of the data requests to be processed is calculated, if the server 103 determines that the tolerance loss rate is smaller than the stacking rate, it may be determined that the frequency of the data requests sent by the vehicle 104 is reduced.
The implementation details of the technical solution of the embodiment of the present application are set forth in detail below:
fig. 2 shows a flow chart of a processing method of a vehicle request according to an embodiment of the present application, which, referring to fig. 2, comprises:
step S210, calculating the braking distance of a target vehicle on a target road section based on the driving parameters of the target vehicle;
step S220, determining a capacity 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 the server side interacting with the target vehicle, wherein the capacity loss rate is used for representing the probability of tolerating the loss of response data sent by the server side;
step S230, determining whether the frequency of sending data requests by the target vehicle is reduced or not according to the loss tolerance and the number of data requests to be processed in the server side.
These steps are described in detail below.
In step S210, a braking distance of a target vehicle on a target link is calculated based on a driving parameter of the target vehicle.
Specifically, the target road segment includes the target vehicle, the braking distance of the target vehicle refers to the running distance of the target vehicle from the current state to the complete stop, and the running parameter of the target vehicle may be any parameter information capable of describing the running state, for example, the running speed, the running acceleration, and the running direction angle of the vehicle.
The execution subject 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.
In one embodiment, the running parameters acquired by the execution subject may be the speed, the acceleration, the maximum braking acceleration of the target vehicle, and the reaction time of the driver or the control system, and the braking distance of the target vehicle is calculated based on the running parameters, in which step S210 specifically includes:
and calculating the braking distance of the target vehicle according to the speed, the acceleration and the maximum braking acceleration of the target vehicle on the target road section and the reaction time of a driver or a vehicle control system.
It should be noted that although the maximum braking acceleration is related to the specific road friction force, the road friction force may be considered to be almost constant for a period of time, so the maximum braking acceleration in this embodiment does not take into account the change of the road friction force.
In one embodiment, the braking distance Δ s of the target vehicle may be calculated according to the following formula one:
Δs＝(vhost+ahostΔt)2/(2amax) Formula one
Wherein v ishostIs the speed of the target vehicle, ahostAcceleration of the target vehicle, Δ t is the reaction time of the driver or the vehicle control system, amaxThe maximum braking acceleration.
In step S220, determining a loss tolerance 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 segment, the historical traffic accident rate of the target road segment, and a packet loss rate of a server interacting with the target vehicle, where the loss tolerance rate is used to indicate a probability that the loss of response data sent by the server can be tolerated.
Since the vehicle driving safety distance for different types of road segments is specified, the safety driving distance for the target road segment can be directly obtained according to the type of the target road segment, which may include a highway segment, a first-level road segment, a second-level road segment, a third-level road segment, a fourth-level road segment, etc., for example, the vehicle driving safety distance for the highway segment is 150 meters.
In addition, the executive body can also acquire the historical traffic accident rate of the target road section from the traffic management department, namely the probability of traffic accidents occurring on the target road section.
In addition, the execution main body may also count a packet loss rate of the server, where the packet loss rate may be counted in a manner that, after the server responds to the data request of the target vehicle, if the server does not receive the acknowledgement of the target vehicle within a preset time, it is considered that the packet has been lost, and the packet loss rate is obtained by dividing a total number of packet losses of the server by a total number of times that the server responds to the data request.
After the parameters of the braking distance, the safe driving distance, the historical traffic accident rate and the packet loss rate are obtained, the execution main body can calculate the packet loss rate corresponding to the data request sent by the target vehicle to the server side based on the parameters.
It should be explained that the loss tolerance rate is used to indicate a probability that the loss of the response data sent by the server can be tolerated, the loss of the response data may be that the target vehicle does not receive the response data of the server, and meanwhile, if the target vehicle does not receive the response data of the server within a preset time period, but receives the response data of the server after the preset time period, the loss of the response data may also be considered as a loss of the response data.
It can be understood that the purpose of the data request from the server side by the target vehicle is to acquire the response data, so that the target vehicle can avoid traffic accidents according to the acquired response data, and the driving safety is improved. The target vehicle can tolerate the loss of the response data within the range smaller than the loss tolerance rate, because the loss of the response data may not affect the safe driving of the target vehicle, however, when the probability of the loss of the response data is larger than or equal to the loss tolerance rate, the situation that the response data which cannot be tolerated by the target vehicle is lost is inevitable, because the loss of the response data greatly affects the safe driving of the target vehicle, and even a traffic accident occurs.
In step S230, it is determined whether to reduce the frequency of data requests sent by the target vehicle according to the loss tolerance and the number of data requests to be processed in the server.
In the related art, a vehicle generally initiates data requests to a server at a fixed frequency, and if the server fails to respond or fails to respond, the vehicle will repeat the data requests, however, if the vehicle repeatedly initiates the data requests, the number of data requests to be processed by the server may be continuously increased, and the increase in the number of data requests to be processed not only increases the processing load of the server, but also affects the timeliness of data request processing, resulting in delay and loss of the data requests, and therefore, it is necessary to balance the relationship between the frequency of sending the data requests to the server by the vehicle and the number of the data requests to be processed by the server.
Specifically, in this step, the execution subject may determine whether to reduce the frequency of sending the data request by the target vehicle according to the loss tolerance and the number of the data requests to be processed in the server, so that both the request frequency of the target vehicle and the number of the data requests to be processed in the server are in a balanced state.
It can be understood that, the larger the number of the requests to be processed in the server, the worse the real-time performance of the data request, the real-time performance of the data request directly affects the data request and brings data request errors, and the tolerance rate is the probability that the response data sent by the server is lost, that is, the tolerable data request errors.
Based on the technical scheme of the embodiment, the capacity loss rate corresponding to the data request sent by the target vehicle to the server side is determined by calculating the braking distance of the target vehicle, 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 interacting with the target vehicle, and whether the frequency of sending data by the target vehicle is reduced is determined according to the capacity loss rate and the number of data requests to be processed in the server side. According to the embodiment of the application, actual factors such as historical traffic accident rate, server-side packet loss rate and vehicle driving state in an actual scene are considered, whether the frequency of data transmission of a target vehicle is reduced or not can be determined according to actual conditions, and then the number of data requests to be processed at the server side is reduced, so that the server side can process the vehicle data requests in real time, the processing real-time performance of the vehicle requests is guaranteed, the safety of vehicle driving is improved, and traffic accidents are reduced.
In an embodiment of the present application, the calculation of the loss tolerance rate may be performed by selecting different calculation methods according to a comparison result between a braking distance of the target vehicle and a safe driving distance of the target road segment, as shown in fig. 3, and the step S220 specifically includes steps S2201 to S2202, which are described in detail as follows:
step S2201, if the braking distance is smaller than the safe driving distance of the target road section, calculating a loss tolerance rate corresponding to a 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.
The braking distance represents the running distance of the target vehicle stopping completely from the current state, if the braking distance is smaller than the safe driving distance of the target road section, it indicates that the target vehicle has enough time to react after receiving the response data of the server, at this time, the loss tolerance rate corresponding to the data request sent by the target vehicle to the server end can be larger, and the loss tolerance rate can be calculated according to the historical traffic accident rate of the target road section and the packet loss rate of the server end.
In one embodiment, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server side can be calculated according to the following formula twotolerate：
ptolerate＝1-(1-paccident)(1-ploss) Formula two
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossThe packet loss rate of the server side interacting with the target vehicle is obtained.
In addition, p isaccidentCalendars for target road sectionsHistory of traffic accident rate, it can be approximately considered as 1-paccidentProbability of data which is required by the target vehicle and does not bring about traffic accidents, namely probability of response data sent by the server side, 1-plossThe non-packet loss rate can be approximately considered, and therefore, (1-p)accident)(1-ploss) The probability that the response data sent by the server will not be lost can be considered approximately, and 1- (1-p)accident)(1-ploss) It can be expressed as a tolerable probability of the loss of the response data sent by the server.
Step 2202, if the braking distance is greater than or equal to the safe driving distance of the target road section, calculating a loss tolerance rate corresponding to a data request sent by the target vehicle to the server according to a historical traffic accident rate of the target road section, a packet loss rate of a server interacting with the target vehicle, and a 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 road section, the condition that the target vehicle does not have enough time to react after receiving the response data of the server is shown, at the moment, the loss rate corresponding to the data request sent by the target vehicle to the server side is smaller, meanwhile, because the target vehicle appears at any place on the target road section with equal probability, at the end of braking of the target vehicle, the target vehicle stops at any place on the target road section with equal probability, namely, the position of the target vehicle at the end of braking is uniformly distributed in the driving direction of the target vehicle, and the larger the difference between the braking distance and the safe driving distance is, the safer the target vehicle is. Therefore, when the braking distance is greater than or equal to the safe driving distance of the target road section, the loss tolerance rate can be calculated according to 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.
In one embodiment, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server side can be calculated according to the following formula threetolerate：
ptolerate＝(1-(1-paccident)(1-ploss) S/Δ s equation three
Wherein p is accidentIs the historical traffic accident rate, p, of the target road sectionlossAnd the packet loss rate of a server side interacting with the target vehicle is s, the safe driving distance of the target road section is s, and the braking distance of the target vehicle is delta s.
In addition, p isaccidentIs the historical traffic accident rate of the target road section, then can be approximately considered as 1-paccidentProbability of data which is required by the target vehicle and does not bring about traffic accidents, namely probability of response data sent by the server side, 1-plossThe non-packet loss rate can be approximately considered, and therefore, (1-p)accident)(1-ploss) The probability that the response data sent by the server will not be lost can be considered approximately, and 1- (1-p)accident)(1-ploss) It can be expressed as the probability of the loss of the server-side transmitted response data, but if Δ s > s, the loss tolerance rate should be corrected to be s/Δ s times of the loss tolerance rate under the security condition, i.e., (1- (1-p) saccident)(1-ploss))s/Δs。
In an embodiment of the present application, according to the number of the requests to be processed in the server, a stacking rate of the requests to be processed in the server may be calculated, where the stacking rate may be used to represent a ratio of the number of the requests to be processed in the number of the requests received by the server, the higher the stacking rate is, the worse the real-time property of the data request is, the real-time property of the data request directly affects the data request and brings a data request error, and the tolerance is a data request error that can be tolerated by the target vehicle, so that the stacking rate of the server must be less than or equal to the tolerance to be tolerated by the target vehicle, as shown in fig. 4, step S230 specifically includes step S2301-step S2302, which is described in detail as follows:
Step S2301, according to the number of the data requests to be processed in the server, calculating the accumulation rate of the data requests to be processed in the server.
Specifically, the pending data requests refer to data requests that are not responded by the server, that is, data requests that do not return response data to the data requester, and these pending data requests may be understood as being accumulated in the server, so that the accumulation rate of the pending data requests may be calculated according to the number of pending data requests in the server.
In an embodiment, the method for calculating the accumulation rate of the pending data requests may be real-time detection and calculation, that is, detecting the number of unprocessed data requests at the server side at the current time, and the sum of the processed data requests and the unprocessed data requests at the current time, so as to obtain the accumulation rate of the pending data requests, which is the number of unprocessed data requests at the current time/the sum of the processed data requests and the unprocessed data requests at the current time.
In another embodiment, the method for calculating the accumulation rate of the data requests to be processed may also be to detect and calculate the accumulation rate within a preset time period, as shown in fig. 5, step S2301 specifically includes step S23011-step S23012, which will be described in detail as follows:
Step S23011, obtaining a total amount of data requests received by the server in a preset time period, and a number of data requests that the server does not respond to in the preset time period.
The preset time period may be any preset time period, for example, the preset time period is 1 minute, and the total amount of data requests received by the server within the preset time period and the number of data requests that the server does not respond within the preset time period are obtained.
Step S23012, calculating a ratio of the number of the unresponsive data requests to the total number of the received data requests, and obtaining a stacking rate of the data requests to be processed in the server.
After obtaining the number of the unresponsive data requests and the total number of the received data requests, a ratio of the number of the unresponsive data requests to the total number of the received data requests may be calculated, so as to obtain a stacking rate of the data requests to be processed in the server side.
Continuing to refer to fig. 4, step S2302 determines to reduce the frequency of data transmission requests of the target vehicle if the loss tolerance is less than the accumulation tolerance.
The accumulation rate can be used to represent the ratio of the number of the to-be-processed requests, the higher the ratio of the to-be-processed data requests is, that is, the higher the accumulation rate of the to-be-processed data requests at the server side is, the worse the real-time performance of the data requests is, the real-time performance of the data requests directly affects the data requests and brings data request errors, therefore, the worse the real-time performance of the data requests is, the larger the data request errors are, and the loss tolerance is used to represent the data request errors that can be tolerated by the target vehicle, that is, the accumulation rate of the to-be-processed data requests at the server side must be less than or equal to the loss tolerance to be tolerated by the target vehicle, when the accumulation rate is greater than the loss tolerance, it is indicated that the accumulation rate of the to-be-processed data requests at the server side is too high, the data request errors are too large and exceed the tolerable scope, therefore, the accumulation rate of the data requests to be processed at the server can be controlled, and the phenomenon that the accumulation rate is too high to exceed the tolerable range is avoided.
On the contrary, if the pile-up rate is smaller than or less than the loss tolerance rate, it is within a tolerable range, and therefore, it can be determined not to reduce the frequency with which the target vehicle transmits the data request.
In one embodiment of the present application, the method for processing a vehicle request further comprises:
in a case where it is determined to reduce the frequency at which the target vehicle transmits data requests, an indication to reduce the frequency of data requests is transmitted to a controller of the target vehicle.
Specifically, when the accumulation rate is greater than the loss tolerance rate, it is indicated that the accumulation rate of the server-side data requests to be processed is too high, the data request error is too large, and exceeds the tolerable range, so that the frequency of sending the data requests by the target vehicle can be determined to be reduced, and in the case of determining to reduce the frequency of sending the data requests by the target vehicle, an instruction for reducing the frequency of sending the 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 the data requests until the accumulation rate of the server-side data requests to be processed is less than or equal to the loss tolerance rate.
According to the technical scheme, actual factors such as historical traffic accident rate, server-side packet loss rate and vehicle driving state in an actual scene are considered, the loss tolerance rate indicating that response data transmitted by a server side can be tolerated is calculated to serve as the accumulation rate of the server-side to-be-processed requests, when the accumulation rate is larger than the loss tolerance rate, the frequency of data requests transmitted by a target vehicle is determined to be reduced, and under the condition that the frequency of the data requests transmitted by the target vehicle is reduced, the number of the server-side to-be-processed data requests is correspondingly reduced, so that the accumulation rate is reduced, the accumulation rate of the server-side to-be-processed data requests is reduced, and the processing real-time performance of the vehicle requests is correspondingly improved.
In order to verify the effect brought by the embodiment of the present application, the ratio of the accumulation rate of the data requests to be processed at the server end when the technical scheme of the embodiment of the present application is adopted to process the vehicle request to the accumulation rate of the data requests to be processed at the server end when the technical scheme of the embodiment of the present application is adopted to process the vehicle request is further counted through an experimental way, as shown in table 1, 10 experiments are performed in total, and the experimental results show that the accumulation rate of the data requests to be processed at the server side in the prior art is higher than the accumulation rate of the data requests to be processed at the server side in the embodiment of the present application, which further illustrates that the technical solution in the embodiment of the present application can adjust the frequency of the data requests sent by the target vehicle according to the actual situation, and then reduce the quantity of server end pending data request, also reduce the pile-up rate of server end pending request promptly to the processing real-time of vehicle request has been improved to a certain extent.
Figure BDA0002548162910000151
Figure BDA0002548162910000161
TABLE 1
The following describes embodiments of the apparatus of the present application that may be used to implement the vehicle communication methods of the above-described embodiments of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the vehicle communication method described above in the present application.
Fig. 6 shows a block diagram of a vehicle communication device according to an embodiment of the present application, and referring to fig. 6, 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.
Wherein the calculating unit 602 is configured to calculate a braking distance of a target vehicle on a target road segment based on a driving parameter of the target vehicle; a first determining unit 604, configured to determine, according to the braking distance, the safe driving distance of the target road segment, the historical traffic accident rate of the target road segment, and a packet loss rate of a server interacting with the target vehicle, a capacity loss rate corresponding to a data request sent by the target vehicle to the server, where the capacity loss rate is used to indicate a probability that response data sent by the server can be tolerated to be lost; a second determining unit 608, configured to determine whether to reduce the frequency of data requests sent by the target vehicle according to the loss tolerance and the number of data requests to be processed in the server side.
In some embodiments of the present application, the first determining unit 602 includes: the first calculating subunit is configured to calculate a loss tolerance rate corresponding to a data request sent by the target vehicle to the server according to a historical traffic accident rate of the target road section and a packet loss rate of a server interacting with the target vehicle if the braking distance is smaller than the safe driving distance of the target road section; and the second calculating subunit is configured to calculate, if the braking distance is greater than or equal to the safe driving distance of the target road segment, a loss tolerance rate corresponding to a data request sent by the target vehicle to the server according to a historical traffic accident rate of the target road segment, a packet loss rate of a server interacting with the target vehicle, and a ratio of the braking distance to the safe driving distance.
In some embodiments of the present application, the first calculatorThe unit is configured to: if the braking distance is smaller than the safe driving distance of the target road section, calculating the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formulatolerate：
ptolerate＝1-(1-paccident)(1-ploss)
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossThe packet loss rate of the server side interacting with the target vehicle is obtained.
In some embodiments of the present application, the second computing subunit is configured to: if the braking distance is greater than or equal to the safe driving distance of the target road section, calculating the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server according to the following formulatolerate：
ptolerate＝(1-(1-paccident)(1-ploss))s/Δs
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossAnd the packet loss rate of a server side interacting with the target vehicle is s, the safe driving distance of the target road section is s, and the braking distance of the target vehicle is delta s.
In some embodiments of the present application, the second determining unit 606 includes: the third computing subunit is configured to compute the accumulation rate of the data requests to be processed in the server side according to the number of the data requests to be processed in the server side; and the determining and reducing subunit is configured to determine to reduce the frequency of the data sending request of the target vehicle if the loss tolerance rate is smaller than the accumulation rate.
In some embodiments of the present application, the third calculation subunit is configured to: acquiring the total amount of data requests received by the server end in a preset time period and the quantity of data requests which are not responded by the server end in the preset time period; and calculating the ratio of the number of the unresponsive data requests to the total number of the received data requests to obtain the accumulation rate of the data requests to be processed in the server side.
In some embodiments of the present application, the second determining unit 606 is configured to: in a case where it is determined to reduce the frequency at which the target vehicle transmits data requests, an indication to reduce the frequency of data requests is transmitted to a controller of the target vehicle.
In some embodiments of the present application, the computing unit 602 is configured to: the braking distance of the target vehicle is calculated 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 the vehicle control system.
In some embodiments of the present application, the computing unit 602 is configured to: calculating a braking distance Δ s of the target vehicle according to the following formula:
Δs＝(vhost+ahostΔt)2/(2amax)
wherein v ishostIs the speed of the target vehicle, a hostFor the acceleration of the target vehicle, Δ t is the reaction time of the driver or the vehicle control system, amaxThe maximum braking acceleration.
FIG. 7 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
It should be noted that the computer system 700 of the electronic device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data necessary for system operation are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An Input/Output (I/O) interface 705 is also connected to the bus 704.
The following components are connected to the I/O interface 1705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. 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, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.
In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method illustrated by the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program executes various functions defined in the system of the present application when executed by a Central Processing Unit (CPU) 701.
It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, 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 Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with a computer program embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program embodied 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 foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.
As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method described in the above embodiments.
It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments 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 disk, a removable 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 embodiments of the present application.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.
It will be understood that the present application is not limited to the precise arrangements 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 application is limited only by the appended claims.

Claims (10)

1. A method of processing a vehicle request, the method comprising:
calculating a braking distance of a target vehicle on a target road section based on a driving parameter of the target vehicle;
determining a loss tolerance 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 the server side interacting with the target vehicle, wherein the loss tolerance rate is used for representing the probability of tolerating the loss of response data sent by the server side;
And determining whether the frequency of sending data requests by the target vehicle is reduced or not according to the loss tolerance rate and the number of the data requests to be processed in the server side.
2. The method according to claim 1, wherein determining a loss tolerance 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 segment, the historical traffic accident rate of the target road segment, and a packet loss rate of the server side interacting with the target vehicle comprises:
if the braking distance is smaller than the safe driving distance of the target road section, calculating a loss tolerance rate corresponding to a 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 greater than or equal to the safe driving distance of the target road section, calculating the loss tolerance rate corresponding to the data request sent by the target vehicle to the server 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.
3. The method according to claim 2, wherein if the braking distance is less than the safe driving distance of the target road segment, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server side is calculated according to the following formulatolerate：
ptolerate＝1-(1-paccident)(1-ploss)
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossThe packet loss rate of the server side interacting with the target vehicle is obtained.
4. The method according to claim 2, wherein if the braking distance is greater than or equal to the safe driving distance of the target road segment, the loss tolerance rate p corresponding to the data request sent by the target vehicle to the server side is calculated according to the following formulatolerate：
ptolerate＝(1-(1-paccident)(1-ploss))s/Δs
Wherein p isaccidentIs the historical traffic accident rate, p, of the target road sectionlossAnd the packet loss rate of a server side interacting with the target vehicle is s, the safe driving distance of the target road section is s, and the braking distance of the target vehicle is delta s.
5. The method of claim 1, wherein determining whether to reduce the frequency of data requests sent by the target vehicle according to the loss tolerance and the number of data requests to be processed in the server comprises:
Calculating the accumulation rate of the data requests to be processed in the server side according to the quantity of the data requests to be processed in the server side;
and if the loss tolerance rate is smaller than the accumulation rate, determining to reduce the frequency of the data request sent by the target vehicle.
6. The method according to claim 5, wherein 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 comprises:
acquiring the total amount of data requests received by the server end in a preset time period and the quantity of data requests which are not responded by the server end in the preset time period;
and calculating the ratio of the number of the unresponsive data requests to the total number of the received data requests to obtain the accumulation rate of the data requests to be processed in the server side.
7. The method of claim 1, further comprising:
in a case where it is determined to reduce the frequency at which the target vehicle transmits data requests, an indication to reduce the frequency of data requests is transmitted to a controller of the target vehicle.
8. The method of claim 1, wherein calculating a braking distance of a target vehicle on a target road segment based on a driving parameter of the target vehicle comprises:
And calculating the braking distance of the target vehicle according to the speed, the acceleration and the maximum braking acceleration of the target vehicle on the target road section and the reaction time of a driver or a vehicle control system.
9. The method according to claim 8, characterized in that the braking distance as of the target vehicle is calculated according to the following formula:
Δs＝(vhost+ahostΔt)2/(2amax)
wherein v ishostIs the speed of the target vehicle, ahostFor the acceleration of the target vehicle, Δ t is the reaction time of the driver or the vehicle control system, amaxThe maximum braking acceleration.
10. An apparatus for processing a vehicle request, the apparatus comprising:
a calculation unit configured to calculate a braking distance of a target vehicle on a target road segment based on a driving parameter of the target vehicle;
a first determining unit, configured to determine, according to the braking distance, the safe driving distance of the target road segment, the historical traffic accident rate of the target road segment, and a packet loss rate of a server interacting with the target vehicle, a capacity loss rate corresponding to a data request sent by the target vehicle to the server, where the capacity loss rate is used to indicate a probability that response data sent by the server can be tolerated to be lost;
And the second determining unit is configured to determine whether to reduce the frequency of the data requests sent by the target vehicle according to the loss tolerance and the number of the data requests to be processed in the server side.
CN202010567806.4A 2020-06-19 2020-06-19 Vehicle request processing method and device Pending CN111866080A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010567806.4A CN111866080A (en) 2020-06-19 2020-06-19 Vehicle request processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010567806.4A CN111866080A (en) 2020-06-19 2020-06-19 Vehicle request processing method and device

Publications (1)

Publication Number Publication Date
CN111866080A true CN111866080A (en) 2020-10-30

Family

ID=72986996

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010567806.4A Pending CN111866080A (en) 2020-06-19 2020-06-19 Vehicle request processing method and device

Country Status (1)

Country Link
CN (1) CN111866080A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112660160A (en) * 2020-12-29 2021-04-16 驭势科技（北京）有限公司 Method and device for controlling driving speed of unmanned vehicle

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112660160A (en) * 2020-12-29 2021-04-16 驭势科技（北京）有限公司 Method and device for controlling driving speed of unmanned vehicle

Similar Documents

Publication Publication Date Title
WO2022193511A1 (en) Map data transmission method and system, edge server, and storage medium
CN110491147B (en) Traffic information processing method, traffic information processing device and terminal equipment
CN112514425B (en) Data transmission method, vehicle-end equipment and network-side equipment
CN111768440A (en) Techniques for managing a world model of a monitored area
US10755565B2 (en) Prioritized vehicle messaging
CN112261098B (en) Vehicle speed control method, device and system for Internet of vehicles
CN111404976A (en) Data processing method, device and system, vehicle-mounted terminal and medium
US11889341B2 (en) Method and apparatus for managing roadside device in vehicle road cooperation, and cloud control platform system
CN113415275A (en) Vehicle message processing method and device, readable medium and electronic equipment
CN111583713A (en) Vehicle driving early warning method and device
CN111866080A (en) Vehicle request processing method and device
CN114220261A (en) Vehicle speed control method and device, server and storage medium
CN111739343B (en) Early warning method and device for vehicle accident risk, medium and electronic equipment
US20230305559A1 (en) Communication management device, communication management method, driving support device, driving support method and computer readable medium
CN111862599A (en) Vehicle information processing method and device
CN111524389B (en) Vehicle driving method and device
CN111640321B (en) Congestion relieving method based on edge calculation and related equipment
EP4053818A1 (en) Communication method and apparatus
CN112509314A (en) Intersection vehicle speed guiding method and device
CN111800465A (en) Vehicle message processing method, device, medium and electronic equipment
CN113781765B (en) Information processing method and device
EP4167611A1 (en) Cooperative intelligent transport system and method with cpm significance index for redundancy mitigation
EP4167606A1 (en) Cooperative intelligent transport system and method with cpm area perception request
US20240054887A1 (en) Cpr apr based security for its
EP4167607A1 (en) Cooperative intelligent transport system and method with cpm information significance level

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination