Vehicle-road cloud cooperative roadside communication terminal design method, device and equipment

Abstract

The invention provides a vehicle-road cloud cooperative roadside communication terminal design method, device and equipment, and relates to the technical field of data processing, and the method comprises the steps: configuring hardware components and software protocols for realizing a cooperative data processing function, a heterogeneous communication function and a local control function based on a functional architecture, establishing a data interaction link between the roadside communication terminal and the vehicle, the cloud and the adjacent roadside facilities; a traffic participation element state and a cloud scheduling instruction are obtained through a data interaction link, a local control function collects roadside local data, and initial cooperative control information is generated after fusion; and based on the parameter correction, performing optimization adjustment on the initial cooperative control information to generate final cooperative control information. According to the invention, the smoothness of data interaction between the vehicle cloud and the road cloud and the precision of cooperative control are effectively improved, and the rationality and suitability of the design of the vehicle cloud and road cloud cooperative roadside communication terminal are ensured.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to the design method, apparatus and equipment for a vehicle-road-cloud collaborative roadside communication terminal. Background Technology

[0002] With the deep integration of intelligent transportation and vehicle-to-everything (V2X) technology, vehicle-road-cloud collaborative systems have become a core solution to address pain points in urban commuting congestion and highway safety management. Roadside communication terminals, as key hubs connecting vehicles, roads, and the cloud, undertake core functions such as data collection, real-time transmission, and local collaboration. Their deployment rationality and scenario adaptability directly affect data interaction efficiency and collaborative decision-making response speed, serving as a fundamental support for ensuring the effectiveness of V2X collaboration. Existing roadside communication terminal deployment schemes have achieved certain results in urban roads and highway scenarios, often combining general road segment attributes, industry standards, or past experience for deployment. For example, they are deployed every 500 meters on urban roads and at kilometer-level intervals on highways, meeting basic communication needs in stable, simple traffic environments. However, in complex and dynamic real-world traffic scenarios, existing schemes still have room for optimization in terms of refined adaptation and regionally differentiated responses. Traffic flow characteristics, vehicle operating states, and communication needs may vary significantly across different key road sections: For example, during morning and evening rush hours, traffic flow characteristics, vehicle operating states, and communication needs may differ significantly in key urban road entrance sections (such as commercial areas and subway interchanges). Traffic congestion is a significant challenge, with the number of vehicles accessing the system at peak times reaching 3 to 5 times that of off-peak hours. This places extremely high demands on the instantaneous communication capacity and low-latency response of terminals. In the middle sections of urban expressways (such as elevated roads and tunnels), vehicles travel at a stable speed of 80 to 100 km / h, requiring terminals to continuously transmit high-definition traffic conditions and platooning instructions, which places even higher demands on transmission stability and continuity. At highway exit sections (such as the 2 kilometers before an interchange), vehicles decelerate, change lanes, and diverge, requiring terminals to cover the main lanes, deceleration lanes, and ramps to avoid information interruptions caused by signal blind spots. Existing deployment solutions are mostly based on general models or macroscopic parameter planning, lacking personalized modeling of the specific scenario topology and traffic flow spatiotemporal patterns. Some solutions do not optimize terminal density and capacity for peak traffic flow, do not consider the impact of terrain obstruction, or do not extend coverage to ramp areas, and rarely dynamically adjust terminal operating modes in conjunction with traffic flow tidal characteristics. This may lead to information interaction delays at the entrance section, signal attenuation in the middle section, and insufficient coverage at the exit section, increasing traffic risks and affecting the collaborative linkage effect of terminals, thus restricting the effectiveness of vehicle-road-cloud collaborative systems in complex scenarios. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a design method, device and equipment for a vehicle-road-cloud collaborative roadside communication terminal, which can effectively improve the smoothness of data interaction and the accuracy of collaborative control between vehicles, roads and the cloud, and ensure the rationality and adaptability of the design of the vehicle-road-cloud collaborative roadside communication terminal.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0005] Firstly, the design methodology for vehicle-road-cloud collaborative roadside communication terminals includes:

[0006] Step 1: Plan the deployment area of ​​the target road segment and determine the first critical deployment location, the second critical deployment location, and the third critical deployment location. The first critical deployment location corresponds to the entrance area of ​​the road segment, the second critical deployment location corresponds to the core area of ​​the middle section of the road segment, and the third critical deployment location corresponds to the exit area of ​​the road segment.

[0007] Step 2: Establish a topology model based on three key deployment locations; partition the topology model to generate structural units;

[0008] Step 3: Based on the network characteristics of the structural units, calculate and generate parameter correction values ​​for optimizing terminal deployment and working modes;

[0009] Step 4: Determine the functional architecture of the roadside communication terminal based on the parameter correction amount. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function.

[0010] Step 5: Based on the functional architecture, configure the hardware components and software protocols to implement collaborative data processing, heterogeneous communication and local control functions, and establish data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities.

[0011] Step 6: Obtain the status of traffic participants and cloud scheduling instructions through the data interaction link; collect local roadside data through local control function; and generate initial collaborative control information after fusion.

[0012] Step 7: Based on the parameter correction amount, optimize and adjust the initial cooperative control information to generate the final cooperative control information;

[0013] Step 8: Encapsulate the final collaborative control information and distribute it to the vehicle and cloud platform to complete the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

[0014] Secondly, the design device for the vehicle-road-cloud collaborative roadside communication terminal includes:

[0015] The deployment module plans the deployment area of ​​the target road segment and determines the first, second, and third key deployment locations. The first key deployment location corresponds to the road segment entrance area, the second key deployment location corresponds to the core area of ​​the middle section of the road segment, and the third key deployment location corresponds to the road segment exit area.

[0016] The partitioning module establishes a topology model based on three key deployment locations; it then partitions the topology model to generate structural units.

[0017] The calculation module, based on the network characteristics of the structural units, calculates and generates parameter correction quantities for optimizing terminal deployment and working modes;

[0018] The module is determined based on the parameter correction amount, and the functional architecture of the roadside communication terminal is determined. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function.

[0019] The configuration module, based on the functional architecture, configures the hardware components and software protocols that enable collaborative data processing, heterogeneous communication and local control functions, and establishes data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities.

[0020] The fusion module obtains the status of traffic participants and cloud scheduling instructions through data interaction links, while the local control function collects local roadside data and generates initial collaborative control information after fusion.

[0021] The optimization module optimizes and adjusts the initial cooperative control information based on the parameter correction amount to generate the final cooperative control information;

[0022] The distribution module encapsulates the final collaborative control information and distributes it to vehicles and the cloud platform, completing the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

[0023] Thirdly, a computing device, comprising:

[0024] One or more processors;

[0025] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0026] The above-described solution of the present invention has at least the following beneficial effects:

[0027] This invention generates initial collaborative control information through multi-source data fusion, and then optimizes and adjusts the initial information in a targeted manner by combining parameter corrections before packaging and distributing it. This enables the final collaborative control information to accurately match the actual traffic conditions, communication needs, and network characteristics of different key areas of the target road segment, improving the accuracy and response speed of vehicle-road-cloud collaborative decision-making. It effectively solves the problems of collaborative control information lacking scenario-based optimization and being difficult to adapt to complex dynamic traffic scenarios, and fully releases the overall efficiency of the vehicle-road-cloud collaborative system in complex traffic scenarios such as urban arterial roads, expressways, and highways. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the design method for a vehicle-road-cloud collaborative roadside communication terminal provided in an embodiment of the present invention.

[0029] Figure 2 This is a schematic diagram of a vehicle-road-cloud collaborative roadside communication terminal design device provided in an embodiment of the present invention. Detailed Implementation

[0030] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0031] like Figure 1 As shown, embodiments of the present invention propose a design method for a vehicle-road-cloud collaborative roadside communication terminal, the method comprising the following steps:

[0032] Step 1: Plan the deployment area of ​​the target road segment and determine the first critical deployment location, the second critical deployment location, and the third critical deployment location. The first critical deployment location corresponds to the entrance area of ​​the road segment, the second critical deployment location corresponds to the core area of ​​the middle section of the road segment, and the third critical deployment location corresponds to the exit area of ​​the road segment.

[0033] Step 2: Establish a topology model based on three key deployment locations; partition the topology model to generate structural units;

[0034] Step 3: Based on the network characteristics of the structural units, calculate and generate parameter correction values ​​for optimizing terminal deployment and working modes;

[0035] Step 4: Determine the functional architecture of the roadside communication terminal based on the parameter correction amount. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function.

[0036] Step 5: Based on the functional architecture, configure the hardware components and software protocols to implement collaborative data processing, heterogeneous communication and local control functions, and establish data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities.

[0037] Step 6: Obtain the status of traffic participants and cloud scheduling instructions through the data interaction link; collect local roadside data through local control function; and generate initial collaborative control information after fusion.

[0038] Step 7: Based on the parameter correction amount, optimize and adjust the initial cooperative control information to generate the final cooperative control information;

[0039] Step 8: Encapsulate the final collaborative control information and distribute it to the vehicle and cloud platform to complete the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

[0040] In this embodiment of the invention, the invention generates initial collaborative control information through multi-source data fusion, and then optimizes and adjusts the initial information in a targeted manner by combining parameter correction amounts before packaging and distributing it. This enables the final collaborative control information to accurately match the actual traffic conditions, communication needs and network characteristics of different key areas of the target road segment, thereby improving the accuracy and response speed of vehicle-road-cloud collaborative decision-making. It effectively solves the problems of collaborative control information lacking scenario-based optimization and being difficult to adapt to complex dynamic traffic scenarios, and fully releases the overall efficiency of the vehicle-road-cloud collaborative system in complex traffic scenarios such as urban arterial roads, expressways and highways.

[0041] In a preferred embodiment of the present invention, step 1 involves planning the deployment area of ​​the target road segment and determining a first key deployment location, a second key deployment location, and a third key deployment location. The first key deployment location corresponds to the entrance area of ​​the road segment, the second key deployment location corresponds to the core area of ​​the middle section of the road segment, and the third key deployment location corresponds to the exit area of ​​the road segment. Specifically, this includes: firstly, conducting a comprehensive survey of the target road segment, collecting core data including the road segment length (accuracy retained to the meter level), the number of lanes (clearly defining the number of main lanes, auxiliary lanes, and ramps), and the traffic flow distribution during different time periods (statistically collected from roadside cameras for 7 consecutive days, including morning peak from 7:00 to 9:00, off-peak from 9:00 to 17:00, and evening peak from 17:00 to 18:00). The survey data includes: average traffic flow at 9:00 AM and during the nighttime off-peak hours from 7:00 PM to 7:00 AM the next day; surrounding environmental characteristics (including the presence of commercial area interchanges, subway entrances / exits, interchanges, tunnels, or elevated road sections, and specific parameters for tunnel length and elevated road height); accident-prone locations (road sections with ≥3 accidents in the past year); and the distribution of existing traffic infrastructure (such as the location, communication coverage, and equipment model of existing roadside equipment). Based on the survey data, deployment areas are divided, and these areas must fully cover the entire road segment, with a focus on key sections with traffic flow ≥800 vehicles / hour and communication request frequency ≥500 times / hour. The communication request frequency is set based on the dual-mode communication requirements of 5G and C-V2X.

[0042] When determining the first key deployment location, focus on the core node where traffic converges at the road segment entrance. Select a location where traffic begins to concentrate but before congestion occurs. Specifically, the standard is that the traffic flow at this location is ≤300 vehicles / hour during off-peak hours and ≤500 vehicles / hour during peak hours. Examples include 100 meters behind the commercial area interchange at the entrance of a main urban road, or the end of the acceleration lane after a highway toll station exit (500 meters from the toll station exit). The geographic coordinates of this location (longitude and latitude retained to 6 decimal places) should be exported through GPS field mapping (positioning accuracy ±1 meter) or a high-precision coordinate system GIS. When determining the second key deployment location, target the core area in the middle of the road segment. This area should have stable traffic flow (speed fluctuation ≤10 km / h), with no frequent merging or splitting. It should avoid structures such as bridges and tunnels that obstruct communication signals (≥50 meters from the edge of such structures), and should be selected in the middle of the road segment with a clear view. Areas without obstructions exceeding 5 meters in height, such as unobstructed green belts in the middle of urban expressways or the midpoint of highway mileage markers (500 to 800 meters from each end mileage marker); precise geographic coordinates are obtained through on-site measurement (using a total station, measurement accuracy ±0.5 meters); when determining the third key deployment location, for the exit area of ​​the road segment, where traffic flow frequently slows down and changes lanes, and routes diverge (vehicle speed drops from ≥60km / h to ≤40km / h), it is necessary to cover the main lane, deceleration lane, and ramp entrance (coverage of ≥3 lane widths, each lane 3.75 meters wide), such as the starting point of the deceleration lane before the exit of urban roads (300 meters from the exit ramp entrance) or 200 meters in front of the divergence point before the highway interchange; geographic coordinates are determined by combining high-precision traffic map data (scale 1:1000) and on-site survey (using a GNSS positioning instrument, positioning accuracy ±0.8 meters).

