Internet of vehicles architecture deployment optimization method and device

Abstract

The invention provides an Internet of Vehicles architecture deployment optimization method and device, and relates to the technical field of Internet of Vehicles, and the method comprises the steps: a collection layer of massive vehicles carries out the preprocessing of all kinds of collection data obtained according to a preset period, and transmits the data to a target edge node of an edge layer; the edge layer performs filtering and aggregation operation on the acquired data received from the at least one acquisition layer, and performs collision risk and congestion risk early warning based on the aggregated data; and the cloud computing layer predicts the road traffic based on the aggregated data, and performs dynamic resource scheduling according to the load occupancy rate and health state of the target edge node, so as to alleviate the technical problem of poor expandability and performance of the Internet of Vehicles system when facing mass equipment access.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle networking applications, and in particular to a method and apparatus for optimizing vehicle networking architecture deployment. Background Technology

[0002] The rapid development of Internet of Vehicles (IoV) technology has led to increasingly close connections between vehicles and the internet, forming a complex network system encompassing vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-network (V2N). The realization of this system relies on several key technologies, including big data processing, cloud computing, and edge computing. Big data processing technology is used to analyze and process the massive amounts of data generated by IoV, such as vehicle status data and traffic flow data, to support intelligent traffic management and services. Cloud computing technology provides the necessary computing and storage resources for IoV, enabling the deployment and operation of various IoV applications. Edge computing technology moves data processing tasks from the cloud to the network edge, effectively reducing latency and improving the real-time performance of data processing.

[0003] However, with the explosive growth in the number of connected vehicle devices, the scalability and performance management of the system face severe challenges. Existing connected vehicle architectures are inefficient in handling massive device connections and data streams, especially with the surge in the number of devices, where system scalability becomes a bottleneck. Data processing efficiency is particularly problematic; large amounts of data need to be transmitted to the cloud for processing, resulting in high latency and making it difficult to meet the real-time requirements of applications such as collision warnings. Furthermore, the resource allocation mechanism lacks flexibility and cannot be dynamically adjusted according to actual needs, leading to both resource waste and resource shortages during peak periods. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method and apparatus for optimizing the deployment of vehicle network architecture, so as to alleviate the technical problems of poor scalability and performance of vehicle network systems when facing massive device access.

[0005] In a first aspect, the present invention provides a method for optimizing the deployment of a vehicle-to-everything (V2X) architecture, comprising: The massive vehicle data acquisition layer will preprocess the various types of data acquired according to a preset cycle and transmit them to the target edge node of the edge layer. The edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data; The cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes.

[0006] In an optional implementation, the step of preprocessing various types of collected data acquired by the massive vehicle acquisition layer according to a preset period and transmitting them to the target edge node of the edge layer includes: When each vehicle starts, it triggers various preset devices to collect various preset parameters according to a preset cycle, resulting in multiple types of collected data. The collected data carries a collection timestamp and a collection device ID. The collected data includes at least vehicle speed, vehicle location, weather data, temperature data, and traffic flow. The collected data from a large number of vehicles is compressed, the target edge node is determined based on the network latency, and the compressed collected data is transmitted to the target edge node in the edge layer via the QUIC protocol.

[0007] In an optional implementation, the edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data, including: Based on the collection timestamp in the collected data, the data status of each type of collected data within the preset time period is determined, and the collected data from each collection layer that is in an invalid state is filtered out; wherein, the collected data in an invalid state includes at least invalid collected data with negative vehicle speed or temperature exceeding a preset threshold and redundant collected data with no change in vehicle position within the preset time period. Data collected from various collection layers for the same road segment is aggregated according to their corresponding categories to obtain aggregated data; The aggregated data is analyzed. If a collision risk is determined based on the relative distance and relative speed of vehicles at each collection layer, a collision warning is sent to the corresponding vehicles via the cloud computing layer. If a congested road segment is determined based on the average speed, speed dispersion, and vehicle density of vehicles in each road segment, a congestion warning is sent to the corresponding vehicles in the congested road segment and the third-party electronic map platform via the cloud computing layer.

