A vehicle-road-cloud integrated architecture design method, system and device

Abstract

The present invention relates to the field of autonomous driving technology, and specifically discloses a vehicle-road-cloud integrated architecture design method, system and device. The present invention constructs a scene set based on multi-dimensional scene elements such as facilities, environment, traffic, rules, etc. in the operating route of the autonomous driving vehicle, and combines the design and operation domain of the autonomous driving vehicle to determine the target element set that the roadside equipment needs to perceive in each scene set, and further determines the selection and layout points of the roadside equipment, while performing system data collection optimization, computing power allocation optimization and driving safety optimization. The present invention is mainly used to solve the applicability and optimization design problems of the vehicle-road-cloud integrated architecture in generalized and diverse scenarios, and can allocate the perception, transmission and computing resources of vehicles and roadside equipment more economically and efficiently, reduce data processing costs, improve system efficiency, reduce dependence on high-cost perception equipment, and reduce the overall cost of the system while ensuring vehicle driving safety.

Description

Technical Field

[0001] The present invention relates to the field of autonomous driving technology, and in particular to a vehicle-road-cloud integrated architecture design method, system and device. Background Art

[0002] Vehicle-road-cloud integration is the future development trend of vehicle-road collaborative autonomous driving technology. Through the mutual coupling among the three, it can significantly alleviate the long-tail effect of the current single-vehicle perception, improve the environmental adaptability of the entire system and the safety level of autonomous driving vehicles, reduce the cost and technical threshold of autonomous driving vehicles, improve the environmental adaptability of the entire system and the safety level of autonomous driving vehicles, and accelerate the implementation of autonomous driving technology.

[0003] CN118116221A discloses an autonomous driving decision-making and planning architecture based on vehicle-road-cloud integration, which builds vehicle-road-cloud integration through the physical space of the vehicle-side and the information space of the cloud device, but does not provide a multi-scenario differentiated demand-oriented vehicle-road-cloud integration efficient collaborative architecture and its optimization design method, which cannot make the vehicle-road-cloud differentiated and effective and economical collaboration in different scenarios. Therefore, the existing vehicle-road-cloud integration architecture still has problems such as applicability and optimization of generalized diverse scenarios. Summary of the invention

[0004] In order to solve the problems of generalized and diverse scenario applicability and optimal design of the vehicle-road-cloud integrated architecture, the present invention provides a vehicle-road-cloud integrated architecture design method, system and device.

[0005] In order to achieve the above-mentioned object of the invention, the present invention provides the following technical solutions:

[0006] In a first aspect, the present invention provides a method for designing a vehicle-road-cloud integrated architecture, wherein the vehicle-road-cloud integrated architecture includes a cloud device, a roadside device, and an autonomous driving vehicle, and the method includes:

[0007] Step 101: constructing a scene set according to the multidimensional scene elements in the running route of the autonomous driving vehicle, and determining a total target element set to be perceived based on each scene set; wherein the multidimensional scene elements include facilities, environment, traffic and rules;

[0008] Step 102: Determine a first target element set perceived by the autonomous driving vehicle in each scene set in combination with the designed operating domain of the autonomous driving vehicle;

[0009] Step 103: determining a second target element set according to the difference between the total target element set and the first target element set in each scenario set, selecting roadside equipment based on the second target element set, and planning the layout points of the roadside equipment in the operating route to obtain a roadside equipment layout plan;

[0010] Step 104: Design the driving speed of the autonomous driving vehicle in each scenario to obtain a vehicle driving plan;

[0011] Step 105: Based on the performance of the roadside equipment and the autonomous driving vehicle, and in combination with the roadside equipment deployment plan, data collection is optimized, computing power allocation is optimized for the computing transmission costs of the roadside equipment and the cloud equipment based on data computing requests, and driving safety is optimized based on the vehicle driving plan to complete the design.

[0012] According to a specific implementation, in the above design method, the data acquisition optimization includes:

[0013] According to the data collection accuracy of the roadside equipment and the autonomous driving vehicle for the same target element, the accuracy weight is allocated according to the accuracy ratio. The calculation formula is:

[0014] , ,

[0015] in, For the data collection accuracy of roadside equipment, To ensure the data collection accuracy of autonomous vehicles, is the accuracy weight of the roadside equipment, is the accuracy weight of the autonomous vehicle;

[0016] According to the spatial range and interval of data collection by roadside equipment and autonomous driving vehicles for the same target element, the distance weight is allocated according to the spatial range and interval ratio. The calculation formula is:

[0017] ,

[0018] in, is the sensing space range of the drive test equipment, is the distance between the autonomous driving vehicle and the roadside equipment, is the distance weight of the roadside equipment, is the distance weight of the autonomous vehicle;

[0019] According to the collection time period of the roadside equipment and the autonomous driving vehicle for the same target element, the time weight is allocated according to the proportion of the time interval. The calculation formula is:

[0020] , ,

[0021] in, is the collection time interval of the roadside equipment, is the collection time interval of the autonomous driving vehicle equipment, is the time weight of the drive test equipment, is the time weight of the autonomous vehicle;

[0022] The collected data are fused according to the accuracy weight allocation, distance weight allocation and time weight allocation, and the calculation formula is:

[0023] ,

[0024] in, is the fusion weight of the roadside equipment, is the fusion weight of the autonomous driving vehicle.

[0025] According to a specific implementation, in the above design method, the computing power allocation optimization includes:

[0026] All computing requests are scheduled through the computing power allocation model, and computing requests are allocated to cloud devices and roadside devices based on the principle of minimum cost to determine the carrier device for computing analysis; the objective function of the computing power allocation model is:

[0027] ,

[0028] in, c i Indicates operation request t i The operation cost, l i Indicates operation request t i The transmission cost is the cost of data processing calculation performed by the cloud device or the roadside device, and the transmission cost is the cost of data transmission performed by the cloud device or the roadside device.

[0029] According to a specific implementation, in the above design method, the method further includes:

[0030] Based on the designed vehicle-road-cloud integrated architecture, collaborative control design is performed, which includes:

[0031] The data collected by the autonomous driving vehicle and the data collected by the roadside equipment are weighted and fused to obtain fused data;

[0032] Determine the carrier device for operation analysis through the computing power allocation model, calculate the fused data through the carrier device and obtain the analysis results;

[0033] A judgment is made based on the analysis result. When the analysis result exceeds a first preset threshold, a first driving plan is issued to the autonomous driving vehicle through the roadside equipment. When the analysis result exceeds a second preset threshold, a second driving plan is directly issued to the autonomous driving vehicle.

[0034] According to a specific implementation, in the above-mentioned design method, the first driving plan and the second driving plan are used to indicate the driving direction, driving speed and acceleration of the autonomous driving vehicle.

[0035] According to a specific implementation, in the above-mentioned design method, the driving speed is based on the maximum speed limit in each scenario set, and the driving safety optimization is used to indicate the safe distance between the autonomous driving vehicles in each scenario set.

[0036] According to a specific implementation, in the above design method, the roadside equipment includes a roadside perception device, a roadside communication device and a roadside computing device.

[0037] According to a specific implementation, in the above-mentioned design method, the total target element set includes information on people, vehicles, roads, and environment, including the position, speed, and driving direction of the autonomous driving vehicle, the position and movement trajectory of pedestrians, the status of traffic lights, traffic signs, markings, road alignment, obstacles, and environmental status information.

[0038] In a second aspect, the present invention provides a vehicle-road-cloud integrated system, the system comprising a cloud device, a roadside device and an autonomous driving vehicle, wherein the cloud device, the roadside device and the autonomous driving vehicle are designed using a vehicle-road-cloud integrated architecture design method as described in any one of the above items.

[0039] In a third aspect, the present invention provides a vehicle-road-cloud integrated architecture design device, including a memory and a processor, wherein:

[0040] The memory is used to store computer programs;

[0041] The processor is used to call and execute the computer program so that the device performs any one of the methods described above.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] The present invention constructs a scene set according to multi-dimensional scene elements such as facilities, environment, traffic, rules, etc. in the operation route of the autonomous driving vehicle, and determines the total target element set to be perceived in each scene; combined with the design and operation domain of the autonomous driving vehicle, the driving speed of the autonomous driving vehicle in each scene and the target element set that the roadside equipment needs to perceive are determined, so as to determine the selection and layout points of the roadside equipment; on this basis, data collection, computing power allocation, and driving safety optimization are carried out; compared with the prior art, the present invention focuses on the design and optimization of the vehicle-road-cloud integrated architecture guided by differentiated perception needs under the coupling of multi-dimensional scene elements, which can improve the applicability, safety, and economy of the overall system for diversified scenes, so that the vehicle-road cooperative autonomous driving system can adapt to various traffic scenes more flexibly, perceive and respond to various situations in the traffic environment more comprehensively, and improve the safety of the autonomous driving vehicle; at the same time, the perception, transmission, and computing resources of the vehicle and roadside equipment are allocated more economically and efficiently, reducing the data processing cost and improving the system efficiency; in addition, the dependence on high-cost perception equipment can be reduced through target element identification and weight allocation, and the overall cost of the system can be reduced while ensuring the safety of vehicle driving. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A flowchart of a vehicle-road-cloud integrated architecture design method provided in an embodiment of the present application;

[0045] Figure 2 A schematic diagram of a collaborative control design process provided in an embodiment of the present application;

[0046] Figure 3 A system architecture diagram provided for an embodiment of the present application;

[0047] Figure 4 A schematic diagram of the longitudinal speed control logic of an autonomous driving vehicle provided in an embodiment of the present application;

[0048] Figure 5 A force analysis diagram of an autonomous driving vehicle on a horizontal slope provided in an embodiment of the present application;

[0049] Figure 6 An exemplary schematic diagram of weather station weight allocation provided in an embodiment of the present application;

[0050] Figure 7 A schematic diagram of the transmission of the driving plan provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The technical solution in this application will be described below in conjunction with the accompanying drawings.

[0052] In order to clearly describe the technical solution of the embodiment of the present application, the following explanation is first made.

[0053] In the embodiments of the present application, words such as "first", "second", and "third" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first vehicle, the second vehicle, and the third vehicle are used to distinguish different vehicles, and do not limit their order. Those skilled in the art can understand that words such as "first", "second", and "third" do not limit the quantity and execution order, and words such as "first", "second", and "third" do not necessarily limit them to be different.

[0054] In the embodiments of the present application, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0055] Please refer to Figure 1 , which shows a flow chart of a vehicle-road-cloud integrated architecture design method provided in an embodiment of the present application, wherein the vehicle-road-cloud integrated architecture includes cloud devices, roadside devices, and an autonomous driving vehicle, and the method includes:

[0056] Step 101: constructing a scene set according to the multidimensional scene elements in the running route of the autonomous driving vehicle, and determining a total target element set to be perceived based on each scene set; wherein the multidimensional scene elements include facilities, environment, traffic and rules;

[0057] Step 102: Determine a first target element set perceived by the autonomous driving vehicle in each scene set in combination with the designed operating domain of the autonomous driving vehicle;

[0058] Step 103: determining a second target element set according to the difference between the total target element set and the first target element set in each scenario set, selecting roadside equipment based on the second target element set, and planning the layout points of the roadside equipment in the operating route to obtain a roadside equipment layout plan;

[0059] Step 104: Design the driving speed of the autonomous driving vehicle in each scenario to obtain a vehicle driving plan;

[0060] Step 105: Based on the performance of the roadside equipment and the autonomous driving vehicle, and in combination with the roadside equipment deployment plan, data collection is optimized, computing power allocation is optimized for the computing transmission costs of the roadside equipment and the cloud equipment based on data computing requests, and driving safety is optimized based on the vehicle driving plan to complete the design.

[0061] Based on the above technical solution, this application constructs a scene set according to the multi-dimensional scene elements such as facilities, environment, traffic, rules, etc. in the operation route of the autonomous driving vehicle, which can comprehensively analyze the perception requirements under the coupling of different scene elements, and provide more accurate perception and response strategies for the autonomous driving vehicle. Further, the target element set that the roadside equipment needs to perceive is determined in combination with the design and operation domain of the autonomous driving vehicle, and then supplemented by the roadside equipment, which improves the perception range of the autonomous driving vehicle, especially the perception ability of the vehicle blind spot or super perception area, so as to determine the selection and layout of the roadside equipment, so that the vehicle-road-cloud integrated system provided by the present invention can be more flexibly adapted to various traffic scenes, and improve the applicability, safety and economy of the overall system for diversified scenes. At the same time, the data collection optimization and computing power allocation optimization of the roadside equipment can allocate the perception resources of the vehicle and roadside equipment more economically and efficiently, reduce unnecessary data processing, improve system efficiency, reduce dependence on high-cost perception equipment, and reduce the overall cost of the system on the premise of ensuring vehicle driving safety. It can solve the coupling relationship between the vehicle, road and cloud, and provide technical support for the early solution design and system function operation of the entire system.

[0062] The following is a detailed introduction and description of each step.

[0063] Step 101: Construct a scene set based on multi-dimensional scene elements such as facilities, environment, traffic, and rules in the autonomous driving vehicle's operating route, and determine the total target element set to be perceived based on each scene set.

[0064] Specifically, the scenario set is the factors that may affect traffic safety in a specific operating route of an autonomous vehicle. The scenario set is constructed based on these factors. , such as snow and ice on the road, which may affect the driving safety of autonomous vehicles. And further determine the specific scenarios The total set of target elements that need to be perceived For example, at an intersection, the number of elements that need to be sensed includes traffic lights, vehicles and their trajectories within the intersection, road markings, pedestrians, and non-motor vehicles. At sharp bends with poor visibility, it is necessary to sense parameters such as the position and speed of oncoming vehicles.

[0065] In one possible implementation, the total target element set includes information on people, vehicles, roads, and environment, including the position, speed, and direction of travel of the autonomous driving vehicle, the position and movement trajectory of pedestrians, the status of traffic lights, traffic signs, markings, road alignment, obstacles, and environmental status information.

[0066] Step 102: Determine a first target element set perceived by the autonomous driving vehicle in each scene set in combination with the designed operating domain of the autonomous driving vehicle.

[0067] First, determine the design operation domain (ODD) of the autonomous vehicle, and determine the perception capability of the autonomous vehicle itself in each scenario based on the ODD, which is the first target element set. Understandably, in the field of autonomous driving, the Operational Design Domain (ODD) is a key concept that defines the conditions under which the autonomous driving system is designed to operate, including the environment, geography, time constraints, and the presence or absence of traffic or road features. The determination of ODD is critical to the perception capabilities of autonomous vehicles, which determines in what scenarios the vehicle can operate safely and effectively.

[0068] Generally speaking, the perception system of an autonomous vehicle usually includes a variety of sensors, such as lidar, cameras, millimeter-wave radar, and ultrasonic sensors, which work together to provide the vehicle with environmental perception. The perception system needs to be able to accurately identify and understand objects, obstacles, road signs, and traffic signals around the vehicle, and convert this information into digital signals for further processing and decision-making by the vehicle.

[0069] However, under normal circumstances, the perception capabilities of autonomous vehicles cannot cover all scenes and elements. Therefore, based on these elements that cannot be perceived, the embodiments of the present application use roadside equipment to perform supplementary perception.