[0043] This embodiment precisely plans key deployment locations and clarifies specific parameter standards, ensuring that the deployment of roadside communication terminals is highly adapted to the traffic flow characteristics and environmental conditions of road sections. This effectively avoids blind deployment and ensures communication coverage without blind spots or overlaps.

[0044] In a preferred embodiment of the present invention, step 2, establishing a topology model based on three key deployment locations; partitioning the topology model to generate structural units, may include:

[0045] Step 201: Based on the geographic coordinates of the first, second, and third key deployment locations, establish a connection between the three key deployment locations to generate an initial topology describing the backbone connections of the target road segment. Specifically, this includes: first, summarizing the high-precision geographic coordinate data of the first, second, and third key deployment locations to ensure consistent coordinate data accuracy (longitude and latitude are both retained to 6 decimal places); using the three key deployment locations as core nodes, connecting the first and second key deployment locations, and the second and third key deployment locations sequentially with straight lines to form two backbone connection lines; the two connection lines together constitute the initial topology describing the core connection relationships of the target road segment.

[0046] Step 202: Based on the initial topology, according to the preset communication coverage radius of the roadside communication terminal, multiple auxiliary nodes are inserted at equal intervals on the line connecting every two adjacent key deployment locations to generate a topology model that includes all core nodes and auxiliary nodes as well as the connection relationships between nodes. Specifically, this includes: first, clarifying the hardware performance benchmark of the roadside communication terminal, referring to the core capabilities of the AG57XQ automotive-grade 5G NR Sub-6 GHz communication module. This hardware supports the 3GPP Rel-15 standard and MIMO multi-antenna mode, with a maximum single-antenna communication distance of up to 800 meters. In dual-antenna MIMO mode, signal penetration loss is reduced by 30%, and anti-blocking capability is improved. These performance parameters provide the core basis for setting the coverage radius.

[0047] The preset communication coverage radius is accurately determined based on the environmental characteristics of the target road segment: In urban road scenarios, the average building height is 15 to 30 meters, and the street density is ≥200 buildings per 1,000,000 square meters. Signal is easily attenuated due to obstruction, so the coverage radius is set to 300 meters. If there are high-rise office buildings (height > 30 meters) or dense residential buildings (spacing < 10 meters) around the road segment, the obstruction intensity increases, and the coverage radius is reduced by 20% to 30%, i.e., 210 to 240 meters. The reduction ratio is determined based on the height and density of the obstruction. For every increase in height... For every 10 meters or every 50 buildings / 1,000,000 square meters increase in density, the coverage radius is reduced by 5%. In highway scenarios, there are no dense buildings to obstruct the view, and the signal attenuation is only affected by atmospheric propagation, so the coverage radius is set at 500 meters. If the road section is located in a plain area without mountains, bridges, or other obstructions, the signal propagation loss is reduced, and the coverage radius can be expanded by 10% to 15%, i.e., 550 to 575 meters. The expansion ratio is adjusted according to the results of on-site signal attenuation tests. The signal strength is tested every 10 kilometers, and the maximum expansion is 15% when the attenuation is <5dB.

[0048] Based on the two backbone connection lines of the initial topology, the construction process of the complete topology model is initiated: parameter solidification clarifies the value logic of each parameter in the interval distance calculation formula, and the overlap distance is set to 50 meters. This value is determined based on the signal attenuation curve of the AG57XQ module. When the signals of two nodes overlap by 50 meters, the signal strength at the receiving end is ≥-75dBm, which can ensure communication stability; the number of auxiliary nodes is derived by reverse calculation of the distance between two key nodes and the interval distance to ensure that there are no gaps in the coverage of adjacent nodes.

[0049] The auxiliary node coordinate calculation involves obtaining high-precision coordinates (longitude and latitude rounded to 6 decimal places) between the first and second critical deployment locations, and between the second and third critical deployment locations. Linear interpolation is used to calculate the auxiliary node coordinates. For example, if the coordinates of the first critical deployment location are (E118.XXX123, N30.XXX456) and the coordinates of the second critical deployment location are (E118.XXX789, N30.XXX678), with a spacing of 1200 meters and an interval distance of approximately 367 meters, when inserting three auxiliary nodes, the longitude of the first auxiliary node is E118. .XXX123+(E118.XXX789-E118.XXX123)×367 / 1200, and the same applies to latitude. Calculate the coordinates of the remaining two auxiliary nodes in sequence, ensuring that the coordinate accuracy of each auxiliary node is ±0.5 meters. Node integration and connection involves arranging the three core nodes and all calculated auxiliary nodes according to their actual geographical locations, connecting adjacent nodes (core nodes and adjacent auxiliary nodes, and between auxiliary nodes) with straight lines to form the connection relationship between nodes. The path of the connection line must conform to the actual direction of the road segment, with a deviation of ≤1 meter, and finally forming an initial model containing node location information and connection relationships.

[0050] Signal simulation verification employs professional wireless communication simulation methods. It inputs road segment environmental parameters (height, density, and material of obstructions) and the signal attenuation model of the AG57XQ module to simulate the signal coverage range of each node in the initial model. The focus is on detecting the signal strength in overlapping areas between adjacent nodes, ensuring that the signal strength in the overlapping area is ≥-75dBm, eliminating the risk of communication interruption due to signal attenuation. If the simulation finds that the signal strength in a certain area is <-75dBm (i.e., a blind spot exists), the interval distance of the corresponding section is shortened, and the number of auxiliary nodes is increased. For example, in an area with an original interval distance of 367 meters, if a blind spot appears... For blind spots, the spacing can be adjusted to 300 meters, one auxiliary node can be added, the coordinates can be recalculated and substituted into the simulation; if the signal overlap area is found to exceed 100 meters (causing resource waste), the spacing can be appropriately increased and the number of auxiliary nodes reduced until the signal strength in all areas meets the standard and the overlap distance is controlled between 50 and 80 meters; the communication link quality between nodes can be verified by simulation, the data transmission process can be simulated, and the communication delay between adjacent nodes can be ≤10 milliseconds and the data packet delivery rate can be ≥99%. If the requirements are not met, the node positions can be adjusted or the number of nodes can be increased, and the simulation can be repeated until the link quality meets the standard.

[0051] Model Implementation Phase: On-site survey and calibration involves using a GNSS positioning device (positioning accuracy ±0.3 meters) to reach the target road segment. The installation points are surveyed against the calculated coordinates of the auxiliary nodes, avoiding unsuitable areas such as drainage ditches and green belt edges. If adjustments are necessary, the deviation between the adjusted coordinates and the original calculated coordinates is ≤0.5 meters. Simultaneously, the spacing and overlap distance between the node and adjacent nodes are re-verified to ensure parameters meet requirements. Based on the actual node coordinates after on-site survey, the connection lines between nodes are updated, connecting adjacent nodes with straight lines. A complete topology map is drawn using GIS, labeling the coordinates of each node, adjacent node numbers, and the actual length of the connection lines, ensuring the connection path aligns with the road segment direction with a deviation ≤1 meter. All core nodes, auxiliary nodes, and their connections are integrated to form a complete topology model. On-site signal testing uses signal strength testing equipment to check the coverage of each node, confirming an overlap distance of ≥50 meters between adjacent nodes and no signal blind spots along the entire road segment. Actual data transmission testing verifies the stability of the communication links between nodes, ensuring compliance with vehicle-road cooperative communication requirements, ultimately completing model generation.

[0052] Step 203: Based on the topology model, according to the spatial distribution of nodes in the model, connect geographically adjacent nodes to form multiple candidate polygon regions. Specifically, this includes: extracting the spatial location information of all core nodes and auxiliary nodes based on the complete topology model, with coordinate data uniformly retained to 6 decimal places to ensure consistent accuracy; calculating the straight-line distance between any two nodes using the Euclidean distance formula, with a distance ≤200 meters used as the adjacency criterion in urban road scenarios and a distance ≤300 meters used as the adjacency criterion in highway scenarios; and using core nodes... Centered on a point, prioritize associating the 3 to 4 nearest auxiliary nodes as the initial vertex set. For example, if the core node's coordinates are (E118.123456, N30.654321), its four nearest auxiliary nodes are (E118.123656, N30.654521), (E118.123256, N30.654721), (E118.123056, N30.654321), and (E118.123256, N30.654121), proceeding clockwise. Connect the four auxiliary nodes to the core node sequentially to form a closed quadrilateral. Repeat the above operation for all nodes, ensuring that each node is contained within at least one polygon, and that the distance between the node center and the polygon boundary is ≥0.5 meters to avoid nodes falling on the edge. Use coordinate traversal to find the blank areas between polygons: first, based on the vertex coordinates of all polygons, determine the longitude range (between the maximum and minimum longitude values ​​of all polygons) and latitude range (between the maximum and minimum latitude values ​​of all polygons), set the traversal step size to 1 meter, and proceed according to longitude... From left to right and from bottom to top latitude, traverse each coordinate point within the range one by one. For each traversed coordinate point, use the ray method to determine whether it is inside any constructed polygon. That is, draw a ray from the coordinate point in any direction (such as right) and count the number of intersections between the ray and the polygon boundary. If the number of intersections is odd, the point is inside the polygon; if it is even, it is outside the polygon. Mark all coordinate points determined to be outside the polygon as candidate points for blank areas, and then filter out continuous candidate point clusters through adjacency relationships. Each continuous cluster corresponds to a blank area.