[0008] In an optional implementation, the method further includes: The edge layer caches high-frequency hotspot data in the aggregated data so that when other vehicles request the corresponding data, it can directly read from the cache and return it.

[0009] In an optional implementation, the method further includes: Based on the historical driving data of vehicles corresponding to each collection layer, the social relationships between vehicles are determined; if any vehicle is at risk of collision, a collision warning is sent via the cloud computing layer to vehicles with social relationships with the vehicle at risk of collision.

[0010] In an optional implementation, the method further includes: If at least one vehicle cluster corresponding to the aforementioned social relationship stays at a temporary location for more than a preset duration or the number of round trips reaches a threshold, then all of the aforementioned vehicle clusters will be recorded in the temporary scene map. If any vehicle in the vehicle cluster is at risk of collision, a collision warning is sent via the cloud computing layer to all vehicles recorded in the temporary scene map. If any of the aforementioned social relationships change, the vehicle cluster recorded in the temporary scene graph will be removed.

[0011] In an optional implementation, the cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes, including: The aggregated data sent by the edge layer is classified according to time and road segment to generate traffic data in an indexed pattern; Traffic flow is predicted for a preset road segment based on the traffic data of the index pattern and the trained preset network model. If the load occupancy rate of the target edge node is detected to be greater than the first preset occupancy rate threshold, an alarm message will be sent to the resource manager, triggering the resource manager to start a new container to share the corresponding tasks of the target edge node; If the load occupancy rate of the target edge node is detected to be less than the second preset occupancy rate threshold, a notification message will be sent to the resource manager to trigger the resource manager to close the idle container; If the target edge node fails to respond for a preset number of consecutive times, the fault information will be sent to the resource manager, triggering the resource manager to migrate the corresponding task of the target edge node to the healthy edge node. This will enable the healthy edge node to read the historical data required for the corresponding task from the cloud database for connection and issue a notification that the service has been restored.

[0012] Secondly, the present invention provides a vehicle network architecture deployment optimization device, comprising: The data acquisition layer, which collects data from a large number of vehicles, will preprocess the various types of data acquired according to a preset cycle and transmit them to the target edge nodes of the edge layer. The edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data; The cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes.

[0013] Thirdly, the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the steps of the method described in any of the foregoing embodiments.

[0014] Fourthly, the present invention provides a machine-readable storage medium storing machine-executable instructions, which, when invoked and executed by a processor, cause the processor to perform the steps of the method described in any of the foregoing embodiments.

[0015] This invention provides a method and apparatus for optimizing the deployment of a vehicle-to-everything (V2X) architecture. It employs a layered data processing architecture, dividing the V2X system into a data acquisition layer, an edge computing layer, and a cloud computing layer. The data acquisition layer is responsible for collecting data from vehicles and sensors; the edge computing layer performs preliminary processing on the collected data, such as data filtering and aggregation, to reduce the amount of data that needs to be transmitted to the cloud; and the cloud computing layer is responsible for more complex data analysis and storage, providing support for V2X applications.

[0016] Other features and advantages of this disclosure will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0017] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for optimizing the deployment of a vehicle-to-everything (V2X) architecture is provided in an embodiment of the present invention. Figure 2 A functional block diagram of a vehicle network architecture deployment optimization device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0021] Existing vehicle-to-everything (V2X) systems struggle to efficiently manage massive numbers of device connections and data streams, especially with the rapid increase in the number of devices, making system scalability a bottleneck for development. The need to transmit large amounts of data to the cloud for processing leads to high latency and low efficiency, particularly in applications requiring real-time responses, such as collision warning systems.

[0022] Based on this, the vehicle network architecture deployment optimization method and apparatus provided in this embodiment of the invention can achieve efficient data processing and resource management to support the access of large-scale devices and the stable operation of services, while ensuring the high scalability and performance of the system.