[0070] Step 103: Determine the second target element set based on the difference between the total target element set in each scene set and the first target element set. and the first target element set , then the set of missing perception elements in this scene is In order to ensure safety, it is necessary to use roadside equipment to supplement the perception of the missing target elements in the scene, that is, the second target element set , so as to ensure the safe operation of the entire system. For example, a certain type of autonomous driving vehicle lacks the perception of rain and snow, and the corresponding scene should be equipped with roadside perception equipment that can perceive rain and snow. It can be understood that there are multiple configuration schemes for autonomous driving vehicles, and there are also multiple corresponding configuration schemes for roadside equipment. Comprehensive analysis is carried out, and roadside equipment deployment schemes are equipped for different autonomous driving vehicle schemes, and the optimal configuration scheme is comprehensively selected for implementation, that is, roadside equipment is selected based on the second target element set.

[0071] Furthermore, the locations of roadside equipment are planned in the operation route. It is understandable that for the main line section, if the density of roadside sensing equipment is low, low-cost sensing equipment (such as RFID equipment) can be added to monitor the vehicle driving status at regular intervals, and further deduce the vehicle operation status on the entire road.

[0072] The spacing of low-cost roadside sensing equipment determines the real-time perception of the state of the autonomous vehicle. The larger the spacing, the lower the real-time monitoring of the driving state of the autonomous vehicle; the smaller the spacing, the higher the real-time monitoring, but the high density leads to increased costs, including equipment purchase, installation, and operation and maintenance costs. Therefore, it is necessary to plan the layout of roadside equipment, that is, to balance the real-time perception with the cost. In an embodiment of the present application, a method for point layout based on the perception of the driving state of the autonomous vehicle is provided. Specifically, it includes:

[0073] The driving status of the autonomous vehicle needs to be separated by a certain period of time For one monitoring, the spatial interval of low-cost roadside sensing equipment is:

[0074] ,

[0075] in, For sensor i To sensor i +1 Actual distance between For the interval time. It is the designed speed of the autonomous vehicle on this road section.

[0076] Interval time It can be determined comprehensively based on factors such as traffic volume and the complexity of road traffic. In order to save costs, it can generally be installed on the same pole as existing monitoring equipment. If there is a special need, it can be installed separately.

[0077] When autonomous vehicles are running on the main line or stopping at vehicle stations, they are often inevitably affected by various factors, which will further cause delays, resulting in delays in the operation of autonomous vehicles and even delays for other vehicles. Therefore, in the autonomous driving control system, the propagation range of autonomous driving vehicle delays should be controlled as much as possible to improve the robustness of the entire system operation.

[0078] When a vehicle passes by a low-cost roadside sensing device, data will be exchanged between the two, and the low-cost roadside sensing device will record the time when the vehicle passes. The driving status of the autonomous vehicle between the two sensors and whether a traffic incident has occurred are determined based on the running time of the vehicle between the two sensors.

[0079] The specific method is as follows:

[0080] Assume that a vehicle passes by i The time at the sensor is , then according to the preset driving speed of the vehicle The actual distance between the sensor , it can be predicted that the vehicle will be at the next sensor i+1 The time at , assuming the actual elapsed time is , then the actual time difference between the predicted time is:

[0081] ,

[0082] when When , it is determined that the vehicle operation delay is acceptable and belongs to the normal state;

[0083] when When the vehicle running state is abnormal, that is, when the time is If the autonomous vehicle is still not within the sensor i+ If the vehicle is clocked in at 1, it is determined that the vehicle's driving status is abnormal, and an early warning is required to further investigate the vehicle's driving status. If further investigation finds a fault or traffic accident, the emergency plan needs to be quickly activated to deal with it as soon as possible.

[0084] In the vehicle running state judgment formula, is the unit mileage delay threshold coefficient of the vehicle traveling between two sensor intervals, For sensor i To sensor i +1 is the actual distance between the two flights. The longer the distance, the greater the delay.

[0085] Delay Threshold Factor According to actual statistics, assuming that in a single test, under normal circumstances (without any abnormal events in terms of road, traffic, vehicles, or environment), the vehicle delay time is , then the unit mileage delay threshold coefficient is:

[0086] ,

[0087] right Perform multiple measurements and statistics, and arrange the measured values ​​in ascending order and then place them at the 85th percentile The measured value of The value of is:

[0088] .

[0089] The above implementation is only an example of planning the deployment points of the roadside equipment. Furthermore, the planned points of the roadside equipment can also be deployed for full coverage of the line based on its minimum sensing range. This will not be repeated in the embodiments of this application.

[0090] Step 105: Based on the performance of the roadside equipment and the autonomous driving vehicle, and in combination with the roadside equipment deployment plan, data collection is optimized, computing power allocation is optimized for the computing transmission costs of the roadside equipment and the cloud equipment based on data computing requests, and driving safety is optimized based on the vehicle driving plan to complete the design.

[0091] It can be understood that based on the roadside equipment deployment plan obtained above, that is, the determined roadside equipment selection and location, the embodiment of the present application provides data collection optimization, computing power allocation optimization and driving safety optimization for the roadside equipment that has completed the selection and location planning.

[0092] Specifically, the data collection optimization includes:

[0093] Data preprocessing: First, the collected data needs to be preprocessed, including cleaning, removing outliers, duplicate values ​​or missing values. Then the data is standardized so that data from different sources can be compared and integrated.

[0094] After preprocessing, the perception data collected by the fixed-point roadside equipment is matched with the perception data collected by the autonomous vehicle in time and space. This may require the use of interpolation or other statistical methods to approximately fill in the data collected by the autonomous vehicle at a specified time and space position to facilitate the synchronization of data in time and space.

[0095] Weight distribution of collected data: In the process of data fusion, data fusion algorithms such as weighted average, Kalman filtering or machine learning algorithms are used to fuse the data collected by fixed-point equipment on the roadside and the data collected by the autonomous driving vehicle. These algorithms can comprehensively consider the accuracy and reliability of data from different sources to generate more accurate and comprehensive perception data.

[0096] The weight distribution of the two types of data collected by roadside equipment and autonomous vehicles is mainly determined by the time factor, space factor and the accuracy of the equipment itself. Recently acquired data may be more valuable than old data and can be given a higher weight; if the data point is closer to the target location, it can be given a higher weight, and high-precision equipment is assigned a higher weight. The weight distribution specifically includes:

[0097] Allocating accuracy weights based on the data collection accuracy of the roadside equipment and the autonomous driving vehicle;

[0098] Specifically, the accuracy weight of the roadside equipment is:

[0099] ,

[0100] The precision weights for autonomous vehicles are:

[0101] ,

[0102] in, For the data collection accuracy of roadside equipment, To ensure the data collection accuracy of autonomous vehicles, is the accuracy weight of the drive test equipment, is the accuracy weight of the autonomous vehicle.

[0103] For example, the data collection accuracy of the roadside equipment is 0.2 meters, and the data collection accuracy of the autonomous vehicle is 1 meter. The reciprocal of the data collection accuracy is used as the basis for weight calculation in the accuracy weight, because the higher the accuracy, the greater its weight should be. That is, the basis of the accuracy weight of the roadside equipment is 1 / 0.20=5, and the basis of the accuracy weight of the autonomous vehicle is 1 / 1=1. In order to ensure that the sum of the weights is 1 (which is necessary in many data fusion algorithms), we need to normalize the weights. That is, the total weight is the sum of the accuracy weight of the roadside equipment and the accuracy weight of the autonomous vehicle, which is equal to 6, so the normalized accuracy weight of the roadside equipment is 5 / 6, and the normalized accuracy weight of the vehicle is 1 / 6.

[0104] Distance weight allocation is performed based on the spatial range and interval of data collection of the roadside equipment and the autonomous driving vehicle. Assuming that the spatial interval of the roadside equipment at fixed points is L, the perception spatial range of the roadside equipment is , then the distance weight of the roadside equipment at the fixed point is 1, The weight at the location is 0, and the distance weight of the autonomous driving vehicle itself is 1. In order to ensure that the sum of the weights is 1, the two weights are normalized, and the distance from the fixed point roadside equipment at a certain position in the middle is obtained. The distance weight at is:

[0105] ,

[0106] in, is the sensing space range of the drive test equipment, is the distance between the autonomous driving vehicle and the roadside equipment, is the distance weight of the roadside equipment, is the distance weight of the autonomous vehicle.

[0107] Based on the collection time period of the roadside equipment and the autonomous driving vehicle for the same measurement element, the time weight is allocated according to the proportion of the time interval. Assuming that the collection time interval of the roadside equipment at a fixed point is , the collection time interval of the autonomous driving vehicle is , according to the inverse of the data collection time interval, that is, the frequency size is used as the time weight. The larger the frequency, the greater the time weight should be.

[0108] , ,

[0109] in, is the time weight of the roadside equipment, is the time weight of the autonomous vehicle.

[0110] For example, the data collection cycle of the roadside equipment is 0.2 seconds, and the data collection cycle of the autonomous vehicle is 1 second. In the time weight calculation, the reciprocal of the cycle, i.e., the frequency, is used as the basis for weight calculation. The basis for the time weight of the roadside equipment is 1 / 0.2 = 5, and the basis for the time weight of the autonomous vehicle is 1 / 1 = 1. In order to ensure that the sum of the weights is 1, the weights need to be normalized. The normalized time weight of the roadside equipment is 5 / 6, and the normalized time weight of the vehicle is 1 / 6.

[0111] Furthermore, the collected data is fused according to the accuracy weight allocation, distance weight allocation and time weight allocation.

[0112] In a possible implementation, the average value of each weight value obtained above can be used for data fusion, and the fusion weight collected by the roadside equipment is finally obtained as follows:

[0113] ,

[0114] Then the fusion weight of the autonomous driving vehicle collection at the mobile point is:

[0115] ,

[0116] in, is the fusion weight of the roadside equipment, is the fusion weight of the autonomous driving vehicle.

[0117] Fusion perception data generation: Data is fused based on weight distribution. The fused data can generate refined data for the entire road, including high-resolution meteorological parameter maps, meteorological trend analysis, meteorological condition assessment for specific sections of road, road lighting data, signal timing data, road traffic operation data, etc.

[0118] In terms of computing power allocation, the vehicle, road, and cloud all have certain computing capabilities, and the computing power of the entire system is reasonably allocated to ensure the safe and efficient operation of the entire system. For data that needs to be processed in a timely manner, the roadside equipment or the computing equipment on the vehicle itself will process and send it in real time. For the analysis of global data, it will be transmitted to the cloud device, and then the relevant calculation and analysis will be carried out. The computing power allocation model aims to dispatch the computing power of cloud devices and roadside devices to process computing requests outside the ODD of autonomous driving vehicles, and seek the most economical computing power allocation plan on the basis of meeting the computing needs of autonomous driving vehicles.

[0119] Specifically, the specific process of vehicle-road-cloud computing power allocation includes:

[0120] For scene sets Any scene in , the computing power allocation model takes into account all roadside equipment And a remote cloud device with sufficient computing resources First, for an autonomous vehicle traveling on this road section, when the onboard computing resources cannot meet the computing needs or the computing request involves global data analysis, the autonomous vehicle will initiate a computing request to the cloud device. t i At the same time, the deadline for completing the operation request is notified D i Secondly, the cloud device evaluates the execution time of the computing request according to the computing request type, and uniformly schedules and allocates all computing requests through the computing power allocation model. Finally, if the operation request is executed by the roadside device and the autonomous driving vehicle is within the local network range of the roadside device, the calculation result is transmitted back by local transmission (such as WiFi, WAVE, DSRC, etc.), otherwise it is transmitted remotely through a multi-hop cellular network with wide area coverage (such as 4G, 5G).

[0121] Specifically, the objective function of the computing power allocation model is the sum of the computing cost and the transmission cost of all computing requests, which is expressed as:

[0122] ,

[0123] in, c i Indicates operation request t i The specific value is determined by the computing execution device (the computing request is different in different roadside devices). e k The operation cost Different, at the same time, the cost of computing requests in the cloud device computing Since its construction and operation costs are often higher than those of roadside equipment, the computing costs are relatively high); computing request t i The transmission cost l i Determined by its data transmission method (the calculation results are transmitted through different roadside equipment e k Cost of data transfer Different, but this cost is often smaller, while the cost of data transmission through cloud devices , whose value is often higher due to the various forms of additional costs brought about by additional backhaul traffic, such as bandwidth, congestion and other additional costs, and higher transmission costs).

[0124] (1) Computational cost:

[0125] First, by introducing the task assignment Boolean variable m i,k,s To indicate a computation request t i Assigned to roadside equipment e k on s On the thread:

[0126] ,

[0127] The cloud-edge computing power needs to meet the computing requests of any autonomous vehicle, so each computing request must be assigned to a roadside device or cloud device. That is, task allocation Boolean variable m i,k,s The sum of all threads on all roadside devices must be less than or equal to 1. When the sum is 1, the operation request t i Assigned to the s thread on the roadside device for execution, when the sum is 0, the operation request t iAssigned to cloud devices for execution, expressed as constraints:

[0128] ,

[0129] If the operation request t i is assigned to the cloud device for computing, then the computing request t i Variables in any running thread corresponding to any roadside equipment m i,k,s are all 0, that is:

[0130] ,

[0131] Likewise, by defining allocation variables, the computation cost can be computed by the computation request t i The computing cost of the roadside device and the computing cost of the cloud device are jointly constrained. Among them, since a computing request can only be calculated on a certain thread of a roadside device, the computing cost of the roadside device can be calculated by assigning variables to the task corresponding to the roadside device and its thread number. m i,k,s Double sum is performed and multiplied by the cost of executing the operation request by the roadside device. Similarly, if the operation request is performed on the cloud device, a Boolean variable is assigned to the task corresponding to the roadside device and its thread number. m i,k,s The double sum is 0, and the cost of the cloud device's computation can be determined by subtracting the double sum from 1 and multiplying it by the cost of the cloud device to perform the computation request. This process can be described by the following constraints:

[0132] ,

[0133] ,

[0134] In the above formula, m i,k,s For operation request t i Assigned to roadside equipment e k Assigns a Boolean variable to the task on the s thread.

[0135] (2) Parallel computing constraints:

[0136] A single roadside device often has multiple computing cores and can process multiple computing requests in parallel. t i The total number of devices should not exceed e k The maximum number of execution requests that can be processedN k To ensure that each roadside device is not overloaded, all computing requests are t i and threads s Task assignment Boolean variable m i,k,s By summing, we can get the roadside equipment e k The number of all requests running on the RSE is limited to no more than e k Maximum number of execution requests N k :

[0137] ,

[0138] in, N k Roadside equipment e k Processing operation requests t i The maximum number of requests to execute.

[0139] Secondly, by introducing a global operation order decision variable between all operation requests, the execution order of each operation request on the roadside equipment can be determined. p i,j Indicates a request for operation in global order t i and t j The order between:

[0140] ,

[0141] For the operation request order defined above, it should also satisfy the following antisymmetry and transitivity constraints.

[0142]

[0143] ,