[0053] For each blank area, extract consecutive candidate points on its edge as boundary coordinates, sort them clockwise to form a closed boundary, and then calculate the area using the polygon area formula (shoelace formula): The first step is to number the sorted boundary coordinates sequentially, denoted as ( , ), ( , )……( , ), and the last coordinate ( , ) and the first coordinate ( , The first step is to ensure that the coordinates of all adjacent coordinates coincide; the second step is to calculate all adjacent coordinates. The sum, that is The third step is to calculate all adjacent coordinates. The sum, that is The fourth step is to calculate the area of ​​the blank area. By accurately calculating coordinate values ​​(retaining 6 decimal places), the area calculation accuracy is ensured to be ≤0.1 square meters. If the calculated blank area is ≤10 square meters, the existing polygon remains unchanged. If it exceeds 10 square meters, the vertex coordinates of adjacent polygons are adjusted, and the candidate points of the blank area edge are included in the vertex set of the adjacent polygons. The polygon boundaries are reconnected until the blank area is ≤10 square meters. If there are nodes that are not included in any polygon, a small triangle is constructed with the node as the center and associated with the three nearest surrounding nodes. This triangle is then included in the candidate polygon area. All the closed polygons formed in the end are the candidate polygon areas.

[0054] Step 204: For each candidate polygon region, calculate the minimum enclosing rectangle. The minimum enclosing rectangle is the rectangle with the smallest area that completely encloses all vertices of the corresponding polygon and whose sides are parallel to the geographic coordinate axes. Specifically, this includes: for each candidate polygon region, traversing all its vertices and recording the x-coordinate (longitude) and y-coordinate (latitude) of each vertex, keeping the coordinate data to four decimal places, such as E118.1234, N30.6543, ensuring accuracy to the centimeter level; comparing the x-coordinates of all vertices one by one, and selecting the x-coordinate with the largest and smallest values; comparing the y-coordinates of all vertices one by one in the same way, and selecting the y-coordinate with the largest and smallest values; using the minimum x-coordinate as the left boundary of the rectangle and the maximum x-coordinate as the right boundary of the rectangle, drawing two vertical sides parallel to the longitude lines of the geographic coordinate system; using the minimum y-coordinate as the lower boundary of the rectangle and the maximum y-coordinate as the upper boundary of the rectangle, drawing two horizontal sides parallel to the latitude lines of the geographic coordinate system. Connect the four sides of the rectangle in a clockwise order to form a closed rectangle. Calculate the angles between the four sides of the rectangle and the geographic coordinate axes using the vertex coordinates. Take the absolute value of the angle between each side and the corresponding coordinate axis, ensuring that all angles are ≤0.5°. If any angle exceeds the threshold, re-check all vertex coordinate records and filtering results, correct the deviation data, and filter the extreme values ​​of the horizontal and vertical coordinates again. Reconstruct the rectangle until the angle requirements are met. Construct rectangles with other enclosing methods for area comparison: Using the center of the polygon as the rotation point, rotate the rectangle in increments of 1° within the range of 0° to 90° to create a rotating rectangle. Generate a rotating rectangle for each angle. Construct oblique rectangles with different tilt angles, covering key angle nodes within the range of 0° to 90°. Calculate the area of ​​the target rectangle, all rotating rectangles, and oblique rectangles respectively, and record the minimum area among all enclosing methods. Calculate the difference between the area of ​​the target rectangle and the minimum area, divide the difference by the minimum area to obtain the area error, ensuring the error is ≤5%. This confirms that the currently constructed rectangle is the enclosing rectangle with the smallest area.

[0055] Step 205: Based on the spatial location and area of ​​the minimum enclosing rectangle and the communication load data of the nodes within the rectangle, the topology model is divided into regions, generating multiple continuous regions as structural units. Specifically, this includes: collecting the vertex coordinates (retained to 6 decimal places) and center point coordinates of each minimum enclosing rectangle. The center point coordinates are calculated by adding the maximum and minimum x-coordinate values ​​and dividing by 2, and adding the maximum and minimum y-coordinate values ​​and dividing by 2. When determining the edge spacing between adjacent rectangles, the coordinates of the four sides of each rectangle are extracted, and the vertical straight-line distance between the nearest edges of adjacent rectangles is calculated, ensuring that this distance is ≤10 meters. If the distance exceeds the limit, adjust the boundary coordinates of adjacent rectangles to ensure the spacing meets the requirements; collect the coordinate range of key traffic areas, and determine the maximum, minimum, maximum, and minimum values ​​of the horizontal and vertical coordinates of each key area (all rounded to 6 decimal places) to form a set of boundary coordinates for the key areas; calculate the total area of ​​the key areas by combining the difference between latitude and longitude coordinates with the Earth's surface distance conversion factor. The calculation method is: total area of ​​key areas = (maximum horizontal coordinate of key areas - minimum horizontal coordinate of key areas) × (maximum vertical coordinate of key areas - minimum vertical coordinate of key areas) × 111319.9, in square meters.

[0056] Determining the overlapping boundary between the rectangle and the key area involves comparing the x-coordinate range of the rectangle with that of the key area, taking the smaller of the two x-coordinate maximum values ​​as the maximum x-coordinate of the overlapping area, and taking the larger of the two x-coordinate minimum values ​​as the minimum x-coordinate of the overlapping area. Similarly, the smaller of the two y-coordinate maximum values ​​is taken as the maximum y-coordinate of the overlapping area, and the larger of the two y-coordinate minimum values ​​is taken as the minimum y-coordinate of the overlapping area, thus forming the boundary coordinates of the overlapping area. The overlapping area is calculated as: Overlapping Area = (Maximum x-coordinate of overlapping area - Minimum x-coordinate of overlapping area) × (Maximum y-coordinate of overlapping area - Minimum y-coordinate of overlapping area) × 111319.9, in square meters. The percentage of overlapping area is calculated as: Percentage = Overlapping Area ÷ Total area of ​​key area × 100%, requiring a percentage ≥ 90%. If this requirement is not met, the rectangle boundary is adjusted by expanding the maximum and minimum x-coordinate values ​​or the maximum and minimum y-coordinate values, and the overlapping area and percentage are recalculated until the requirement is met.

[0057] The area of ​​each rectangle is calculated using coordinate differences and conversion factors. The calculation method is: Area = (Maximum x-coordinate - Minimum x-coordinate) × (Maximum y-coordinate - Minimum y-coordinate) × 111319.9, in square meters. In urban road scenarios, if the rectangle area exceeds 800,000 square meters, it is evenly divided according to node distribution. First, the total number of nodes within the rectangle is counted, and then the nodes are evenly distributed according to the number of smaller rectangles after the division, ensuring that the number of nodes in each smaller rectangle differs by ≤2, and that the area of ​​each smaller rectangle after division is ≤800,000 square meters. If the area is less than 300,000 square meters, adjacent rectangles with spatial continuity and similar communication characteristics are selected and merged, with the merged area ≤800,000 square meters. In highway scenarios, rectangles with an area exceeding 1,200,000 square meters are evenly divided, and those less than 500,000 square meters are merged. The combined area is ≤1,200,000 square meters. Communication load data for each node within the rectangle is collected: the number of vehicles accessing the system during peak hours (7:00-9:00 AM and 5:00-7:00 PM), with ≤500 vehicles per unit on urban roads and ≤800 vehicles per unit on highways; total data packet transmission volume is ≤10GB per hour; data request frequency is ≤1000 times per second; simultaneously, communication latency, data packet delivery rate, and bandwidth utilization data for nodes within the rectangle are collected. The smallest enclosing rectangles with load levels (number of accessing vehicles, total data packets, request frequency) ≤20%, communication latency ≤10 milliseconds, data packet delivery rate ≤5%, and bandwidth utilization ≤10%, and with continuous spatial location, are integrated to ultimately generate multiple continuous areas, each of which is a structural unit.

[0058] In this embodiment, the construction of the topology model and the division of structural units clearly define specific thresholds such as area and spacing. Combined with the dual-mode communication characteristics of 5G and C-V2X, network management becomes more targeted, making it easier to focus on the communication characteristics of different areas for precise optimization.

[0059] In a preferred embodiment of the present invention, step 3, calculating and generating parameter correction amounts for optimizing terminal deployment and operating modes based on the network characteristics of the structural units, may include:

[0060] Step 301: Collect raw network characteristic data for each structural unit. This raw data includes the communication delay sequence, data packet delivery rate sequence, and bandwidth utilization sequence of nodes within the unit during a continuous monitoring period. Specifically, this includes: deploying data acquisition devices on all nodes of each structural unit, with the devices configured to reference the communication capabilities of the AG57XQ automotive-grade 5G NRSub-6 GHz communication module; setting the sampling frequency to 10 seconds / time; and specifying the measurement accuracy as communication delay ±1 millisecond, data packet delivery rate ±0.1%, and bandwidth utilization ±1%; setting the continuous monitoring duration to 72 hours, fully covering four time periods: morning peak 7:00-9:00, off-peak 9:00-17:00, evening peak 17:00-19:00, and nighttime low peak 19:00-7:00 the next day; collecting communication delay data for each node, specifically the total time from when a node sends a fixed-size 1KB data packet to when the receiver returns confirmation information, with statistical accuracy down to the millisecond level; and collecting... Data packet delivery rate data: each node sends a fixed 10 data packets in each sampling period, and the number of data packets successfully delivered to the receiver is divided by 10, with a statistical accuracy of 0.1%. Bandwidth utilization data: the actual communication bandwidth used by the node is divided by the total available bandwidth of the node. The total available bandwidth of urban road nodes is fixed at 100Mbps, and the total available bandwidth of highway nodes is fixed at 200Mbps. The collected data are recorded sequentially in chronological order to form the communication delay sequence, data packet delivery rate sequence, and bandwidth utilization sequence for each structural unit. Each sequence contains 60×60×72=259200 data points.

[0061] Step 302: Perform curve fitting calculations on the communication delay sequence, data packet delivery rate sequence, and bandwidth utilization sequence, respectively. The curve fitting calculation uses the sampling time as the independent variable and the corresponding index value as the dependent variable to generate a first mathematical relationship for communication delay over time, a second mathematical relationship for data packet delivery rate over time, and a third mathematical relationship for bandwidth utilization over time. Specifically, this includes: using the sampling time as the independent variable, where the sampling time is a specific time point after the start of monitoring, such as the 10th second or 20th second after the start of monitoring, with time accuracy down to the second; using the collected values ​​of the corresponding index as the dependent variable, i.e., the communication delay value, data packet delivery rate value, and bandwidth utilization value corresponding to each sampling time; firstly, clarify the definition of the correlation coefficient R², which is an index measuring the degree of fit between the data change trend and the fitted line, with a value range of 0 to 1. The closer the value is to 1, the higher the degree of fit between the data and the fitted line; analyze the data change trend of each sequence: if the data shows a linear change over time and the correlation coefficient R² ≥ 0.8, such as the communication delay gradually increasing during peak periods, the fitting process is as follows. First, list all sampling times and corresponding index values ​​for the sequence. Calculate the sum of squared vertical distances from each data point to the initial fitted line. By adjusting the slope and intercept of the fitted line, minimize the sum of squared distances to obtain the final trend line, ensuring the trend line slope error is ≤0.01. If the data exhibits non-linear changes and the correlation coefficient R² <0.8, such as a rapid decline in packet delivery rate followed by stabilization at the beginning of a peak, the fitting process is as follows: Divide the sequence into rapid change segments and stable segments according to data change characteristics. For rapid change segments, calculate the average rate of change of adjacent data points and fit the trend line for that segment based on the average rate of change. For stable segments, calculate the average value of all data points in that segment and fit the horizontal trend line based on the average value. After fitting, ensure that the average absolute value of the difference between the fitted value and the actual value within each segment is ≤0.05. If it exceeds this, re-divide the segments and adjust the fitting method. Through the above methods, generate the first mathematical relationship describing the change of communication delay over time, the second mathematical relationship describing the change of packet delivery rate over time, and the third mathematical relationship describing the change of bandwidth utilization over time.

[0062] Step 303: Based on the first, second, and third mathematical relationships, calculate the relationship output value of each mathematical relationship for a specified future prediction period. Based on the difference between each relationship output value and the actual indicator value of the corresponding sequence at the end of the monitoring period, calculate the communication delay change rate, data packet delivery rate change rate, and bandwidth utilization rate change rate. Combine these change rates according to pre-set weights to generate network performance evolution coefficients. Specifically, this includes: setting the specified future prediction period to 2 hours; first, performing linear fitting on the communication delay sequence to calculate the change slope. The data range is determined by selecting communication delay sampling data from 0:00 on the 71st hour to 0:00 on the 72nd hour, totaling 360 data points (sampling frequency 10 seconds / second). (Each time, 1 hour = 3600 seconds, 3600 ÷ 10 = 360); using the sampling time as the independent variable (unit: seconds, increasing sequentially from 0 seconds to 3590 seconds), and the communication delay value at the corresponding time as the dependent variable; summing the values ​​of the 360 ​​independent variables and dividing by 360 to obtain the average value 'a' of the independent variables; summing the values ​​of the 360 ​​dependent variables and dividing by 360 to obtain the average value 'h' of the dependent variables; calculating the difference between each independent variable and 'a', then multiplying by the difference between the corresponding dependent variable and 'h', and summing all the product results; calculating the square of the difference between each independent variable and 'a', and summing all the square results; dividing the slope numerator by the slope denominator to obtain the linear change slope 'k' of the communication delay sequence for the past 1 hour, with the slope calculation precision retained to 6 decimal places.)

[0063] Based on the slope k, the predicted communication delay value for each moment in the next 2 hours is calculated: There are 720 sampling moments in the next 2 hours (once every 10 seconds, 2×3600÷10=720). Each moment is calculated 3 times in the following way: The first calculation uses the adjusted slope. =k×(1-5%), taking the actual communication delay at the last sampling time of the 72nd hour as the benchmark, plus the time difference (in seconds) between that time and the benchmark time, multiplied by... The first prediction was 1; the second prediction used the original slope k, calculated with the same baseline and time difference as above, and was 2; the third prediction used the adjusted slope. =k×(1+5%), calculated using the same benchmark and time difference as above, yields a predicted value of 3; the final predicted value at each moment = (predicted value 1 + predicted value 2 + predicted value 3) ÷ 3, with the predicted value precision retained to 3 decimal places; similarly, for the data packet delivery rate sequence, 360 sampled data points from 0:00 to 0:00 on the 71st hour, 0:00 on the 72nd hour, 0:00 on the 72nd hour, 0:00 on the 71st hour, are selected, and the slope of change is calculated by performing linear fitting according to the above 6 steps. Then, the calculation is performed 3 times within the range of ±5% of the slope, and the average value is taken as the predicted value of the data packet delivery rate at each moment in the next 2 hours; for the bandwidth utilization rate sequence, the same process is followed to calculate the predicted value of the bandwidth utilization rate at each moment in the next 2 hours.

[0064] Extract the actual values ​​of communication latency (t), data packet delivery rate (p), and bandwidth utilization (b) at the last sampling moment of the 72nd hour, the end of the monitoring period. Calculate the average values ​​of the predicted values ​​for the next two hours: Average predicted communication latency T = (sum of all predicted communication latency values ​​for the next two hours) ÷ 720; Average predicted data packet delivery rate P = (sum of all predicted data packet delivery rates for the next two hours) ÷ 720; Average predicted bandwidth utilization B = (sum of all predicted bandwidth utilization values ​​for the next two hours) ÷ 720. Calculate the change rates, keeping the accuracy to 0.1%: Change rate of communication latency = (T - t) ÷ t × 100%; Change rate of data packet delivery rate = (P - p) ÷ p × 100%; Change rate of bandwidth utilization = (B - b) ÷ b × 100%.