[0023] To facilitate understanding of this embodiment, a detailed description of the vehicle-to-everything (V2X) architecture deployment optimization method disclosed in this embodiment of the invention will be provided first. This method is applied to a layered and collaborative device cluster, wherein the acquisition layer includes vehicle terminals and roadside perception devices; the edge layer includes roadside edge servers (deployed at traffic hubs and intersections), edge gateways, containerized clusters (Docker + Kubernetes), FPGA acceleration cards, load balancers (such as Nginx), and P2P communication modules; the cloud computing layer includes cloud server clusters (such as AWS EC2, ECS), distributed databases (time-series database InfluxDB + relational database MySQL), and big data processing framework clusters (Spark / Flink).

[0024] Figure 1 A flowchart illustrating a method for optimizing the deployment of a vehicle network architecture, as provided in an embodiment of the present invention.

[0025] like Figure 1 As shown, the method includes the following steps: In step S102, the massive vehicle acquisition layer will preprocess the various types of acquisition data obtained according to a preset cycle and transmit them to the target edge node of the edge layer.

[0026] In practical applications, the data layer mainly consists of vehicle-mounted sensors and cloud service APIs, responsible for collecting raw data such as vehicle status information and environmental information. Step S102 can achieve data preprocessing and selection of the most suitable target edge node for transmission through the following steps: Step 1.1: When each vehicle starts, it triggers each preset device to collect various preset parameters according to a preset cycle, and obtains a variety of collected data.

[0027] The collected data includes a collection timestamp and a collection device ID; the collected data includes at least vehicle speed, vehicle location, weather data, temperature data, and traffic flow.

[0028] As one application example, when the vehicle is started, sensors such as the engine temperature sensor, vehicle speed sensor, and GPS module are automatically activated; these sensors monitor and record various status information of the vehicle in real time, such as speed, location, fuel consumption, and engine status.

[0029] Step 1.2: Compress the collected data from a large number of vehicles, determine the target edge node based on the network latency, and transmit the compressed collected data to the target edge node in the edge layer via the QUIC protocol.

[0030] The acquisition layer uses Gzip to compress the acquired data, such as compressing 10KB GPS data to 4KB. The network status is analyzed through intelligent routing algorithms: if edge node A has a delay of 30ms and edge node B has a delay of 80ms, edge node A is selected as the target edge node for transmission; at the same time, the QUIC protocol is used to ensure fast reconnection after transmission interruption.

[0031] At this point, the collected data is compressed and sent in real time to the target edge node in the edge layer via the vehicle's wireless network (such as 4G / 5G network). For example, while the vehicle is in motion, the GPS module continuously records location data and sends it to the target edge node every few seconds.

[0032] In step S104, the edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data.

[0033] In this embodiment of the invention, the edge layer can be located on a server at a transportation hub or network edge to perform preliminary processing on the collected data, such as filtering, aggregation, and simple analysis, to reduce the burden on the cloud computing layer. The edge computing layer is also responsible for handling tasks with high real-time requirements, such as emergency response commands.

[0034] In some embodiments, step S104 may also be implemented by the following steps: Step 2.1: Determine the data status of each type of collected data within the preset time period based on the collection timestamp, and filter the collected data from each collection layer that is in an invalid state.

[0035] Here, the target edge node receives the collected data from the acquisition layer. Based on the acquisition timestamp carried by the acquired data, invalid and abnormal non-valid state data can be filtered to ensure the lightweight nature of subsequent operations.

[0036] Among them, the invalid data collected includes at least invalid data where the vehicle speed is negative or the temperature exceeds a preset threshold, and redundant data where the vehicle position does not change within a preset time period; for example, duplicate GPS data within 3 seconds and abnormal data where the vehicle speed is negative are removed.

[0037] Step 2.2: Aggregate the collected data from various collection layers for the same road segment according to their corresponding categories to obtain aggregated data.