[0144] in, p i,j Indicates a request for operation in global order t i and t j The order of operations between the decision variables, p j,i Indicates a request for operation in global order t j and t iThe order of operations between the decision variables, p i,l Indicates a request for operation in global order t i and t l The order of operations between the decision variables, p l,j Indicates a request for operation in global order t l and t j The order of operations between the decision variables, m i,k,s Indicates operation request t i Assign to roadside equipment e k Assign a Boolean variable to the task on the s thread, m j,k,s Indicates operation request t j Assign to roadside equipment e k Assign a Boolean variable to the task on the s thread, m l,k,s Indicates operation request t l Assign to roadside equipment e k The task allocation Boolean variable on the s threads on the same thread; considering the execution time of each operation request, the continuous variable is introduced R i,k Indicates operation request t i Roadside equipment e k The computing time consumed on R i,k It can be obtained by summing the computing time of the task itself and the computing time of the computing tasks with higher priority than this task. The execution time of the high-priority task is determined if and only if the request t j has priority over requests t i And request t j Also assigned to roadside equipment e k Thread s Run on, is not 0, by t i The sum of the requests can be obtained by summing the execution time of all high-priority tasks. This process is described by the following constraints:

[0145] ,

[0146] in, , For operation request t i AND operation request t j Roadside equipment e k Specifically, the operation request t i The computing time consumption includes the execution time of the computing request and the waiting time for other computing requests on the same thread (such as computing requests t j ) is completed.

[0147] In addition, the operation request t i Must be completed within the time required by the autonomous vehicle:

[0148] ,

[0149] in, D i Indicates operation request t i Deadline for completion, M is a sufficiently large numeric constant. If the operation requests t i Assigned to roadside equipment e k superior, The value is 1, and the constraint is transformed into ; On the contrary, if the operation request t i Not assigned to roadside equipment e k On the s thread, The value is not 0, and the right side of the inequality is M Leading, due to M If is large enough, the above constraints are relaxed.

[0150] (3) Transmission cost:

[0151] In addition, after the operation request is completed, the result needs to be transmitted back to the autonomous driving vehicle through the local network or remote network. t i exist e k The transmission type on the transmission cost, the embodiment of the present application introduces another transmission cost Boolean variable n i,kTo indicate whether the result data can be used from roadside equipment e k The local area network is used for transmission:

[0152] ,

[0153] in, n i,k Indicates operation request t i Through roadside equipment e k A Boolean variable that represents the transmission cost of the local area network transmission.

[0154] Without considering multi-stage transmission, operation request t i First, it should be assigned to the roadside equipment e k After the above processing is completed, the roadside equipment can be used e k The local area network returns the calculation results:

[0155] ,

[0156] like t i Not assigned e k ,but ,Right now n i,k is 0.

[0157] In addition, the calculation results must be completed within the time required by the autonomous vehicle operation request, that is, the operation request t i The autonomous vehicle must reach the roadside equipment e k Time T i,k The result is sent back to the vehicle before the

[0158] ,

[0159] Finally, the operation request t i Roadside equipment e k The computation time consumed on R i,k , should be no greater than the estimated arrival time of the autonomous vehicle T i,k :

[0160] ,

[0161] Specifically, if t i The results of the roadside equipment e k Local area network for local transmission, that is n i,k = 1, then the above constraint is transformed into Otherwise, due to M is a sufficiently large numeric constant, the constraint is relaxed.

[0162] In summary, the operation request t i Total transmission cost l i It can be determined by the transmission cost of the roadside device plus the transmission cost of the cloud device. n i,k Only in the operation request t i Assigned to roadside equipment e k The value will be 1 only when You can get the operation request t i Assigned to roadside equipment e k The transmission cost of the operation request can also be determined by the same logic. t i The transmission cost is allocated to the cloud device. The process is described by the following formula:

[0163] .

[0164] It should be noted that the roadside equipment used for the calculation request above adopts the roadside computing equipment in the roadside equipment selection, and the calculation request is used to calculate the fused data and obtain the analysis result.

[0165] It is understandable that the design starts from a macro perspective, determines the driving speed of all vehicles on the road, that is, the vehicle driving plan; and then optimizes the driving safety of the safe distance based on the plan. Specifically, the driving speed is based on the maximum speed limit in each scene set, and the driving safety optimization is used to indicate the safe distance between the autonomous driving vehicles in each scene set.

[0166] In one possible implementation, the autonomous driving vehicle determines different safe speeds according to a specific set of scenarios while driving. Under normal conditions, including normal weather and traffic conditions, the safe driving speed of the vehicle is mainly determined by the actual speed limit of the road. Under adverse weather conditions, the driving speed is determined comprehensively based on the influence of the road friction coefficient and visibility. Under traffic event conditions, such as traffic congestion and traffic accidents, the impact of the event ahead on the vehicle's driving speed is mainly considered, and the speed of the following vehicle is determined from the perspective of traffic safety and speed smoothness.

[0167] Furthermore, the safety distance is used to indicate the following distance that the autonomous driving vehicle should maintain in the driving scene. The following distance that should be maintained between vehicles mainly consists of two parts: a basic following distance and an elastic following distance.

[0168] In a possible implementation, the following distance is expressed as:

[0169] ,

[0170] in, The following distance that the autonomous vehicle maintains in the driving scenario. The basic following distance mainly refers to the necessary safety distance to avoid rear-end collision, including parking brake distance and parking interval. The parking brake distance refers to the distance from when the vehicle starts braking to when it stops, which is determined by factors such as the perception distance of the autonomous vehicle itself, the visibility of the road surface, and the friction coefficient. The parking interval mainly refers to the safe distance that should be maintained between the front and rear vehicles when the vehicle is parked, and is generally a constant between 2 and 4 meters; The elastic distance is mainly used to avoid the frequent acceleration and deceleration of other vehicles in the convoy when the vehicle encounters interference. That is, due to the existence of the elastic distance, even if the front vehicle brakes accidentally, the rear vehicle does not need to brake and decelerate immediately. The value of the elastic distance is related to the number of autonomous vehicles on the road.

[0171] Minimum braking distance of the vehicle as follows:

[0172] ,

[0173] in, To test the reaction time, v 0 is the current vehicle initial speed, a max is the maximum braking deceleration, which is determined by factors such as the road friction coefficient in the driving scenario, namely:

[0174] ,

[0175] In the above formula, is the road friction coefficient. The road friction coefficient varies in different driving scenarios. Especially in rainy and snowy conditions, the road friction coefficient decreases rapidly. g is the acceleration of gravity.

[0176] The difference between the distance of the vehicle braking and normal driving (no braking) is:

[0177] ,

[0178] ,

[0179] in, is the distance traveled by the vehicle in normal operation (without braking), is the duration of a single braking operation, a is the braking deceleration. Then the elastic distance is:

[0180] ,

[0181] In the above formula, n is the number of vehicles in the fleet, The possibility of braking.

[0182] In a possible implementation, the duration of a single braking can be calculated using a mathematical statistical method, and then the data is arranged from small to large, and the 85th percentile is used. The braking time length is The value of is:

[0183] ,

[0184] is the probability of braking, that is, the total time of a single trip on the road is T , the cumulative braking deceleration time is , then the probability of braking is:

[0185] ,

[0186] Collect the braking and deceleration probability values ​​of vehicles within a period of time, arrange the values ​​from small to large, and use the 85% percentile probability value as the braking probability. The size of the data can be statistically calibrated according to different roads, and the same road can be marked at intervals.

[0187] In addition, it should be noted that in curved sections, the safe driving speed of vehicles should not only consider the friction coefficient of the road surface, but also the influence of factors such as the curve radius and superelevation to avoid the vehicle rolling over due to excessive driving speed. In icy and snowy conditions, attention should also be paid to the phenomenon of vehicles sliding inward due to excessively slow driving speed.

[0188] At this point, the vehicle-road-cloud integrated architecture design is completed. Based on the above technical solution, the vehicle-road-cloud integrated architecture design provided by this application can better adapt to various complex traffic environments, including bad weather, complex traffic flows, etc.

[0189] In one possible implementation, an embodiment of the present application also includes collaborative control design based on a designed vehicle-road-cloud integrated architecture.