[0065] Pre-defined weight allocation rules are established based on the core needs and priority of indicators in vehicle-road cooperative communication. The core principle of weight allocation is to prioritize real-time performance and reliability, while also considering transmission efficiency. The importance of indicators is ranked as follows: communication latency > data packet delivery rate = bandwidth utilization. The weight of communication latency variation rate ranges from 0.35 to 0.45: communication latency directly affects real-time decision-making in vehicle-road cooperation, such as conflict warning and speed adjustment. Excessive latency fluctuations can lead to decision lag and safety risks; therefore, a maximum weight range is set for this. (Urban road scenario traffic flow...) In densely populated areas with many intersections, latency sensitivity is higher, with a weight of 0.40 to 0.45. In highway scenarios with stable traffic flow, latency sensitivity is relatively lower, with a weight of 0.35 to 0.40. The weight for the data packet delivery rate change ranges from 0.25 to 0.35: the data packet delivery rate determines the reliability of data transmission. Loss of critical data such as vehicle location and road condition warnings can affect the collaborative effect, but the impact is less than that of latency, therefore its weight is lower than that of communication latency. In urban road scenarios with frequent data interaction, the delivery rate weight is 0.30 to 0.35. (The last sentence appears to be incomplete and possibly refers to a different scenario: highways.) The data volume in the scenario is relatively stable, so the delivery rate is weighted at 0.25 to 0.30; the bandwidth utilization change rate is weighted at 0.25 to 0.35: bandwidth utilization affects data transmission efficiency, and excessively high bandwidth utilization can lead to congestion, but this can be alleviated through dynamic capacity expansion. Its importance is comparable to that of the data packet delivery rate, hence the same weight range. Urban road scenarios have complex data types, including video and commands, and bandwidth requirements fluctuate greatly, so the weight is 0.30 to 0.35. Highway scenarios have relatively simple data types, so the bandwidth weight is 0.25 to 0.30. The weights of the three indicators are as follows. The sum of the values ​​must be 1.0 to ensure rigorous calculation logic. For example, in urban road scenarios, the weights for communication latency can be 0.42, data packet delivery rate 0.30, and bandwidth utilization 0.28. In highway scenarios, the weights for communication latency can be 0.38, data packet delivery rate 0.29, and bandwidth utilization 0.33. Multiply the rate of change in communication latency, the rate of change in data packet delivery rate, and the rate of change in bandwidth utilization by the corresponding selected weights, and then add the three products together to obtain the network performance evolution coefficient. The result is retained to three decimal places.

[0066] Step 304: Structural units whose network performance evolution coefficient exceeds a preset stability threshold are marked as structural units to be optimized. For structural units to be optimized, the output characteristics of the first, second, and third mathematical relations are analyzed. The network index corresponding to the mathematical relation whose output value deviates most from the normal range is determined as the dominant degradation index. Specifically, based on industry standards and the actual application requirements of the target road segment, the preset stability threshold for the network performance evolution coefficient is 0.2. When the absolute value of the evolution coefficient is > 0.2, the network performance fluctuation is determined to exceed the allowable range, and the structural unit is marked as a structural unit to be optimized. For each structural unit to be optimized, the first mathematical relation is analyzed. The output characteristics of the second and third mathematical relations are analyzed first. The normal range of each indicator is determined based on the network performance statistics of similar road segments: the normal range of communication latency is ≤50 milliseconds for urban roads and ≤30 milliseconds for highways; the normal range of data packet delivery rate is ≥95%; and the normal range of bandwidth utilization is ≤80%. The deviation between the predicted value of each mathematical relation and the normal range is calculated. If the predicted value exceeds the upper limit, the deviation is calculated as (predicted value - upper limit of normal range) / upper limit of normal range; if the predicted value is lower than the lower limit, the deviation is calculated as (lower limit of normal range - predicted value) / lower limit of normal range. The network indicator corresponding to the mathematical relation with the largest absolute value of deviation is determined as the dominant degradation indicator.

[0067] Step 305: Based on the dominant degradation index and according to the pre-established rules for matching index categories with optimization measures, generate a preliminary parameter adjustment plan; integrate the preliminary parameter adjustment plan, coordinate and arbitrate resource allocation conflicts and signal coverage overlaps involved in the plan, and generate parameter correction amounts, specifically including: pre-establishing the rules for matching index categories with optimization measures: if the dominant degradation index is communication latency, optimization measures include: increasing terminal transmission power, from 23dBm to 27dBm on urban roads (adjusted in 1dBm increments); increasing the number of communication resource blocks allocated, 2 to 4 (adjusted in 1-block increments); migration For some edge computing tasks, the reduction rate is 30% to 50% (adjusted in 10% increments). If the dominant degradation metric is packet delivery rate, optimization measures include: optimizing the communication protocol, adjusting packet retransmission parameters (retransmission interval from 50 milliseconds to 30 milliseconds, retransmission count from 3 to 5), adjusting signal reception sensitivity to ±2dBm (adjusted in 0.5dBm increments), reducing signal interference sources, avoiding 2.4GHz high-frequency interference areas, and adjusting antenna azimuth angle to ±10° (adjusted in 2° increments). If the dominant degradation metric is bandwidth utilization, optimization measures include: expanding communication bandwidth from 100M in urban areas. Expand Mbps to 120-140Mbps (adjusted in 10Mbps increments), and expand highway Mbps from 200Mbps to 240-280Mbps (adjusted in 20Mbps increments); optimize data transmission priority, giving control data higher priority than non-control data; compress data transmission volume to a compression ratio of 1:2 to 1:5 (adjusted in 1:1 increments); extract optimization measures from corresponding rules based on the dominant degradation index of the structural unit to be optimized, forming a preliminary parameter adjustment scheme; integrate all preliminary parameter adjustment schemes and check for resource allocation conflicts, such as multiple units to be optimized. Simultaneously, the application to add communication resource blocks may lead to insufficient total resources; or signal coverage may overlap, such as after increasing the transmission power, the signal overlap area of ​​adjacent units may be ≥30%; in response to resource conflicts, the structural units shall be sorted according to their importance, with core road segment units > general road segment units > edge road segment units, and the resource needs of key road segment units shall be given priority; in response to signal coverage overlap, the specific value of the transmission power shall be adjusted, reducing it by 5% to 10% (adjusted in 1% increments); or the antenna angle shall be adjusted by ±15° (adjusted in 3° increments), and the final parameter correction amount shall be generated after coordination and arbitration, with each parameter correction value retained to one decimal place or an integer place.

[0068] In this embodiment, the collection of raw network characteristic data clarifies the sampling frequency and monitoring duration parameters. Combined with specific methods for curve fitting and evolution coefficient calculation, it is possible to accurately grasp the real-time operating status and changing trends of structural units.

[0069] In a preferred embodiment of the present invention, step 4 involves determining the functional architecture of the roadside communication terminal based on the parameter correction amount. The functional architecture includes collaborative data processing, heterogeneous communication, and local control functions, and may include:

[0070] Step 401: Separate the terminal transmit power adjustment value, communication resource block allocation plan, and edge computing task migration scheme from the parameter correction values; based on the terminal transmit power adjustment value, generate power adjustment rules for the radio frequency transmission unit in the heterogeneous communication function, specifically including: extracting three types of core information one by one from the parameter correction values; differentiating the terminal transmit power adjustment value according to the scenario: extracting specific values ​​between 23dBm and 27dBm for urban road scenarios, and extracting specific values ​​between 25dBm and 30dBm for highway scenarios. The selection of values ​​needs to refer to the power output range of the AG57XQ automotive-grade communication hardware. The results of the road segment signal attenuation test; the communication resource block allocation plan extracts the specific allocation quantity and corresponding allocation time period of 2 to 4 resource blocks. The allocation time period is divided according to traffic flow characteristics into morning peak 7:00 to 9:00, evening peak 17:00 to 19:00, off-peak 9:00 to 17:00, and nighttime low peak 19:00 to 7:00 the next day. 3 to 4 resource blocks are allocated during peak hours, 2 to 3 resource blocks during off-peak hours, and 2 resource blocks during low-peak hours; the edge computing task migration scheme extracts the task migration ratio between 30% and 50%, and the migration task type (such as video data preprocessing, history...). Historical traffic data statistics and non-real-time road condition analysis are used to determine the target nodes for migration. Priority is given to selecting idle computing resources from adjacent roadside communication terminals; if no adjacent idle resources are available, cloud edge nodes are selected. Power adjustment rules for the radio frequency transmission unit are generated based on the terminal's transmit power adjustment value. These rules need to be dynamically adjusted according to time periods and communication load: During morning peak hours (7:00-9:00) and evening peak hours (17:00-19:00), the number of connected vehicles is counted in real-time via the vehicle-to-everything (V2X) direct link. When the number of connected vehicles exceeds 300, the upper limit of the adjustment value is applied; during off-peak hours (9:00-17:00), the number of connected vehicles is below 1000. When the number of vehicles is between 00 and 300, the system operates at the midpoint of the adjusted value. During the off-peak hours of 19:00 to 7:00 the next day, when the number of connected vehicles is less than 100, the system operates at the lower limit of the adjusted value. At the same time, the adjustment trigger conditions are clearly defined. Communication latency is monitored in real time through data acquisition equipment. When the communication latency exceeds 80% of the upper limit of the normal range and lasts for 10 seconds, the transmission power is automatically increased by 5%. The data packet delivery rate is statistically analyzed in real time through the communication protocol. When the data packet delivery rate is higher than 98% and lasts for 30 minutes, the transmission power is automatically reduced by 3%. The power adjustment is fed back to the local control function in real time, and the resource allocation status is updated synchronously.

[0071] Step 402: Based on power adjustment rules and communication resource block allocation plans, obtain the collaborative scheduling strategy for multi-mode communication in heterogeneous communication functions; according to the edge computing task migration scheme, determine the lower limit of data throughput and the upper limit of processing latency that the collaborative data processing function needs to meet, and obtain the collaborative data processing function architecture that meets the lower limit of data throughput and the upper limit of processing latency. Specifically, this includes: formulating a collaborative scheduling strategy for multi-mode communication based on power adjustment rules and communication resource block allocation plans, clarifying the application scenarios and resource allocation of 5G communication and C-V2X communication: when the vehicle speed is ≥60km / h and non-real-time data is transmitted (such as traffic condition statistics, historical data backup), 5G communication mode is enabled, 1 to 2 communication resource blocks are allocated, and high-speed transmission is achieved by relying on the 5G NR standalone networking capability of AG57XQ hardware; when the vehicle speed is <60km / h, near an intersection (≤500 meters from the intersection), or transmitting real-time control data (such as conflict warning instructions, lane change suggestions), C-V2X communication mode is enabled, 2 to 4 communication resource blocks are allocated, and 3GPP Rel-15 is utilized. C-V2X direct communication reduces latency; scheduling switching conditions are set, and the data packet delivery rate of C-V2X communication is monitored in real time through communication hardware. When the delivery rate is lower than 95% for 10 consecutive sampling periods (each sampling period is 10 seconds), it automatically switches to 5G communication mode; 5G communication latency is monitored in real time. When the latency exceeds 30 milliseconds for 5 consecutive sampling periods, it automatically switches to C-V2X communication mode. During the switching process, untransmitted data is retained through caching to avoid data loss.

[0072] The performance metrics for collaborative data processing functions are determined based on the edge computing task migration plan. If the task migration ratio in the migration plan is 30%, the lower limit of data throughput is calculated as 70% of the unmigrated level. Before migration, the urban road scenario processes 10GB of data per hour, and the highway scenario processes 20GB of data per hour. After migration, the urban road scenario processes at least 7GB of data per hour, and the highway scenario processes at least 14GB of data per hour. The upper limit of processing latency is controlled at 80% of the unmigrated level. Before migration, the processing latency for the urban road scenario is ≤50 milliseconds, and for the highway scenario it is ≤30 milliseconds. After migration, the processing latency for the urban road scenario is ≤80% of the unmigrated level. For video scenes, the latency should not exceed 40 milliseconds, and for highway scenes, it should not exceed 24 milliseconds. Based on the above indicators, a collaborative data processing functional architecture is constructed. The multi-core processor (at least 4 cores, with a main frequency of not less than 1.2GHz) and dedicated computing units are selected from the AG215S. A master core + slave core allocation method is adopted. The master core is responsible for task scheduling and multi-source data fusion. The slave cores are allocated according to task type. One slave core is responsible for video data frame parsing and feature extraction, one slave core is responsible for radar point cloud denoising and clustering, and one slave core is responsible for vehicle and pedestrian status data fusion. The cores exchange data through a high-speed bus to ensure that the throughput and latency requirements are met.