[0038] Here, a large amount of collected data from the massive vehicle collection layer can be aggregated according to the type of collected data. For example, the location information of multiple vehicles can be summarized into a traffic flow information, or the speed data of 100 vehicles on the same road segment can be summarized into aggregated data with an average speed of 25km / h.

[0039] Step 2.3: Analyze the aggregated data. If a collision risk is determined based on the relative distance and relative speed of vehicles corresponding to each collection layer, a collision warning is sent to the corresponding vehicles via the cloud computing layer. If a congested road segment is determined based on the average speed, speed dispersion, and vehicle density of vehicles in each road segment, a congestion warning is sent to the corresponding vehicles in the congested road segment and the third-party electronic map platform via the cloud computing layer.

[0040] The aggregated data undergoes simple real-time analysis, such as calculating traffic flow and detecting anomalies (e.g., traffic congestion). Based on the analysis results, the target edge node can immediately send emergency response commands to the cloud computing layer. For example, upon detecting a traffic accident, it can immediately notify the cloud computing layer so that its APIs or microservice interfaces can be provided to various connected vehicle applications, such as intelligent traffic management systems and vehicle health monitoring systems, to notify nearby vehicles and relevant management departments.

[0041] The target edge node receives real-time location information from multiple vehicles. Through data aggregation and simple analysis, it detects slow-moving vehicles on a certain road segment and determines that traffic congestion may exist on that segment. For example, the target edge node calls a lightweight version of the CEP engine. If it detects that the distance between vehicles is less than 50 meters and the vehicle speed is greater than 60 km / h, it generates a collision warning according to preset warning rules and notifies the vehicles involved through the vehicle network. If the aggregated data meets the condition that the vehicle speed is less than 20 km / h for 5 consecutive minutes, it generates a congestion alert and pushes it to a nearby navigation app.

[0042] In practical applications, the method of this invention embodiment further includes: The edge layer caches high-frequency hot data in the aggregated data so that when other vehicles request the corresponding data, it can be read directly from the cache and returned.

[0043] The target edge node can store traffic data and real-time weather data of the city center road segment locally according to preset caching rules, such as caching for 72 hours and updating every 10 minutes. When other vehicles request data for this road segment, it can directly return from the cache without re-collecting the data or uploading the request to the cloud. This cached data reduces the response time of subsequent similar requests from 500ms to 50ms. When subsequent vehicles query the city center road conditions, they can quickly obtain the data, improving the navigation APP experience.

[0044] Based on the foregoing embodiments, the collision warning method provided in this embodiment of the invention further includes: Based on the historical driving data of vehicles corresponding to each collection layer, the social relationships between vehicles are determined; if any vehicle is at risk of collision, a collision warning is sent through the cloud computing layer to vehicles that have a social relationship with the vehicle at risk of collision.

[0045] Here, the edge layer obtains the historical driving data of vehicles in the coverage area over the past 30 days in batches through the vehicle network platform interface. This historical driving data includes daily driving trajectory (GPS coordinates, driving time), V2V communication interaction records (such as avoidance instructions, fleet coordination signals), destination records (such as navigation destination, frequently parked location), etc.

[0046] The system assesses whether the frequency of vehicles following each other on the same route, the duration of following each other, and the intensity of interaction in historical driving data meet requirements to determine if social relationships exist between vehicles. For example, it counts the number of times two vehicles overlap in the same time period and trajectory by ≥80% within 7 consecutive days; if this number is ≥15, it is marked as a potential related route relationship. Similarly, it counts the proportion of driving time where the distance between two vehicles is ≤100 meters and the speed difference is ≤10 km / h; if this proportion is ≥60%, it is marked as a potential convoy relationship. Or, it counts the number of V2V communication interactions between two vehicles; if these interactions are ≥20, it is marked as a potential temporary cooperative relationship. Based on this, if a vehicle requires a warning, it can more quickly issue warnings to other vehicles based on the social relationships between them.