[0190] In terms of vehicle-road-cloud collaborative perception, it mainly refers to the collaborative perception of the vehicle and the road, which coordinates the data collected by the autonomous driving vehicle with the data collected by the roadside equipment, that is, the information analysis results collected by the roadside equipment and the information analysis results collected by the vehicle are mutually coordinated and uploaded to the cloud device. Therefore, weight distribution and fusion of the collected data can maximize the collaborative perception capability of the overall architecture.

[0191] In terms of collaborative decision-making, it mainly refers to the vehicle, road, and cloud making decisions on the driving direction, driving speed, and acceleration of the autonomous vehicle through information sharing. For example, when a vehicle merges into a ramp, the roadside equipment will detect the operating status of surrounding vehicles. If there is a collision, the roadside equipment will issue information and the merging vehicle will adjust its driving speed and trajectory to avoid traffic conflicts and accidents, allowing the vehicle to smoothly enter the main line.

[0192] In terms of collaborative control, it mainly refers to the collaboration among vehicle, road and cloud. Collaborative control can be carried out in complex scenarios, and all autonomous driving vehicles can be taken over and controlled. For example, autonomous driving vehicles can be taken over and controlled in accident sections and under severe weather conditions, and pass through dangerous sections smoothly.

[0193] Please refer to Figure 2 , which shows a schematic diagram of the process of collaborative control design provided in an embodiment of the present application. Specifically, the collaborative control design includes:

[0194] Step 201: weighting and fusing the data collected by the autonomous driving vehicle and the data collected by the roadside equipment to obtain fused data;

[0195] Step 202: Determine the carrier device for operation analysis through the computing power allocation model, calculate the fused data through the carrier device and obtain the analysis result;

[0196] Step 203: Make a judgment based on the analysis result. When the analysis result exceeds a first preset threshold, issue a first driving plan to the autonomous driving vehicle through the roadside equipment. When the analysis result exceeds a second preset threshold, issue a second driving plan directly to the autonomous driving vehicle.

[0197] The first driving plan and the second driving plan are used to indicate the driving direction, driving speed and acceleration of the autonomous driving vehicle.

[0198] The technical solution of the present application is further introduced and illustrated below in conjunction with specific implementation methods.

[0199] Assume that there is a project Project_A. The road section includes merging sections, curved sections and other scenes. Meteorological sensors are deployed on both roadside equipment and vehicle terminals to collect meteorological environment data along the route. The vehicle-road collaboration construction plan for this scene is as follows.

[0200] 1. System overall technical solution

[0201] The entire decision-making process of an autonomous vehicle is mainly divided into four parts: perception, calculation, decision-making, and execution. The perception level mainly involves the vehicle and roadside equipment. The calculation level mainly involves the vehicle, road, and cloud. The decision-making part involves the vehicle, road, and cloud. The execution level mainly involves the autonomous vehicle itself. Please refer to Figure 3 , which shows a system architecture diagram provided in an embodiment of the present application.

[0202] (1) Vehicle side: The vehicle side has the function of transmitting information between the roadside communication equipment (RSU) and the 5G base station and the cloud control platform. After obtaining the information, it combines its own perception and calculation results to perform control actions.

[0203] (2) Roadside / station: Road operation status and event identification are realized through roadside sensing equipment (cameras, millimeter-wave radars, weather stations, etc.) and roadside computing equipment. The information is published to the vehicle through the roadside communication equipment (RSU) and transmitted to the cloud device via optical fiber.

[0204] (3) Cloud: The integrated vehicle-road-cloud cloud control platform monitors and warns of abnormalities in the operation status of all autonomous driving vehicles and road traffic; it also realizes the integration, decision-making and release of vehicle-road collaborative information, as well as remote processing. The cloud interacts with roadside facilities and 5G base stations via optical fiber, and interacts with vehicle-side data via the roadside communication equipment (RSU) direct connection communication interface (PC5 interface) and the 5G base station cellular communication interface (uu interface).

[0205] 2. Roadside Equipment Layout Plan

[0206] Exemplary, determination of a roadside equipment deployment plan for a merging scenario.

[0207] Step 1: Determine the set of scenarios that affect traffic safety. When vehicles on the auxiliary road merge into the main line in the merging area, there is a merging conflict.

[0208] Step 2: Determine the design and operation domain of the autonomous vehicle. The autonomous vehicle can only perceive the driving status of vehicles within 150 meters ahead of the lane in real time, and it is difficult to perceive the driving status of vehicles in the acceleration lane of the merging area.

[0209] Step 3: Determine the roadside equipment selection and layout plan based on the vehicle configuration plan.

[0210] Combined with the above analysis results, it is necessary to monitor the driving status of vehicles on the main line and the acceleration lane. Therefore, roadside sensing equipment is deployed within the merging area to perform holographic perception of vehicle trajectories. The collision risk is calculated in real time based on the roadside equipment. Once there is a collision risk, the vehicle on the acceleration lane is warned based on the roadside RSU equipment to avoid traffic accidents.

[0211] Estimate the arrival time at the next sensor based on the speed of the autonomous vehicle i +1 time The actual collected vehicle arrival time is , and compare the two.

[0212] when When the vehicle is in normal operation state.

[0213] when When the vehicle is in danger, an early warning will be issued to check the actual operating status of the vehicle.

[0214] in, is the spacing between two roadside sensors. is the unit mileage delay threshold coefficient of the vehicle traveling between two sensor intervals.

[0215] The intervals between roadside equipment deployments can be determined based on a combination of temporal distance and spatial distance. Since the equipment for roadside vehicle perception is not very expensive, it can be appropriately encrypted.

[0216] 3. Scenario vehicle driving plan.

[0217] For example, the longitudinal speed of the vehicle is determined. Figure 4, which shows a schematic diagram of the longitudinal speed control logic of the autonomous driving vehicle provided in an embodiment of the present application. The vehicle longitudinal speed control logic mainly determines the driving state of the rear vehicle based on the total following distance. When the actual following distance of the vehicle is greater than the basic following distance, it drives at the original set speed. When it is less than the basic following distance, it further determines whether to decelerate. Exemplary determination of the safe driving speed of a curve section. If the vehicle is traveling too fast when the curve section has a certain superelevation, the vehicle may slide off the road. Please refer to Figure 5 , which shows a force analysis diagram of an autonomous driving vehicle on a horizontal slope provided by an embodiment of the present application. β is the road cross slope angle. Centrifugal force The calculation formula is as follows:

[0218] ,

[0219] Where: v is the vehicle speed; G is the vehicle's gravity; g is the acceleration due to gravity; r is the road curve radius.

[0220] The lateral force generated when a vehicle travels on the inside of a flat curve for:

[0221] ,

[0222] generally β If the angle is small, we can assume that: , , i 0 is the cross slope of the road surface. Then:

[0223] ,

[0224] ,

[0225] Lateral reaction force of the road on the wheels , whose maximum value is:

[0226] ,

[0227] In the formula, is the lateral friction coefficient.

[0228] When a vehicle is traveling on a flat curve, there is a lateral force that causes the vehicle to slide outward. , there is also a lateral reaction force that prevents the vehicle from sliding outwards , lateral reaction force Limited by the attachment conditions, when the lateral force Greater than adhesion When the vehicle slides to the outside of the curve, the following are necessary to ensure driving safety:

[0229] ,

[0230] Right now:

[0231] ,

[0232] After finishing, we can get:

[0233] ,

[0234] In order to prevent the vehicle from slipping on the outside during the curve section, the vehicle speed v The above requirements must be met.

[0235] 4. Collaborative control of the vehicle-road-cloud integrated architecture.

[0236] As described in step 201 above, the data collected by the autonomous driving vehicle and the data collected by the roadside equipment are weighted and fused to obtain fused data. For example, the meteorological data collected by the roadside equipment and the autonomous driving vehicle are taken as an example. First, data preprocessing is performed, including:

[0237] Data cleaning: remove invalid or abnormal data; data format unification: convert all data into a unified format, including timestamp, geographic location, meteorological parameters, etc.; time synchronization: ensure that all data are on the same time scale, and timestamps can be aligned through interpolation or approximation methods; spatial interpolation (for fixed points): if fixed points are sparse, use spatial interpolation algorithms (such as Kriging interpolation) to estimate the meteorological data of missing points.

[0238] Furthermore, weight distribution is performed, including:

[0239] A weight is assigned to each data source based on factors such as the accuracy of the data source itself and the measured spatial and temporal distance. High-precision devices are assigned higher weights. If the data point is closer to the target location, it can be given a higher weight. Recently acquired data may be more valuable than older data and can be given a higher weight.

[0240] Take the vehicle-road fusion perception of temperature in meteorological elements as an example: please refer to Figure 6 , which shows a schematic diagram of the weight fusion of meteorological data given in an embodiment of the present application.

[0241] Assign weights based on data collection accuracy, assuming The data collection accuracy of the roadside sensing equipment, is the data collection accuracy of the autonomous vehicle, and the accuracy weights of the roadside perception equipment and the autonomous vehicle for temperature are:

[0242] in, is the accuracy weight of the roadside perception device, is the accuracy weight of the autonomous vehicle.

[0243] Based on the spatial distance allocation weight, assuming that the layout interval of the roadside sensing equipment is L, the effective sensing space range is , then the roadside sensing device of the autonomous driving vehicle at the middle distance is At this time, the distance weight of the roadside perception device and the distance weight of the autonomous driving vehicle are:

[0244] ,

[0245] in, is the sensing space range of the road test sensing device, is the distance between the autonomous vehicle and the roadside sensing device, is the distance weight of the roadside sensing device, is the distance weight of the autonomous vehicle.

[0246] Assign weights based on time distance, assuming is the collection time interval of the roadside sensing equipment, is the collection time interval of the autonomous driving vehicle equipment, then the time weight of the roadside perception equipment and the time weight of the autonomous driving vehicle are:

[0247] , ,

[0248] in, is the time weight of the drive test equipment, is the time weight of the autonomous vehicle.

[0249] Finally, it is concluded that for the temperature data in the meteorological element, the allocation weight of the roadside sensing device is:

[0250] ,

[0251] The assigned weights for autonomous vehicles are:

[0252] .

[0253] Furthermore, data fusion is performed, including:

[0254] Weighted average method: Use the weighted average method to fuse the meteorological temperature data collected by the roadside sensing equipment and the meteorological temperature data collected by the autonomous driving vehicle.

[0255] As described in the above step 202, the carrier device for operation analysis is determined by the computing power allocation model, and the fused data is calculated by the carrier device to obtain the analysis result.

[0256] Exemplarily, the vehicle-road-cloud computing power allocation includes:

[0257] (1) Computing power allocation optimization model:

[0258] In this embodiment, a simplified vehicle-road-cloud collaboration scenario is considered, assuming that all roadside devices can only execute one computing request at the same time, that is, N k =1. The computing power allocation model of the vehicle-road-cloud is degenerated into the following:

[0259] ,

[0260] st

[0261] ,

[0262] In the above formula, c i Indicates operation request t i The operation cost, Indicates operation request t i Different roadside equipment e k The computational cost on Indicates operation request t i The cost of computing on cloud devices, l i Indicates operation request t i The transmission cost, Indicates operation request t i Different roadside equipment e k The local transmission cost on Indicates operation request t i Transmission costs through cloud devices, m i,k,s Indicates operation request t i Assigned to roadside equipment e k Assign a Boolean variable to the task on the s thread, m j,k,s Indicates operation request t jAssigned to roadside equipment e k Assign a Boolean variable to the task on the s thread, N k Roadside equipment e k Processing operation requests t i The maximum number of execution requests, p i,j Indicates a request for operation in global order t i and t j The order of operations between the decision variables, p j,i Indicates a request for operation in global order t j and t i The order of operations between the decision variables, p i,l Indicates a request for operation in global order t i and t l The order of operations between the decision variables, p l,j Indicates a request for operation in global order t l and t j The order of operations between the decision variables, R i,k Indicates a request for calculation under the condition that the calculation order is taken into account t i Roadside equipment e k The computing time consumed on , that is, the execution time; , For operation request t i AND operation request t j Roadside equipment e k The operation time in ; n i,k Indicates operation request t i Through roadside equipment e k The transmission cost Boolean variable for the local area network transmission, M is a sufficiently large numeric constant, D i Indicates operation request ti Deadline for completion, T i,k Indicates operation request t i When the autonomous vehicle reaches the roadside equipment e k The maximum time limit for sending the result back to the vehicle before A i,j,k Indicates that the operation request t i ,t j Roadside equipment e k The antisymmetry and transitivity constraints of the above operation are linear constraints; Indicates all operation requests, Indicates all drive test devices.

[0263] (2) Case data:

[0264] For a simple computing power allocation case, define two computing requests , two roadside equipment The remote cloud device computing cost for each computing request , ; The cost of the roadside equipment executing operation request 1 , ; The cost of the roadside equipment executing operation request 2 , ; The time when the roadside equipment executes operation request 1 , ; The time for the roadside equipment to execute operation request 2 , ; The deadline for the two operation requests is D 1=5, D 2=6; the transmission cost of each operation request is as follows:

[0265] .

[0266] (3) Allocation results:

[0267] The results of the computing power allocation case are shown in Table 1:

[0268] Table 1 is the result table of computing power allocation case

[0269]

[0270] Model solution results show that all calculation requests are concentrated on the same roadside equipment e 1 processing can minimize the total cost. This is because the roadside equipment e1 provides a better cost-effectiveness ratio for both operation requests. It is worth noting that although the operation request t 2. Roadside equipment e 1 takes longer to compute, but its total cost is relatively low, so it is ultimately handled by the roadside equipment. e 1Execute operation request t 2.

[0271] As described in the above step 203, a judgment is made based on the analysis result. When the analysis result exceeds a first preset threshold, a first driving plan is issued to the autonomous driving vehicle through the roadside equipment; when the analysis result exceeds a second preset threshold, a second driving plan is directly issued to the autonomous driving vehicle.

[0272] Specifically, the analysis result can be understood as the abnormal analysis result obtained by analyzing and processing the most original data collected by the autonomous driving vehicle and the roadside equipment after weight fusion. The abnormal analysis result may include, for example, the width and slope of the lane, whether there is water on the road surface, whether there is ice and snow on the road surface, traffic flow, traffic light indication information, lane line and landmark indication information, and whether there is a traffic accident on the road ahead, etc. The embodiments of the present application do not impose any limitation on this.

[0273] When the abnormal analysis result exceeds the first preset threshold, it can be understood that the complexity of the abnormal analysis result does not affect the autonomous passing ability of normal vehicles. At this time, the cloud device will issue the first driving plan to normal autonomous driving vehicles near the abnormal event area through roadside equipment or 5G communication facilities. It is used to instruct the driving direction, driving speed and acceleration of these autonomous driving vehicles to avoid the abnormal event area; at the same time, the cloud device sends abnormal handling instructions to the operation and maintenance personnel to handle abnormal vehicles and restore normal traffic conditions.

[0274] When the abnormal analysis result exceeds the second preset threshold, it can be understood that the complexity of the abnormal analysis result affects the normal vehicle's autonomous passing ability. Then the cloud device directly issues a second driving plan to the autonomous driving vehicle. That is to say, the cloud device takes over the normal autonomous driving vehicle near the abnormal area, and the real-time data of the vehicle's operating status is sent to the cloud device via the 5G communication facility. After manual observation and judgment, the remote driving function sends driving control instructions to the autonomous driving vehicle via the 5G communication facility. At the same time, the cloud device sends abnormal handling instructions to the operation and maintenance personnel to deal with the abnormal vehicle and restore normal traffic conditions.