[0073] Step 403: Based on the edge computing task migration scheme, determine the execution logic of computing resource awareness and task offloading in the local control function; based on the collaborative data processing function architecture and execution logic, combined with the collaborative scheduling strategy, comprehensively generate a complete description of the roadside communication terminal functional architecture, specifically including: determining the execution logic of computing resource awareness and task offloading in the local control function according to the edge computing task migration scheme; computing resource awareness is performed in 10-second cycles, and the S32K144 microcontroller collects multi-core processor utilization, memory utilization, and remaining storage space data in real time; the collected data is transmitted to the local control logic via the CAN bus; when the processor utilization exceeds 80% for 15 seconds or the memory utilization exceeds 80% for 15 seconds... When the rate exceeds 75%, task unloading is triggered. Task unloading prioritizes non-real-time tasks, sorted by priority from low to high: historical data statistics, video data preprocessing, non-real-time traffic analysis, and real-time data caching. Historical data statistics tasks are unloaded first, followed by other non-real-time tasks. The unloading ratio strictly follows the migration plan of 30% to 50%. Before unloading, the resource idle status of the target node is checked through the communication link to ensure that the processor utilization rate of the target node is ≤50% and the memory utilization rate is ≤60%. The target node for unloading is an adjacent roadside communication terminal or a cloud edge node. During the unloading process, the transmitted data is encrypted through the HSM hardware encryption circuit to ensure data security.

[0074] Based on the collaborative data processing functional architecture, local control execution logic, and multi-mode communication collaborative scheduling strategy, a complete description of the roadside communication terminal functional architecture is generated, clarifying the connection relationship between the three types of functions: When the local control function senses the shortage of computing resources through the S32K144 microcontroller, it immediately sends a task migration notification to the collaborative data processing function. The collaborative data processing function adjusts the core allocation according to the remaining task load, shuts down unnecessary slave cores to save resources, and simultaneously sends a resource adjustment request to the heterogeneous communication function. After receiving the request, the heterogeneous communication function synchronously switches the communication mode and resource block allocation, prioritizing the transmission resources of real-time control data, ensuring a high degree of coordination among the three types of functions in resource usage and task execution.

[0075] Step 404 verifies the complete description to ensure that the power adjustment rules, collaborative scheduling strategy, and edge computing task migration scheme are consistent in terms of resources and timing. This ultimately determines the functional architecture of the roadside communication terminal. Specifically, this includes: comprehensively verifying the complete description of the functional architecture; checking at the resource level whether there is a conflict between the power resources required for adjusting the RF transmit power and the allocation of communication resource blocks; real-time monitoring of the power supply voltage using the voltage monitoring module of the power circuit; ensuring that the power supply voltage remains stable at 12V±0.5V when simultaneously increasing the transmit power to the upper limit and allocating 4 communication resource blocks during peak periods; and adjusting the transmit power increase or reducing the simultaneous allocation if the voltage fluctuation exceeds ±0.5V. The number of resource blocks is determined, and the redundant power supply capacity of the power circuit is increased if necessary. At the timing level, the trigger time of edge computing task migration and the communication mode switching time are checked for coordination. After the task migration is triggered, the communication mode switching is delayed by 2 seconds to avoid data packet loss caused by the superposition of data transmission and mode switching during the migration process. The data transmitted during the migration is temporarily stored through the data caching module, and the transmission continues after the switching is completed. At the same time, the logical consistency of the functional connection is verified to ensure that there are no contradictions between the resource perception results of the local control function, the task adjustment instructions of the collaborative data processing function, and the resource allocation scheme of the heterogeneous communication function. After verification, the functional architecture of the roadside communication terminal is finally determined.

[0076] In this embodiment, the process of determining the functional architecture fully combines parameter corrections with actual scenario requirements and integrates hardware performance characteristics, so that the functions of the roadside communication terminal are accurately adapted to the traffic characteristics and communication needs of different road sections, thereby improving the functionality and practicality.

[0077] In a preferred embodiment of the present invention, step 5, based on the functional architecture, configures hardware components and software protocols to implement collaborative data processing, heterogeneous communication, and local control functions, and establishes data interaction links between the roadside communication terminal and vehicles, the cloud, and adjacent roadside facilities, which may include:

[0078] Step 501: Based on the minimum data throughput and maximum processing latency required by the collaborative data processing functional architecture, select a multi-core processor and a dedicated computing unit as hardware components; based on the collaborative scheduling strategy, select dual-mode communication hardware components that support 5G mobile communication and vehicle-to-everything (V2X) direct communication; based on the execution logic of the local control function, select a microcontroller hardware component that supports real-time control, specifically including: based on the performance requirements of the collaborative data processing functional architecture, select a multi-core processor and a dedicated computing unit. The multi-core processor is the matching processor of the AG215S communication module, with at least 4 cores, a main frequency of not less than 1.2GHz, and support for parallel data processing. The dedicated computing unit is a dedicated chip that supports multi-source data fusion, ensuring that the hourly data processing volume meets the requirements of 7GB for urban roads and 14GB for highways, and that the processing latency is controlled within 40 milliseconds for urban roads and 24 milliseconds for highways; based on the multi-mode communication collaborative scheduling strategy, select AG57XQ automotive-grade 5G NRSub-6 GHz communication hardware, supporting the 3GPP Rel-15 standard and MIMO mode, and compatible with C-V2X PC5 direct communication and 5G. SA / NSA networking with 5.9GHz band communication capability to meet communication switching needs in different scenarios; based on the execution logic of local control functions, the S32K144 microcontroller is selected, which supports AEC-Q100 certification, has an ultra-low power mode, can communicate with other hardware components via CAN bus, and has a built-in encryption security engine to meet the control requirements of real-time resource awareness and task offloading; at the same time, supporting hardware is selected, including the XDSM3276 security chip (providing data encryption service), the RTL8211FI Ethernet chip (supporting Gigabit Ethernet transmission), the PCF8563T / 5RTC chip (providing a precise time base), and the power circuit (including power input, battery charging and discharging, and power switching sub-circuits).

[0079] Step 502: Integrate the multi-core processor with the dedicated computing unit, dual-mode communication hardware components, and microcontroller hardware components to form a complete hardware combination for the roadside communication terminal. Specifically, this includes: connecting the multi-core processor and the dedicated computing unit via a PCIe Gen3 interface with an interface transmission rate ≥8Gbps to achieve high-speed data transmission; connecting the multi-core processor and the AG57XQ communication hardware via a USB 2.0 interface with an interface bandwidth ≥480Mbps for data interaction and command transmission; and connecting the S32K144 microcontroller with the multi-core processor, power supply circuit, and XDSM3276 security chip via a CAN bus with a CAN bus communication rate of 500kbps to control the working status of each component. The power supply circuit supplies power to all hardware components via a power interface, with an output voltage of 12V. This provides stable power to the multi-core processor and communication hardware, and a 3.3V regulated power supply to the microcontroller and security chip. The XDSM3276 security chip connects to the AG57XQ communication hardware via an SPI interface with a speed of ≥10Mbps, providing data encryption and authentication services. The RTL8211FI Ethernet chip connects to the multi-core processor via an RGMII interface, supporting gigabit Ethernet speeds for video data transmission. All hardware components are integrated and fixed within a waterproof and dustproof IP67 enclosure. The enclosure has pre-drilled ventilation holes and interfaces to ensure adaptability to complex environments such as high and low temperatures, rain, snow, and dust.

[0080] Step 503: Based on the complete hardware combination, configure an execution environment for parallel data processing for the multi-core processor and dedicated computing unit; configure a set of multi-mode communication protocols for the dual-mode communication hardware components to implement a collaborative scheduling strategy; configure control logic for resource awareness and task offloading for the microcontroller hardware components; and generate a complete set of instructions and protocols. Specifically, this includes: configuring a parallel data processing execution environment for the multi-core processor and dedicated computing unit based on the complete hardware combination; installing the FreeRTOS operating environment; dividing data processing threads; allowing video data processing threads, radar data processing threads, and data fusion threads to run in parallel; prioritizing thread scheduling based on data real-time performance; prioritizing conflict warning-related data processing threads; and prioritizing historical data statistics threads. Data sharing is achieved through inter-thread communication. A set of multi-mode communication protocols is configured for the AG57XQ communication hardware, including the 3GPP Rel-15 C-V2X protocol (supporting PC5 direct communication) and 5G. The NR protocol (supporting SA / NSA networking) clarifies the triggering conditions and execution process for protocol switching, and implements automatic protocol invocation through hardware drivers. For example, when the C-V2X communication data packet delivery rate is below 95%, the driver automatically invokes the 5G NR protocol. Resource awareness and task offloading control logic is configured for the S32K144 microcontroller. The resource awareness logic collects hardware status data every 10 seconds, acquiring power supply voltage and processor temperature data through the ADC interface. The task offloading logic includes instructions such as task priority sorting, offloading ratio calculation, and target node selection, generating a complete set of control instructions. The above execution environment configuration, protocol set, and control instructions are integrated to generate a complete set of instructions and protocols.

[0081] Step 504: Load the complete instruction and protocol set into the complete hardware assembly for collaborative operation, completing the construction and debugging of the roadside communication terminal entity. Specifically, this includes: loading the complete instruction and protocol set into the multi-core processor and S32K144 microcontroller via USB interface, starting all hardware components, and performing collaborative debugging; debugging content includes: the data processing speed of the multi-core processor and dedicated computing unit, verifying whether the hourly data processing volume meets the requirements of 7GB for urban roads and 14GB for highways by inputting standard video streams and radar point cloud data, and whether the processing latency is controlled within the corresponding thresholds; and whether the switching between the two communication modes of the AG57XQ communication hardware is smooth, by simulating different traffic scenarios. Test whether the switching response time is ≤500 milliseconds, and whether the communication latency and data packet delivery rate meet the standards after switching; whether the microcontroller's resource awareness is accurate, by manually occupying different proportions of computing resources, to verify whether the deviation between the perceived result and the actual resource utilization rate is ≤3%, and whether the task unloading instruction can be executed normally; whether the power supply of each hardware component is stable, by continuously monitoring the power supply voltage through power monitoring tools to verify whether the voltage fluctuation is ≤±0.5V, and whether there are any power outages or voltage drops; for the problems found during debugging, adjust the instruction parameters or hardware connections, such as optimizing the thread scheduling strategy to improve data processing speed, adjusting the interface timing to improve the smoothness of communication switching, until all performance indicators meet the requirements and the construction of the terminal entity is completed.

[0082] Step 505: Based on the constructed and debugged roadside communication terminal entity, activate the dual-mode communication hardware component and the corresponding multi-mode communication protocol set to establish a vehicle-to-everything (V2X) direct data interaction link with the vehicle, a fifth-generation mobile communication uplink data interaction link with the cloud, and a wired or wireless backhaul data interaction link with adjacent roadside facilities. Specifically, this includes: based on the debugged terminal entity, activating the AG57XQ communication hardware and the corresponding multi-mode communication protocol set to establish three types of data interaction links: a vehicle-to-everything (V2X) direct data interaction link with the vehicle, and activating C-V2X... The PC5 direct communication protocol operates in the 5.9GHz band with a channel bandwidth of 20MHz. It is used to transmit real-time data between vehicles and roadside facilities (such as vehicle location and conflict warning commands). The 5G uplink data interaction link with the cloud uses the 5GNR protocol, accesses the local 5G network, selects SA networking mode, and has an uplink bandwidth of ≥100Mbps. It is used to upload status data (such as traffic flow statistics and equipment operating status) and receive dispatch commands to the cloud. The data interaction link with adjacent roadside facilities uses a gigabit vehicular Ethernet wired connection in urban road scenarios, using CAT.5UTP cable, with a transmission rate of ≥1Gbps, for transmitting local traffic sensing data. In highway scenarios, it uses wireless backhaul communication, using the IEEE 802.11p protocol, operating in the 5.9GHz band, with a transmission rate of ≥6Mbps.

[0083] Step 506: Based on the vehicle-to-everything (V2X) direct data interaction link, the 5G uplink data interaction link, and the wired or wireless backhaul data interaction link, test the connectivity of each link to verify whether the test results meet the performance requirements corresponding to the collaborative data processing function, heterogeneous communication function, and local control function. Establish the data interaction link, specifically including: conducting connectivity tests on the three types of data interaction links respectively: sending 1000 test data packets at 10-millisecond intervals to the test vehicles within the coverage area, each data packet being 1KB in size and containing a data packet number, sending timestamp, and terminal identifier fields. The confirmation information returned by the receiving vehicle must carry the corresponding data packet number. Count the number of data packets that are successfully received and return confirmation information, and the success rate of reception must be ≥99.5%; sending 100 status summary reports to the cloud platform, each report being 100KB in size, the reports being organized according to the preset field order, with a sending interval of 1 minute, and receiving the cloud platform feedback. The dispatch instructions must include a report number and a confirmation identifier, and the time difference from sending the report to receiving the instruction must be recorded, with an instruction feedback delay of ≤1 second. 100 sets of local traffic perception data are exchanged with adjacent roadside facilities at 30-second intervals. Each set of data is 500KB in size and includes data collection time, facility identification, and traffic element status information. After receiving the data, a checksum comparison (data byte accumulation and verification) is used to check data integrity, ensuring no data loss or tampering. The vehicle-to-everything (V2X) direct link uses the terminal's built-in latency statistics function to record the difference between the data packet sending time and the receiver's confirmation time, taking the average of 100 samples to ensure communication latency does not exceed 10 milliseconds. The 5G uplink uses bandwidth monitoring to calculate the ratio of actual bandwidth used to total available bandwidth during peak data transmission periods, ensuring bandwidth utilization does not exceed 80%. The roadside inter-link calculates the ratio of successfully exchanged data sets to the total number of exchanged data sets, ensuring a transmission success rate of at least 99%. After successful testing, the data interaction link is formally established.