[0047] As an optional embodiment, to further accurately expand the range of vehicles eligible for early warning, the method also includes: Step 3.1: If there is at least one vehicle cluster corresponding to a social relationship that stays at a temporary location for more than a preset duration or the number of round trips reaches a threshold, then all vehicle clusters are recorded in the temporary scene map.

[0048] Specifically, based on the group behavior characteristics reflected by the social relationships of vehicles, implicit dynamic scenarios are identified. If a cluster of vehicles stays in a non-parking area for ≥10 minutes and the proportion of waiting for instructions in V2V interactions is ≥70%, it is determined that there is a temporary event scenario (such as a temporary gathering or temporary road closure) in that area, and the cluster of vehicles at that temporary location is added to the dynamic temporary scenario map. If a cluster of vehicles (such as a ride-hailing fleet) frequently travels around a shopping mall (≥3 times within 1 hour), it is determined that there is a temporary high-demand scenario (such as shopping mall promotions or holiday crowds) in that area, and the cluster of vehicles at that temporary location is added to the temporary scenario map.

[0049] Step 3.2: If any vehicle in the vehicle cluster is at risk of collision, a collision warning is sent via the cloud computing layer to all vehicles recorded in the temporary scene map.

[0050] If any vehicle is at risk of collision, the alert will not be limited to vehicles with the same social relationship, but will be issued to all vehicles in the temporary location that have multiple social relationships, ensuring timely alerts for vehicle clusters in a wider range of temporary scenarios.

[0051] Step 3.3: If any social relationship changes, the vehicle cluster recorded in the temporary scene graph will be removed.

[0052] It should be noted that if a vehicle breaks away from its social relationship, then there is a change in the social relationship within the vehicle cluster; this indicates that the temporary scene has changed, and the vehicle cluster recorded in the temporary scene image is removed.

[0053] In step S106, the cloud computing layer predicts road segment traffic based on aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes.

[0054] The cloud computing layer resides in the data center and processes data that has been filtered and aggregated by the edge layer, enabling the execution of complex data analysis and long-term data storage tasks. The cloud computing layer also supports large-scale data processing and machine learning tasks, providing users with deep data insights. For example, step S106 can be implemented through the following steps: Step 4.1: Classify the aggregated data sent by the edge layer according to time and road segment to generate traffic data in an indexed pattern.

[0055] The cloud computing layer can receive aggregated data from the edge layer for storage and management. For example, aggregated traffic flow data can be stored in a cloud database; in practical applications, this traffic data is indexed by date and road segment for quick data retrieval.

[0056] Specifically, the edge layer uploads filtered and aggregated valid data, such as average vehicle speed on road segments and vehicle anomaly records, to the cloud computing layer, which then stores the traffic data indexed by date and road segment.

[0057] Step 4.2: Predict traffic flow on preset road segments based on traffic data in the index pattern and the trained preset network model.

[0058] The cloud computing layer uses the Spark framework and LSTM model to predict traffic flow on road segments for the next two hours based on seven days of traffic data uploaded from the edge layer. For example, it predicts a 30% increase in traffic flow on road segment A during the morning rush hour at 8:00 AM. In addition, the cloud computing layer can also be used to analyze the health status of vehicles based on data uploaded from the edge layer. For example, based on engine data from 1,000 vehicles of the same model, it can identify vehicle conditions under the pattern of temperature >90℃ and speed fluctuation >100 rpm → 80% probability of failure, and generate a vehicle health report.

[0059] The cloud computing layer in this invention utilizes big data processing technology and machine learning algorithms to perform in-depth data analysis. For example, it can analyze long-term traffic flow data to predict future traffic trends. Using received traffic flow data, the cloud computing layer, through historical driving data and machine learning models, predicts traffic flow on a specific road segment at a future time, helping vehicles take proactive measures. The cloud computing layer can also analyze engine status data from multiple vehicles, identify common fault modes, and notify vehicle owners to perform preventative maintenance, reducing the failure rate.