[0275] In the embodiment of the present application, the information transmission path of the cloud device includes three types:

[0276] (1) The information perceived by the autonomous vehicle is transmitted to the cloud control platform via roadside communication equipment and optical fiber;

[0277] (2) The information perceived by the autonomous vehicle is transmitted to the cloud control platform via cellular communication base stations and optical fibers;

[0278] (3) The information sensed by the roadside equipment is transmitted to the cloud control platform via optical fiber.

[0279] After receiving the information reported by the autonomous driving vehicle and roadside equipment, the cloud device determines the ability of normal vehicles to make autonomous decisions based on factors such as the type of abnormality, environmental conditions, and traffic conditions.

[0280] Please refer to Figure 7 , which shows a schematic diagram of driving plan transmission provided in an embodiment of the present application.

[0281] In summary, based on the collaborative control design provided by the embodiment of the present application, the collected data is analyzed in real time through the computing power allocation model, which can quickly and efficiently identify abnormal situations, and generate driving plans in a timely and dynamic manner according to the abnormal analysis results, so that the autonomous driving vehicle can flexibly adjust the driving strategy according to the real-time traffic conditions. On the one hand, the driving plan can be quickly released to the autonomous driving vehicle through the roadside equipment to shorten the reaction time and improve the response speed to emergencies. On the other hand, the autonomous driving vehicle can be directly controlled through the cloud device to ensure that corresponding safety measures are taken under different levels of risk, thereby improving driving safety. Automated abnormality detection and driving plan release reduce the need for human judgment, thereby reducing the risk of accidents caused by human errors. This application can enable the system to better cope with various complex and unpredictable traffic environments through abnormal analysis and dynamic adjustment of driving plans, and provide support for traffic flow optimization and traffic congestion relief.

[0282] In another aspect of the present application, a device is provided, which includes a processor, a network interface and a memory, wherein the processor, the network interface and the memory are interconnected, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program instructions to execute the above method.

[0283] In the embodiments of the present application, the processor may be an integrated circuit chip having the ability to process signals. The processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0284] The methods, steps and logic diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The processor reads the information in the storage medium and completes the steps of the above method in combination with its hardware.

[0285] The storage medium may be a memory, which may be, for example, a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory.

[0286] Among them, the non-volatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory.

[0287] The volatile memory may be a random access memory (RAM) which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), sync link DRAM (SLDRAM), and direct rambus RAM (DRRAM).

[0288] The storage media described in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memory.

[0289] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A method for designing a vehicle-road-cloud integrated architecture, wherein the vehicle-road-cloud integrated architecture includes cloud devices, roadside devices, and autonomous driving vehicles, and is characterized in that: The method comprises: Step 101: constructing a scene set according to the multidimensional scene elements in the running route of the autonomous driving vehicle, and determining a total target element set to be perceived based on each scene set; wherein the multidimensional scene elements include facilities, environment, traffic and rules; Step 102: Determine a first target element set perceived by the autonomous driving vehicle in each scene set in combination with the designed operating domain of the autonomous driving vehicle; Step 103: determining a second target element set according to the difference between the total target element set and the first target element set in each scenario set, selecting roadside equipment based on the second target element set, and planning the layout points of the roadside equipment in the operating route to obtain a roadside equipment layout plan; Step 104: Design the driving speed of the autonomous driving vehicle in each scenario to obtain a vehicle driving plan; Step 105: Based on the performance of the roadside equipment and the autonomous driving vehicle, and in combination with the roadside equipment deployment plan, data collection is optimized, computing power allocation is optimized for the computing transmission costs of the roadside equipment and the cloud equipment based on data computing requests, and driving safety is optimized based on the vehicle driving plan to complete the design.

2. The vehicle-road-cloud integrated architecture design method according to claim 1, characterized in that: The data collection optimization includes: According to the data collection accuracy of the roadside equipment and the autonomous driving vehicle for the same target element, the accuracy weight is allocated according to the accuracy ratio. The calculation formula is: ， ， in, For the data collection accuracy of roadside equipment, To ensure the data collection accuracy of autonomous vehicles, is the accuracy weight of the roadside equipment, is the accuracy weight of the autonomous vehicle; According to the spatial range and interval of data collection by roadside equipment and autonomous driving vehicles for the same target element, the distance weight is allocated according to the spatial range and interval ratio. The calculation formula is: ， in, is the sensing space range of the roadside equipment, is the distance between the autonomous driving vehicle and the roadside equipment, is the distance weight of the roadside equipment, is the distance weight of the autonomous vehicle; According to the collection time period of the roadside equipment and the autonomous driving vehicle for the same target element, the time weight is allocated according to the proportion of the time interval. The calculation formula is: ， ， in, is the collection time interval of the roadside equipment, is the collection time interval of the autonomous driving vehicle equipment, is the time weight of the roadside equipment, is the time weight of the autonomous vehicle; The collected data are fused according to the accuracy weight allocation, distance weight allocation and time weight allocation, and the calculation formula is: ， in, is the fusion weight of the roadside equipment, is the fusion weight of the autonomous driving vehicle.

3. The vehicle-road-cloud integrated architecture design method according to claim 2 is characterized in that: The computing power allocation optimization includes: All computing requests are scheduled through the computing power allocation model, and computing requests are allocated to cloud devices and roadside devices based on the principle of minimum cost to determine the carrier device for computing analysis; the objective function of the computing power allocation model is: ， in, c i Indicates operation request τ i The operation cost, l i Indicates operation request τ i The transmission cost is the cost of data processing calculation performed by the cloud device or the roadside device, and the transmission cost is the cost of data transmission performed by the cloud device or the roadside device.

4. The vehicle-road-cloud integrated architecture design method according to claim 3 is characterized in that: The method further comprises: Based on the designed vehicle-road-cloud integrated architecture, collaborative control design is performed, which includes: The data collected by the autonomous driving vehicle and the data collected by the roadside equipment are weighted and fused to obtain fused data; Determine the carrier device for operation analysis through the computing power allocation model, calculate the fused data through the carrier device and obtain the analysis results; A judgment is made based on the analysis result. When the analysis result exceeds a first preset threshold, a first driving plan is issued to the autonomous driving vehicle through the roadside equipment. When the analysis result exceeds a second preset threshold, a second driving plan is directly issued to the autonomous driving vehicle.

5. The vehicle-road-cloud integrated architecture design method according to claim 4, characterized in that: The first driving plan and the second driving plan are used to indicate the driving direction, driving speed and acceleration of the autonomous driving vehicle.

6. The vehicle-road-cloud integrated architecture design method according to claim 1, characterized in that: The driving speed is based on the maximum speed limit in each scenario set, and the driving safety optimization is used to indicate the safe distance between the autonomous driving vehicles in each scenario set.

7. The vehicle-road-cloud integrated architecture design method according to claim 1, characterized in that: The roadside equipment includes a roadside sensing device, a roadside communication device and a roadside computing device.

8. The vehicle-road-cloud integrated architecture design method according to claim 1, characterized in that: The total target element set includes information on people, vehicles, roads, and environment, including the position, speed, and direction of travel of the autonomous driving vehicle, the position and movement trajectory of pedestrians, the status of traffic lights, traffic signs, markings, road alignment, obstacles, and environmental status information.

9. A vehicle-road-cloud integrated system, characterized in that: The system includes a cloud device, a roadside device and an autonomous driving vehicle, wherein the cloud device, the roadside device and the autonomous driving vehicle are designed using a vehicle-road-cloud integrated architecture design method as described in any one of claims 1 to 8.

10. A vehicle-road-cloud integrated architecture design device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store computer programs; The processor is configured to call and execute the computer program, so that the apparatus performs a method according to any one of claims 1 to 8.

Images