[0084] In this embodiment, the establishment of data interaction links covers vehicles, roads, and the cloud. The combination of wired and wireless methods adapts to different scenarios. Link testing and verification ensure transmission stability, realize efficient transmission and sharing of multi-dimensional data, and ensure real-time information exchange.

[0085] In a preferred embodiment of the present invention, step 6, obtaining the status of traffic participation elements and cloud scheduling instructions through a data interaction link, and collecting roadside local data through local control functions, and generating initial collaborative control information after fusion, may include:

[0086] Step 601: Receive real-time status information sent by vehicle and pedestrian terminals through the vehicle-to-everything (V2X) direct data interaction link, extract position, speed, and heading angle data from the real-time status information, and generate a first traffic participation element status set. Specifically, this includes: continuously receiving real-time status information sent by vehicle and pedestrian terminals within the coverage area based on the C-V2X PC5 protocol through the vehicle-to-everything (V2X) direct data interaction link. Vehicle status information includes a unique vehicle identifier, WGS84 coordinate system position coordinates, driving speed, heading angle, and braking status; pedestrian status information includes a unique pedestrian identifier, WGS84 coordinate system position coordinates, moving speed, and moving direction. After receiving the data, the validity of the coordinates (longitude range ±180°, latitude range ±90°) and the reasonableness of the speed (vehicle speed ≤120km / h, pedestrian speed ≤10km / h) are verified, and invalid data is removed. From the valid data, the position coordinates (retained to 6 decimal places), driving speed (retained to integer places, unit km / h), and heading angle (retained to 1 decimal place, unit degree) are extracted, and sorted by vehicle and pedestrian categories. A unique identifier (terminal identifier, timestamp, and sequence number) is assigned to each data point, and the receiving timestamp is marked (accurate to the second), generating the first traffic participation element status set.

[0087] Step 602: Based on the first set of traffic participant statuses, a status summary report is sent to the cloud platform via the 5G uplink data interaction link. Specifically, this includes: based on the first set of traffic participant statuses, counting the total number of vehicles and pedestrians within the current coverage area; calculating the average driving speed using the arithmetic mean of all vehicle speeds; dividing the vehicle distribution area into 100m × 100m grids and counting the number of vehicles in each grid; and selecting grids with a pedestrian density ≥ 5 people / 100 square meters as densely populated pedestrian areas. A status summary report is generated according to a preset format, including a report generation timestamp (accurate to milliseconds), terminal identifier, total number of vehicles, total number of pedestrians, average driving speed, vehicle distribution grid data, densely populated pedestrian grid data, and data source identifier fields. The report is sent to the cloud platform once per minute via the 5G uplink data interaction link. Before sending, the report is digitally signed using the XDSM3276 security chip, and the signature is appended to the end of the report to ensure data integrity and authenticity. If retransmission is enabled during the sending process, and no confirmation is received from the cloud within 30 seconds after sending, the report will be resent. The maximum number of retransmissions is 3. If no confirmation is received after retransmission, an error will be recorded and the process will continue to retries.

[0088] Step 603: Based on the real-time dispatch instructions fed back from the status summary report, the cloud platform parses the signal priority control strategy and regional coordination scheme from the real-time dispatch instructions to generate a cloud dispatch instruction set. Specifically, this includes: receiving the real-time dispatch instructions fed back from the cloud platform based on the status summary report. The instructions are organized according to a preset protocol format and contain fields for signal priority control strategy and regional coordination scheme; splitting the instructions according to the protocol fields; parsing the intersection green light extension time (0 to 30 seconds), red light shortening time (0 to 20 seconds), and green light duration allocation information for left turn, straight, and right turn lanes from the signal priority control strategy; parsing the vehicle speed limit standard (30 to 80 km / h), tidal lane activation status, and traffic flow diversion direction information from the regional coordination scheme; and classifying and sorting this information according to instruction type (signal control, speed limit, lane allocation), applicable scope (specific intersection or road segment), and execution time (effective period) to generate a cloud dispatch instruction set.

[0089] Step 604: Receive local traffic sensing data from adjacent roadside facilities via a wired or wireless data exchange link. Perform spatiotemporal calibration and redundancy removal on the local traffic sensing data and the first set of traffic participation element states to generate an extended set of traffic participation element states. Specifically, this includes: receiving local traffic sensing data from adjacent roadside facilities via a wired or wireless data exchange link. The data contains vehicle and pedestrian status information for adjacent areas, and is labeled with data collection timestamps and sending facility identifiers. Perform spatiotemporal calibration on this data and the first set of traffic participation element states: convert the collection timestamps of adjacent data to local receiving timestamps, with a time difference controlled within ≤1 second; use a seven-parameter conversion method to convert the coordinates of adjacent data to the WGS84 coordinate system consistent with the local system, with a conversion error ≤0.5 meters; perform redundancy removal: first match data in the two sets according to the unique identifier of the vehicle or pedestrian, then compare the position coordinates of the matched data. If the position deviation corresponding to the same identifier is ≤1 meter, retain the latest status information in the local set and delete duplicate records in the adjacent data; if the identifier does not match, directly include it in the local set to generate the extended set of traffic participation element states.

[0090] Step 605: The control logic executed by the microcontroller hardware component activates the local video acquisition unit and radar sensing unit to acquire the original roadside video stream and point cloud sequence. Specifically, this includes: activating the local video acquisition unit and radar sensing unit through the control logic executed by the S32K144 microcontroller. The video acquisition unit uses a high-definition camera with a resolution of 1920×1080, a frame rate of 30 frames / second, a lens focal length of 8mm, and an exposure time of 1 / 50 second. It acquires video streams from roadside lanes, sidewalks, and intersections in H.264 format. The radar sensing unit uses a millimeter-wave radar with a detection range of 0 to 200 meters, a detection accuracy of ±0.5 meters, a detection angle of ±60°, and a sampling frequency of 10Hz. It acquires distance, speed, and azimuth information of roadside targets to form a point cloud sequence in binary format. The original video stream and point cloud sequence are continuously acquired, and the acquisition timestamps (accurate to milliseconds) are marked. The data is then transmitted via the vehicle Ethernet to the storage unit of the multi-core processor for temporary storage using the TCP / IP protocol.

[0091] Step 606: Using the execution environment, feature extraction and target vectorization processing are performed on the original roadside video stream and point cloud sequence to generate structured local perception results. Specifically, this includes: using a parallel processing execution environment with multi-core processors and dedicated computing units, frame parsing is performed on the original roadside video stream to extract features such as vehicle contours (represented by bounding box coordinates), license plates (character recognition results), driving trajectories (sequence of bounding box center coordinates in consecutive frames), and pedestrian contours (bounding box coordinates) and movement trajectories (sequence of bounding box center coordinates in consecutive frames) frame by frame; noise reduction processing is performed on the point cloud sequence to remove points with abnormal distances (exceeding the range of 0 to 200 meters) and abnormal intensity (below the threshold of -60dBm), and then clustering processing is performed according to distance and azimuth angle to extract the target's three-dimensional coordinates, movement speed, and size (length × width × height) information. These features and information are vectorized to represent the target state using structured data. Each result includes target identifier (camera or radar identifier, timestamp, serial number), type (vehicle or pedestrian), location coordinates (WGS84 coordinate system), speed, heading angle, acquisition timestamp, and confidence level (between 0.3 and 1.0, with higher values ​​indicating higher confidence), generating structured local perception results.

[0092] Step 607 involves fusing and matching the structured local perception results with the extended traffic participation element state set. For successfully matched traffic elements, the structured local perception results are used for state correction and confidence enhancement to generate a high-confidence fused traffic situation. Specifically, this includes: fusing and matching the structured local perception results with the extended traffic participation element state set, using location coordinates as the core matching basis, combined with speed and heading angle auxiliary information, calculating the Euclidean distance between target positions in the two sets, and determining the same traffic element when the distance is ≤1 meter; for successfully matched traffic elements, the structured local perception results are used to correct the state information in the extended set, for example, using the precise speed detected by radar to correct the speed reported by the vehicle, and calculating the final state value by a confidence-weighted average (structured local perception results weight 0.7, extended set results weight 0.3) to improve data credibility; for unmatched traffic elements (such as pedestrians perceived locally but not included in the extended set, or unique targets in adjacent areas), they are directly included in the fusion result. The final result is a high-confidence fused traffic situation report, which includes accurate status information and confidence scores (between 0.3 and 1.0) for all traffic elements. Elements with confidence scores below 0.5 are marked as low confidence.

[0093] Step 608: Based on the signal priority control strategy and regional coordination scheme, and combined with high-confidence fused traffic situation, calculate and generate initial collaborative control information including lane allocation suggestions, recommended speeds, and conflict warnings. Specifically, this includes: lane allocation suggestions are determined by statistically analyzing the vehicle density of each lane (lane length divided by the number of vehicles in that lane), guiding vehicles to the lane with the lowest density; guidance instructions include the target lane number and lane change timing suggestions (e.g., prohibiting lane changes within 100 meters of an intersection); recommended speeds are calculated based on the road segment speed limit, vehicle density, and distance to the vehicle in front; the road segment speed limit is determined by cloud-based instructions. When the vehicle density is ≥20 vehicles / km, a 20% speed reduction is recommended; when the distance to the vehicle in front is < a safe distance (5 meters on urban roads, 10 meters on highways), a 30% speed reduction is recommended to ensure safe and efficient vehicle operation. Conflict warning information is calculated based on the position, speed, and direction of movement of vehicles and pedestrians. Based on the current speed and heading angle, the trajectory is determined within the next 5 seconds. When the probability of trajectory overlap is ≥30%, a warning is generated, including the conflict object identifier, warning level, and avoidance suggestions. Initial cooperative control information includes the instruction type, applicable object identifier, execution requirements, and effective time (≤30 seconds).

[0094] In this embodiment, the initial collaborative control information is generated by integrating multi-source data and cloud commands, combined with precise perception and matching methods, to comprehensively reflect the traffic situation and make the control information more rational.

[0095] In a preferred embodiment of the present invention, step 7, optimizing and adjusting the initial cooperative control information based on the parameter correction amount to generate the final cooperative control information, may include:

[0096] Step 701: Extract the terminal transmit power adjustment value from the parameter correction amount. Based on the terminal transmit power adjustment value, adjust the transmit power of the conflict warning information to generate the first intermediate control information. Specifically, this includes: extracting the terminal transmit power adjustment value from the parameter correction amount, taking values ​​according to the scenario: a specific value between 23dBm and 27dBm for urban road scenarios, and a specific value between 25dBm and 30dBm for highway scenarios; and adjusting the transmit power of the conflict warning information in the initial cooperative control information based on this adjustment value. The adjustment logic is that for every 1dBm increase in transmit power, the effective transmission distance of the conflict warning information increases by 10 meters, while maintaining the edge signal strength of the signal coverage area. ≥-75dBm; for every 1dBm decrease in transmission power, the effective transmission distance is reduced by 8 meters, ensuring that the signal strength in the core coverage area remains at ≥-65dBm; for example, in urban road scenarios, if the transmission power is adjusted from 23dBm to 27dBm, the effective transmission distance of the conflict warning information increases from the initial 300 meters to 340 meters, covering more distant vehicles; in highway scenarios, if the transmission power is adjusted from 25dBm to 30dBm, the effective transmission distance increases from 500 meters to 550 meters; after the adjustment, the original content of the conflict warning information is retained, including the conflict object identification, warning level (Level 1 / Level 2 / Level 3), and avoidance suggestions (slow down / avoid / stop), only the transmission power parameters are updated to generate the first intermediate control information.

[0097] Step 702: Based on the first intermediate control information and the communication resource block allocation plan, the data transmission priority and time slots of various control information in the first intermediate control information are allocated and adjusted to generate the second intermediate control information. Specifically, this includes: obtaining the communication resource block allocation plan in the parameter correction amount, clarifying the number of resource blocks allocated in the current time period (2 to 4) and the total number of available time slots, and pre-setting that each resource block corresponds to 8 time slots, with each time slot having a fixed duration of 0.5 milliseconds and a total duration of 4 milliseconds for a single resource block; based on the first intermediate control information, the data transmission priority is divided according to the control information type, with the priority from high to low being conflict warning information, recommended vehicle speed, and lane allocation suggestion. High-priority conflict warning information occupies all time slots of the first two resource blocks, totaling 16 time slots, to ensure real-time transmission without delay; medium-priority recommended vehicle speeds occupy the first four time slots of the third resource block, with a duration of 2 milliseconds; low-priority lane allocation suggestions occupy the last four time slots of the third resource block and all time slots of the fourth resource block (if allocated); at the same time, the time slot reuse strategy is adjusted according to the vehicle distribution density. When the vehicle density is ≥30 vehicles / km, each time slot carries only 10 control information messages; when the vehicle density is <30 vehicles / km, each time slot can carry 20 control information messages to avoid time slot congestion; after the allocation adjustment is completed according to the above rules, the second intermediate control information is generated.