[0060] Step 4.3: If the load occupancy rate of the target edge node is detected to be greater than the first preset occupancy rate threshold, an alarm message is sent to the resource manager to trigger the resource manager to start a new container to share the corresponding tasks of the target edge node.

[0061] Meanwhile, cloud computing monitoring tools such as Prometheus collect resource data from the edge layer every second: if the automotive-grade central processing unit (CCPU) of the edge node exceeds 85% utilization and memory usage reaches 90% for 5 consecutive seconds, a high load alarm is triggered; at this time, resource allocation is dynamically adjusted according to the load monitoring results to cope with load changes.

[0062] When a node is detected to be overloaded, computing resources are automatically increased. For example, new virtual machine instances or containers are launched to distribute the load. Alternatively, a load balancer (such as Nginx) is used to evenly distribute the load across multiple nodes, ensuring balanced resource usage across all nodes. If the load on an edge node consistently exceeds a threshold, new computing instances are automatically launched on nearby servers, and some tasks are assigned to these new instances to reduce the load on that node.

[0063] Step 4.4: If the load occupancy rate of the target edge node is detected to be less than the second preset occupancy rate threshold, a notification message will be sent to the resource manager to trigger the resource manager to close the idle container. When the load decreases, excess computing resources are automatically released to save costs. For example, idle virtual machine instances or containers are shut down. During periods of low traffic at night, if the system detects multiple idle compute instances, some instances are automatically shut down to conserve resources.

[0064] Step 4.5: If the target edge node fails to respond for a preset number of consecutive times, the fault information is sent to the resource manager, which triggers the resource manager to migrate the corresponding tasks of the target edge node to the healthy edge node. This allows the healthy edge node to read the historical data required for the corresponding tasks from the cloud database for connection and sends a notification that the service has been restored.

[0065] When a failure of some system components is detected, tasks are automatically reassigned to healthy nodes to ensure the continued availability of services.

[0066] This invention enables real-time monitoring of system component health using a heartbeat mechanism and monitoring tools. For example, a heartbeat signal is sent every few seconds; if a node fails to respond within a specified time, it is considered to have failed. When a node failure is detected, the system automatically reassigns tasks on that node to other healthy nodes to ensure uninterrupted service. For instance, Kubernetes' Pod scheduling mechanism can be used to reassign Pods from the failed node to other healthy nodes, ensuring tasks run normally on the new nodes and guaranteeing service continuity. Service can be quickly restored through rollback and backup mechanisms.

[0067] Suppose a city's connected vehicle system is processing a large amount of traffic data at target edge nodes A and B during peak hours: monitoring tools detect that node A's CPU utilization reaches 90% and memory usage exceeds 85%, while node B's resource usage is also approaching critical levels. The system automatically starts new computing instances on nodes C and D, distributing some data processing tasks to these new instances. Using a load balancer, the newly arrived data traffic is evenly distributed across nodes A, B, C, and D. Suppose node B experiences a hardware failure and cannot continue processing tasks: the system detects that node B is not responding to a heartbeat signal, confirming its failure. Tasks on node B are immediately redistributed to nodes A, C, and D, ensuring data processing continues. Using container orchestration tools, the task containers on node B are restarted on other nodes, restoring service. Through this dynamic resource allocation algorithm, the connected vehicle system can efficiently utilize resources, ensuring stable operation and providing reliable service even under high load and failure conditions.

[0068] In a preferred embodiment for practical application, the acquisition layer preprocesses and transmits the data to the most suitable target edge node. The target edge node then filters and aggregates the acquired data, enabling the cloud computing layer to predict traffic flow and dynamically balance resources based on load. This significantly improves data processing speed and system response time. This layered data processing architecture allows data to be initially processed closest to its source, greatly reducing data transmission and processing latency. The application of a real-time data stream processing and analysis platform enables the rapid processing and analysis of large-scale real-time data, providing strong data support for connected vehicle applications such as traffic flow optimization and emergency response.