[0098] Step 703: Based on the edge computing task migration scheme and the second intermediate control information, adjust the generation logic of lane allocation suggestions and recommended vehicle speeds to generate third intermediate control information. Specifically, this includes: extracting the task migration ratio (30% to 50%), migration task type, and target node from the edge computing task migration scheme; adjusting the generation logic of lane allocation suggestions according to the migration ratio; and pre-setting lane usage rules including fixed usage periods for tidal lanes (morning peak 7:00 to 9:00 for inbound traffic and evening peak 17:00 to 19:00 for outbound traffic) and the emergency lane being prohibited all day (non-emergency rescue vehicles are not allowed to occupy it). If the migration ratio is ≥40%, it indicates that local computing power is relatively strained, and lane allocation suggestions will be generated primarily based on the above pre-set rules to reduce [the risk of accidents]. Real-time traffic density calculation; if the migration ratio is <40%, then lane occupancy rate data (occupancy rate = number of vehicles in the lane ÷ maximum number of vehicles the lane can accommodate) is combined with real-time high-confidence fusion traffic situation data to dynamically allocate lane usage permissions, prioritizing lanes with an occupancy rate <50%; regarding the generation logic of recommended vehicle speed, when the migration task includes video data preprocessing, the recommended vehicle speed calculation no longer incorporates the vehicle spacing data from video recognition, but is generated only based on radar detection data and road segment speed limit standards; when the migration task is a non-real-time analysis type, the recommended vehicle speed generation logic remains unchanged, still comprehensively calculating based on radar, video, and cloud speed limit instructions; the lane allocation suggestions and recommended vehicle speed content in the second intermediate control information are updated according to the adjusted logic to generate the third intermediate control information.

[0099] Step 704: Based on the high-confidence fused traffic situation, verify the third intermediate control information, correct any instructions that contradict the traffic situation, and generate the fourth intermediate control information. Standardize and encapsulate the fourth intermediate control information to generate the final collaborative control information. This includes: calling traffic element status data from the high-confidence fused traffic situation, including vehicle position, speed, lane occupancy, and pedestrian distribution, and verifying each item of the third intermediate control information. Verification dimensions include whether the lane allocation suggestion contradicts the current lane occupancy rate (e.g., suggesting vehicles enter congested lanes with an occupancy rate ≥ 80%), whether the recommended speed exceeds the actual feasible range of the road segment (e.g., exceeding the current average traffic speed by more than 30%), and whether the conflict warning information is consistent with the actual movement trajectory of traffic elements (e.g., warning of non-existent collision risks). If a contradiction is found, correct the instructions based on the traffic situation data. For example, adjust the lane allocation suggestion to the lane with the lowest current occupancy rate, correct the recommended speed to 1.1 times the current average traffic speed, delete conflict warning information items that do not conflict with the actual trajectory, and generate the fourth intermediate control information. The fourth intermediate control information is encapsulated in a standardized format. The preset instruction field order is instruction type, applicable object identifier, execution requirement, effective time, generation timestamp, and terminal identifier. The execution requirement is preset to be explicitly stated as "execute immediately" or "complete within the specified time limit". The effective time is uniformly expressed in seconds, the generation timestamp is accurate to the millisecond level, and the terminal identifier is a preset unique device number (such as LT-2025001). The field data format is uniform according to preset rules, with speed in km / h, time in seconds, and position coordinates retained to 6 decimal places. Finally, the final collaborative control information with a unified structure and accurate content is generated.

[0100] This embodiment optimizes the control information process based on parameter correction, combining specific preset rules and hardware characteristics to ensure that the collaborative control information is highly adapted to the terminal's operating status, thereby improving the real-time performance and reliability of command transmission.

[0101] In a preferred embodiment of the present invention, step 8, encapsulating the final collaborative control information and distributing it to the vehicle and cloud platform to complete the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal, may include:

[0102] Step 801: Encapsulate the final collaborative control information in a communication protocol format to generate a vehicle-to-everything (V2X) direct communication protocol data unit and a fifth-generation mobile communication uplink protocol data unit. Specifically, this includes: encapsulating the final collaborative control information in a communication protocol format to adapt to the protocol requirements of the two types of communication links. For the direct data interaction link of vehicle-to-everything (V2X) communication, the 3GPP Rel-15 C-V2X PC5 protocol is used for encapsulation to generate V2X direct communication protocol data units. The default protocol header version number is V1.0, the message type is cooperative control instruction, and the priority field corresponds to the control information priority (high, medium, low). The protocol header length is fixed at 16 bytes. The core business data is the complete content of the final cooperative control information, including conflict warning information, recommended vehicle speed, lane allocation suggestion control instructions and instruction types, and applicable object identification fields. The checksum is based on the SM3 hash operation of the XDSM3276 security chip. After the core business data is processed, a 32-byte checksum is obtained and appended to the end of the data unit. For the uplink data interaction link of 5G mobile communication, the 5GNR protocol is used for encapsulation to generate 5G mobile communication uplink protocol data units. The default packet header includes terminal identifier, data length, and timestamp fields. The packet header length is 24 bytes. The payload data is the final cooperative control information. The integrity protection field is based on SM4 encryption processing. The packet header and payload data are encrypted to generate a 16-byte protection field to ensure data transmission security.

[0103] Step 802: Based on the vehicle-to-everything (V2X) direct communication protocol data unit, generate a set of distribution instructions for vehicle broadcasting; based on the fifth-generation mobile communication uplink protocol data unit, generate a set of distribution instructions for uploading to the cloud platform. Specifically, this includes: generating a set of distribution instructions for vehicle broadcasting based on the V2X direct communication protocol data unit; the set includes a preset broadcast range, i.e., all vehicles within the terminal's coverage area, a circular area centered on the terminal and with the effective transmission distance as the radius; preset broadcast interval of 100 milliseconds / time, 3 retransmissions, broadcast frequency band of 5.9 GHz and specific channel 178, etc., specifying the broadcast timing corresponding to each protocol data unit, and strictly executing according to the time slot allocated in step 702; generating a set of distribution instructions for uploading to the cloud platform based on the fifth-generation mobile communication uplink protocol data unit, preset the target cloud address as the vehicle-road cooperative cloud platform IP (192.168.1.100) and port (8080), upload frequency of 30 seconds / time, upload priority as high priority, and retransmission after 30 seconds if no confirmation is received, etc., to ensure timely data upload.

[0104] Step 803: Based on the distribution instruction set for vehicle broadcasting, the dual-mode communication hardware component is invoked to broadcast vehicle-to-everything (V2XPC5) direct-connection communication protocol data units to vehicles within the coverage area via the V2XPC5 direct-connection data interaction link. Specifically, this includes: based on the distribution instruction set for vehicle broadcasting, invoking the AG57XQ dual-mode communication hardware component, enabling the C-V2XPC5 direct-connection communication mode, and sending V2XPC5 direct-connection communication protocol data units via the V2XPC5 direct-connection data interaction link according to the broadcast range, interval, and time slot requirements in the instruction set; during the broadcast, the dual-mode communication hardware component monitors the channel occupancy in real time through its built-in channel detection function. If the channel occupancy rate is >80%, the broadcast interval is automatically extended to 150 milliseconds; if the channel occupancy rate is <50%, the 100-millisecond interval remains unchanged; after each broadcast, the broadcast timestamp and the number of covered vehicles are recorded, and the signal strength statistics are obtained by receiving feedback from the vehicles.

[0105] Step 804: Based on the distribution instruction set, the dual-mode communication hardware component is invoked to send 5G uplink protocol data units to the cloud platform via the 5G uplink data interaction link. Specifically, this includes: based on the distribution instruction set uploaded to the cloud platform, the AG57XQ dual-mode communication hardware component is invoked to enable 5G NR communication mode (SA networking), and the 5G uplink protocol data units are sent to the preset cloud platform IP and port via the 5G uplink data interaction link; before sending, the data units are digitally signed by the XDSM3276 security chip, and the signature result is appended to the integrity protection field; during the sending process, flow control is enabled, and the real-time bandwidth of the 5G link is obtained through the component's built-in bandwidth monitoring function, and the sending rate is adjusted to 80% of the real-time bandwidth to ensure that the bandwidth utilization does not exceed 80%; if no confirmation information is received from the cloud within 30 seconds after sending, retransmission is performed as required by the instruction set, with a maximum of 3 retransmissions. If no confirmation is received, an anomaly is recorded and sending is continuously attempted, while triggering a local alarm.

[0106] Step 805: Based on the broadcast-based vehicle-to-everything (V2X) direct communication protocol data unit, receive the protocol reception confirmation message returned by the vehicle through the V2X direct data interaction link; based on the transmitted 5G uplink protocol data unit, receive the protocol reception confirmation message returned by the cloud platform through the 5G uplink data interaction link. Based on the successful reception of both types of confirmation messages, a control information distribution completion confirmation signal is generated. Specifically, this includes: continuously monitoring the V2X direct data interaction link, receiving the protocol reception confirmation message returned by the vehicle (the confirmation message includes the vehicle identifier, the received protocol data unit number, and the reception timestamp), and calculating the proportion of vehicles receiving confirmation to the total number of vehicles covered by the broadcast (a preset proportion ≥95% is considered successful reception at the vehicle end); simultaneously monitoring the 5G uplink data interaction link, receiving the protocol reception confirmation message returned by the cloud platform (the confirmation message includes the platform confirmation identifier, the received data integrity verification result, and the processing status; a preset verification result of "passed" and a processing status of "received" are considered successful cloud reception); when both the vehicle end and the cloud end successfully receive the message, a control information distribution completion confirmation signal is generated, including the distribution completion timestamp, the number of successfully receiving vehicles, the cloud reception status, and terminal identification information.

[0107] Step 806: Based on the confirmation signal for the completion of control information distribution, perform full-process functional verification from traffic participation element collection, integrated traffic situation generation, collaborative control information optimization, protocol encapsulation to information distribution, completing the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal. Specifically, this includes: based on the confirmation signal for the completion of control information distribution, initiating the full-process functional verification of the vehicle-road-cloud collaborative roadside communication terminal; the verification process covers five key stages, each verified according to preset performance indicators: Traffic participation element collection stage, preset continuous collection for 1 hour with no data packet loss, video frame parsing success rate ≥99%, radar point cloud data integrity ≥98%; Integrated traffic situation generation stage, preset average confidence level of all traffic elements ≥0.6, position deviation ≤0.5 meters; Collaborative control information optimization stage, preset parameter correction accuracy ≥95%, optimized instructions without logical contradictions; Protocol encapsulation stage, preset protocol format conforms to 3GPPRel-15 and 5GNR standards, encrypted data decryption success rate 100%; Information distribution stage, preset link connectivity 100%, data transmission success rate ≥99%. After all aspects meet the requirements, confirm that the terminal functions are fully compliant and complete the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

[0108] This embodiment ultimately helps to improve the efficient operation of vehicle-road-cloud collaboration and enhance the safety and intelligence of traffic flow through precise control information optimization and reliable distribution methods.

[0109] like Figure 2As shown, embodiments of the present invention also provide a design apparatus for a vehicle-road-cloud collaborative roadside communication terminal, comprising:

[0110] The deployment module plans the deployment area of ​​the target road segment and determines the first, second, and third key deployment locations. The first key deployment location corresponds to the road segment entrance area, the second key deployment location corresponds to the core area of ​​the middle section of the road segment, and the third key deployment location corresponds to the road segment exit area.

[0111] The partitioning module establishes a topology model based on three key deployment locations; it then partitions the topology model to generate structural units.

[0112] The calculation module, based on the network characteristics of the structural units, calculates and generates parameter correction quantities for optimizing terminal deployment and working modes;

[0113] The module is determined based on the parameter correction amount, and the functional architecture of the roadside communication terminal is determined. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function.

[0114] The configuration module, based on the functional architecture, configures the hardware components and software protocols that enable collaborative data processing, heterogeneous communication and local control functions, and establishes data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities.

[0115] The fusion module obtains the status of traffic participants and cloud scheduling instructions through data interaction links, while the local control function collects local roadside data and generates initial collaborative control information after fusion.

[0116] The optimization module optimizes and adjusts the initial cooperative control information based on the parameter correction amount to generate the final cooperative control information;

[0117] The distribution module encapsulates the final collaborative control information and distributes it to vehicles and the cloud platform, completing the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

[0118] It should be noted that this device is a device corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0119] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0120] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A design method for a roadside communication terminal for vehicle-road-cloud collaboration, characterized in that, The method includes: Step 1: Plan the deployment area of ​​the target road segment and determine the first critical deployment location, the second critical deployment location, and the third critical deployment location. The first critical deployment location corresponds to the entrance area of ​​the road segment, the second critical deployment location corresponds to the core area of ​​the middle section of the road segment, and the third critical deployment location corresponds to the exit area of ​​the road segment. Step 2: Establish a topology model based on three key deployment locations; partition the topology model to generate structural units; Step 3: Based on the network characteristics of the structural units, calculate and generate parameter correction values ​​for optimizing terminal deployment and working modes; Step 4: Determine the functional architecture of the roadside communication terminal based on the parameter correction amount. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function. Step 5: Based on the functional architecture, configure the hardware components and software protocols to implement collaborative data processing, heterogeneous communication and local control functions, and establish data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities. Step 6: Obtain the status of traffic participants and cloud scheduling instructions through the data interaction link; collect local roadside data through local control function; and generate initial collaborative control information after fusion. Step 7: Based on the parameter correction amount, optimize and adjust the initial cooperative control information to generate the final cooperative control information; Step 8: Encapsulate the final collaborative control information and distribute it to the vehicle and cloud platform to complete the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

2. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 1, characterized in that, A topology model was established based on three key deployment locations; The topology model is partitioned to generate structural units, including: Based on the geographic coordinates of the first, second, and third key deployment locations, establish a connection between the three key deployment locations to generate an initial topology describing the backbone connection of the target road segment; Based on the initial topology, according to the preset communication coverage radius of the roadside communication terminal, multiple auxiliary nodes are inserted at equal intervals on the line connecting every two adjacent key deployment locations to generate a topology model that includes all core nodes and auxiliary nodes as well as the connection relationships between nodes. Based on the topological model, nodes with adjacent geographical locations are connected according to the spatial distribution of nodes in the model to form multiple candidate polygon regions. For each candidate polygon region, calculate the minimum bounding rectangle, which is the rectangle with the smallest area that can completely enclose all vertices of the corresponding polygon and whose sides are parallel to the geographic coordinate axes. Based on the spatial location and area of ​​the minimum enclosing rectangle and the communication load data of the nodes within the rectangle, the topology model is divided into regions, generating multiple continuous regions as structural units.

3. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 2, characterized in that, Based on the network characteristics of structural units, parameter correction quantities are calculated and generated to optimize terminal deployment and operating modes, including: Collect raw network characteristic data for each structural unit. The raw network characteristic data includes the communication delay sequence, data packet delivery rate sequence, and bandwidth utilization sequence of the nodes within the unit during a continuous monitoring period. Curve fitting calculations are performed on the communication delay sequence, data packet delivery rate sequence, and bandwidth utilization sequence, respectively. The curve fitting calculations take the sampling time as the independent variable and the corresponding index value as the dependent variable to generate a first mathematical relationship of communication delay changing with time, a second mathematical relationship of data packet delivery rate changing with time, and a third mathematical relationship of bandwidth utilization changing with time. Based on the first, second, and third mathematical relationships, the relationship output values ​​of each mathematical relationship are calculated for a specified prediction time in the future. Based on the difference between each relationship output value and the actual indicator value of the corresponding sequence at the end of the monitoring period, the communication delay change rate, data packet delivery rate change rate, and bandwidth utilization rate change rate are calculated. The above change rates are combined according to the pre-set weights to generate network performance evolution coefficients. Structural units whose network performance evolution coefficients exceed a preset stability threshold are marked as structural units to be optimized. For structural units to be optimized, the output characteristics of the first, second, and third mathematical relations are analyzed, and the network index corresponding to the mathematical relation whose output value deviates the most from the normal range is determined as the dominant degradation index. Based on the dominant degradation index, and according to the pre-established rules for the correspondence between index categories and optimization measures, a preliminary parameter adjustment plan is generated. The preliminary parameter adjustment plan is then integrated, and resource allocation conflicts and signal coverage overlaps involved in the plan are coordinated and arbitrated to generate parameter correction amounts.

4. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 3, characterized in that, Based on the parameter correction values, the functional architecture of the roadside communication terminal is determined. The functional architecture includes collaborative data processing, heterogeneous communication, and local control functions, including: The terminal transmit power adjustment value, communication resource block allocation plan, and edge computing task migration scheme are extracted from the parameter correction values; based on the terminal transmit power adjustment value, the power adjustment rules of the radio frequency transmit unit in the heterogeneous communication function are generated. Based on power adjustment rules and communication resource block allocation plans, a collaborative scheduling strategy for multi-mode communication in heterogeneous communication functions is obtained; according to the edge computing task migration scheme, the lower limit of data throughput and the upper limit of processing latency that the collaborative data processing function needs to meet are determined, and a collaborative data processing function architecture that meets the lower limit of data throughput and the upper limit of processing latency is obtained. Based on the edge computing task migration scheme, the execution logic of computing resource awareness and task offloading in the local control function is determined; based on the collaborative data processing function architecture and execution logic, combined with the collaborative scheduling strategy, a complete description of the roadside communication terminal functional architecture is generated. The complete description was verified to ensure that the power adjustment rules, collaborative scheduling strategies and edge computing task migration schemes were consistent in terms of resources and timing, and the functional architecture of the roadside communication terminal was finally determined.

5. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 4, characterized in that, Based on the functional architecture, hardware components and software protocols are configured to implement collaborative data processing, heterogeneous communication, and local control functions. Data interaction links are established between the roadside communication terminal and vehicles, the cloud, and adjacent roadside facilities, including: Based on the minimum data throughput and maximum processing latency required by the collaborative data processing functional architecture, multi-core processors and dedicated computing units were selected as hardware components; based on the collaborative scheduling strategy, dual-mode communication hardware components supporting 5G mobile communication and vehicle-to-everything (V2X) direct communication were selected; based on the execution logic of the local control function, microcontroller hardware components supporting real-time control were selected. The roadside communication terminal integrates a multi-core processor with a dedicated computing unit, dual-mode communication hardware components, and microcontroller hardware components to form a complete hardware combination. Based on the complete hardware combination, an execution environment for data parallel processing is configured for multi-core processors and dedicated computing units, a set of multi-mode communication protocols for implementing cooperative scheduling strategies is configured for dual-mode communication hardware components, and control logic for resource awareness and task offloading is configured for microcontroller hardware components, generating a complete set of instructions and protocols. The complete set of instructions and protocols is loaded into the complete hardware assembly to work together and complete the construction and debugging of the roadside communication terminal entity; Based on the roadside communication terminal entity that has been constructed and debugged, dual-mode communication hardware components and the multi-mode communication protocol set corresponding to dual-mode communication hardware components are enabled to establish a vehicle-to-everything (V2X) direct data interaction link with vehicles, a fifth-generation mobile communication uplink data interaction link with the cloud, and a wired or wireless backhaul data interaction link with adjacent roadside facilities. Based on the vehicle-to-everything (V2X) direct data interaction link, the 5G uplink data interaction link, and the wired or wireless backhaul data interaction link, the connectivity of each link was tested to verify whether the test results met the performance requirements corresponding to the collaborative data processing function, heterogeneous communication function, and local control function, and a data interaction link was established.

6. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 5, characterized in that, The status of traffic participants and cloud-based dispatch instructions are obtained through data interaction links. Local control functions collect roadside local data, which is then fused to generate initial collaborative control information, including: Through the vehicle-to-everything (V2X) direct data interaction link, the system receives real-time status information sent by vehicle and pedestrian terminals, extracts position, speed and heading angle data from the real-time status information, and generates the first traffic participation element status set. Based on the status set of the first traffic participation elements, a status summary report is sent to the cloud platform through the uplink data interaction link of the fifth generation mobile communication. Based on the real-time dispatch instructions fed back from the status summary report, the cloud platform parses the signal priority control strategy and regional coordination scheme from the real-time dispatch instructions to generate a set of cloud dispatch instructions; Through wired or wireless data exchange links, local traffic perception data sent by adjacent roadside facilities is received. The local traffic perception data and the first set of traffic participation element states are spatiotemporally calibrated and redundancy removed to generate an extended set of traffic participation element states. The control logic executed by the microcontroller hardware components activates the local video acquisition unit and radar sensing unit, thereby acquiring the original roadside video stream and point cloud sequence. Using the execution environment, feature extraction and target vectorization are performed on the original roadside video stream and point cloud sequence to generate structured local perception results; The structured local perception results are fused and matched with the extended traffic participation element state set. For the successfully matched traffic elements, the structured local perception results are used to correct the state and improve the confidence, generating a high-confidence fused traffic situation. Based on the signal priority control strategy and regional coordination scheme, and combined with high-confidence fusion traffic situation, initial collaborative control information including lane allocation suggestions, recommended vehicle speeds and conflict warning information is calculated and generated.

7. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 6, characterized in that, Based on the parameter correction, the initial cooperative control information is optimized and adjusted to generate the final cooperative control information, including: Extract the terminal transmit power adjustment value from the parameter correction amount, adjust the transmit power of the conflict warning information based on the terminal transmit power adjustment value, and generate the first intermediate control information; Based on the first intermediate control information and the communication resource block allocation plan, the data transmission priority and time slot of various control information in the first intermediate control information are allocated and adjusted to generate the second intermediate control information; Based on the edge computing task migration scheme and the second intermediate control information, the generation logic of lane allocation suggestions and recommended vehicle speeds is adjusted to generate the third intermediate control information. Based on high-confidence fusion of traffic situation, the third intermediate control information is verified, and instructions that contradict the traffic situation are corrected to generate the fourth intermediate control information. The fourth intermediate control information is then standardized and encapsulated to generate the final collaborative control information.

8. The design method for a vehicle-road-cloud collaborative roadside communication terminal according to claim 7, characterized in that, The final collaborative control information is encapsulated and distributed to vehicles and the cloud platform, completing the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal, including: The final collaborative control information is encapsulated in a communication protocol format to generate vehicle-to-everything (V2X) direct communication protocol data units and fifth-generation mobile communication uplink protocol data units. Based on the vehicle-to-everything (V2X) direct communication protocol data unit, a set of distribution instructions for vehicle broadcasting is generated; based on the fifth-generation mobile communication uplink protocol data unit, a set of distribution instructions for uploading to the cloud platform is generated. Based on the set of distribution instructions for vehicle broadcasting, dual-mode communication hardware components are invoked to broadcast vehicle-to-everything (V2X) direct communication protocol data units to vehicles within the coverage area through the V2X direct data interaction link. Based on the distribution instruction set, the dual-mode communication hardware components are invoked, and the 5G mobile communication uplink protocol data unit is sent to the cloud platform through the 5G mobile communication uplink data interaction link; The broadcast-based vehicle-to-everything (V2X) direct communication protocol data unit receives a protocol reception confirmation message returned by the vehicle through the V2X direct data interaction link. The transmission-based fifth-generation mobile communication uplink protocol data unit receives a protocol reception confirmation message returned by the cloud platform through the fifth-generation mobile communication uplink data interaction link. Based on the successful reception of both types of reception confirmation messages, a control information distribution completion confirmation signal is generated. Based on the confirmation signal for the completion of control information distribution, the system performs full-process functional verification from the collection of traffic participation elements, the generation of integrated traffic situation, the optimization of collaborative control information, protocol encapsulation to information distribution, and completes the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

9. A design device for a vehicle-road-cloud collaborative roadside communication terminal, wherein the device implements the method as described in any one of claims 1 to 8, characterized in that, include: The deployment module plans the deployment area of ​​the target road segment and determines the first, second, and third key deployment locations. The first key deployment location corresponds to the road segment entrance area, the second key deployment location corresponds to the core area of ​​the middle section of the road segment, and the third key deployment location corresponds to the road segment exit area. The partitioning module establishes a topology model based on three key deployment locations; The topological model is partitioned to generate structural units; The calculation module, based on the network characteristics of the structural units, calculates and generates parameter correction quantities for optimizing terminal deployment and working modes; The module is determined based on the parameter correction amount, and the functional architecture of the roadside communication terminal is determined. The functional architecture includes collaborative data processing function, heterogeneous communication function and local control function. The configuration module, based on the functional architecture, configures the hardware components and software protocols that enable collaborative data processing, heterogeneous communication and local control functions, and establishes data interaction links between the roadside communication terminal and vehicles, the cloud and adjacent roadside facilities. The fusion module obtains the status of traffic participants and cloud scheduling instructions through data interaction links, while the local control function collects local roadside data and generates initial collaborative control information after fusion. The optimization module optimizes and adjusts the initial cooperative control information based on the parameter correction amount to generate the final cooperative control information; The distribution module encapsulates the final collaborative control information and distributes it to vehicles and the cloud platform, completing the design and deployment of the vehicle-road-cloud collaborative roadside communication terminal.

10. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 8.

Images