[0069] In some embodiments, the transmission latency between the edge layer and the cloud computing layer can be reduced by optimizing the transmission path between the edge layer and the cloud computing layer.

[0070] For example, deploy intelligent routing algorithms (such as Dijkstra) to select the optimal data transmission path based on network conditions. Deploy caching mechanisms at target edge nodes to store frequently used data and reduce redundant data transmission. Utilize data compression techniques (such as Gzip) to compress data before transmission, reducing the amount of data transmitted to the cloud computing layer. Use efficient data transmission protocols (such as QUIC) to improve the speed and reliability of data transmission to the cloud computing layer.

[0071] For example, target edge node A needs to transmit data to the cloud computing layer. An intelligent routing algorithm selects the path with the lowest network load and latency for data transmission. Vehicle A's data on road segment X is cached. When vehicle B travels to the same road segment, it directly retrieves the data from the cache without retransmission.

[0072] In some embodiments, such as Figure 2 As shown, this embodiment of the invention also provides a vehicle network architecture deployment optimization device 200, comprising: The data acquisition layer 201 will preprocess the various types of data acquired from massive vehicles according to a preset cycle and transmit them to the target edge node of the edge layer. Edge layer 202 performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data; The cloud computing layer 203 predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge node.

[0073] This invention employs a layered design of acquisition, edge, and cloud computing layers to optimize data flow and processing, improving data processing efficiency and system response speed while reducing latency. Each layer has independent functions and responsibilities, allowing for flexible allocation of processing resources based on data processing needs and real-time requirements. It can also automatically adjust resource allocation, including but not limited to computing, storage, and network resources, based on real-time system load and predicted service demands to achieve optimal resource utilization. The algorithm can monitor system load in real time and dynamically adjust resource configuration, effectively responding to unexpected events and load fluctuations. Combining edge computing and cloud computing technologies enables rapid processing and analysis of large-scale real-time data. The dynamic resource allocation algorithm optimizes resource utilization and reduces waste by adjusting resource allocation in real time. Simultaneously, the introduction of edge computing reduces reliance on central servers, further lowering data transmission costs.

[0074] Figure 3 This is a schematic diagram of the hardware architecture of the electronic device 300 provided in an embodiment of the present invention. See also... Figure 3 As shown, the electronic device 300 includes a machine-readable storage medium 301 and a processor 302, and may also include a non-volatile storage medium 303, a communication interface 304, and a bus 305; wherein the machine-readable storage medium 301, the processor 302, the non-volatile storage medium 303, and the communication interface 304 communicate with each other through the bus 305. The processor 302 can execute the vehicle network architecture deployment optimization method described in the above embodiments by reading and executing machine-executable instructions for vehicle network architecture deployment optimization in the machine-readable storage medium 301.

[0075] The machine-readable storage medium mentioned in this article can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0076] Non-volatile media can be non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar non-volatile storage media, or combinations thereof.

[0077] It is understood that the specific operation methods of each functional module in this embodiment can be referred to the detailed description of the corresponding steps in the above method embodiment, and will not be repeated here.

[0078] The computer-readable storage medium provided in the embodiments of the present invention stores a computer program. When the computer program code is executed, it can implement the vehicle network architecture deployment optimization method described in any of the above embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0080] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms installation, connection, and linking should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0081] In the description of this invention, it should be noted that the terms center, up, down, left, right, vertical, horizontal, inner, and outer, indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms first, second, and third are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0082] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A method for optimizing the deployment of a vehicle-to-everything (V2X) architecture, characterized in that, include: The massive vehicle data acquisition layer will preprocess the various types of data acquired according to a preset cycle and transmit them to the target edge node of the edge layer. The edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data; The cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes.

2. The method according to claim 1, characterized in that, The massive vehicle data acquisition layer will preprocess various types of collected data according to a preset cycle and transmit them to the target edge nodes of the edge layer, including: When each vehicle starts, it triggers various preset devices to collect various preset parameters according to a preset cycle, resulting in multiple types of collected data. The collected data carries a collection timestamp and a collection device ID. The collected data includes at least vehicle speed, vehicle location, weather data, temperature data, and traffic flow. The collected data from a large number of vehicles is compressed, the target edge node is determined based on the network latency, and the compressed collected data is transmitted to the target edge node in the edge layer via the QUIC protocol.

3. The method according to claim 1, characterized in that, The edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data, including: Based on the collection timestamp in the collected data, the data status of each type of collected data within the preset time period is determined, and the collected data from each collection layer that is in an invalid state is filtered out; wherein, the collected data in an invalid state includes at least invalid collected data with negative vehicle speed or temperature exceeding a preset threshold and redundant collected data with no change in vehicle position within the preset time period. Data collected from various collection layers for the same road segment is aggregated according to their corresponding categories to obtain aggregated data; The aggregated data is analyzed. If a collision risk is determined based on the relative distance and relative speed of vehicles at each collection layer, a collision warning is sent to the corresponding vehicles via the cloud computing layer. If a congested road segment is determined based on the average speed, speed dispersion, and vehicle density of vehicles in each road segment, a congestion warning is sent to the corresponding vehicles in the congested road segment and the third-party electronic map platform via the cloud computing layer.

4. The method according to claim 3, characterized in that, The method further includes: The edge layer caches high-frequency hotspot data in the aggregated data so that when other vehicles request the corresponding data, it can directly read from the cache and return it.

5. The method according to claim 3, characterized in that, The method further includes: Based on the historical driving data of vehicles corresponding to each collection layer, the social relationships between vehicles are determined; if any vehicle is at risk of collision, a collision warning is sent via the cloud computing layer to vehicles with social relationships with the vehicle at risk of collision.

6. The method according to claim 5, characterized in that, The method further includes: If at least one vehicle cluster corresponding to the aforementioned social relationship stays at a temporary location for more than a preset duration or the number of round trips reaches a threshold, then all of the aforementioned vehicle clusters will be recorded in the temporary scene map. If any vehicle in the vehicle cluster is at risk of collision, a collision warning is sent via the cloud computing layer to all vehicles recorded in the temporary scene map. If any of the aforementioned social relationships change, the vehicle cluster recorded in the temporary scene graph will be removed.

7. The method according to claim 1, characterized in that, The cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes, including: The aggregated data sent by the edge layer is classified according to time and road segment to generate traffic data in an indexed pattern; Traffic flow is predicted for a preset road segment based on the traffic data of the index pattern and the trained preset network model. If the load occupancy rate of the target edge node is detected to be greater than the first preset occupancy rate threshold, an alarm message will be sent to the resource manager, triggering the resource manager to start a new container to share the corresponding tasks of the target edge node; If the load occupancy rate of the target edge node is detected to be less than the second preset occupancy rate threshold, a notification message will be sent to the resource manager to trigger the resource manager to close the idle container; If the target edge node fails to respond for a preset number of consecutive times, the fault information will be sent to the resource manager, triggering the resource manager to migrate the corresponding task of the target edge node to the healthy edge node. This will enable the healthy edge node to read the historical data required for the corresponding task from the cloud database for connection and issue a notification that the service has been restored.

8. A vehicle-to-everything (V2X) architecture deployment optimization device, characterized in that, include: The data acquisition layer, which collects data from a large number of vehicles, will preprocess the various types of data acquired according to a preset cycle and transmit them to the target edge nodes of the edge layer. The edge layer performs filtering and aggregation operations on the collected data received from at least one acquisition layer, and then performs collision risk and congestion risk warnings based on the aggregated data; The cloud computing layer predicts road segment traffic based on the aggregated data and performs dynamic resource scheduling according to the load occupancy and health status of the target edge nodes.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-executable instructions that, when invoked and executed by a processor, cause the processor to perform the steps of the method according to any one of claims 1 to 7.

Images