Cooperative scheduling method based on dynamic priority and multi-level cache multi-queue
Patent Information
- Application Number
- CN202511476803.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-16
- Publication Date
- 2026-10-13
AI Technical Summary
尤其在云端,会汇聚不同的路侧消息,存在大量的消息需要处理,同时,由于很多消息需要再实时通过云端传递到不同的终端(例如车机或者手机地图等),消息链路较长,如何有效低延时的实现那些实时性要求比较高的消息处理,就成为一个关键问题
[0049]本发明通过多级队列实现了系统能力的精细化管理,通过多级缓存实现了数据访问的加速,并通过动态优先级这个核心算法将两者有机串联,实现对消息时空有效性的智能响应。这套方案能够有效地处理智能网联场景下海量、突发、低延时的数据挑战,具备极强的工程实践性和竞争力。具备如下特点:
Smart Images

Figure CN122909312A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of intelligent transportation, specifically a collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues. Background Technology
[0002] In recent years, Intelligent Transportation Systems (ITS), as a novel technology, employs advanced science and technology to comprehensively consider systems involving roads, traffic, people, and the environment, achieving intelligent traffic management and bringing possibilities and hope for solving road traffic problems. Furthermore, in a 5G-based network environment, ITS comprises three parts: vehicle-side, road-side, and cloud-side. The key challenge lies in leveraging the collaborative communication and interaction between "people, vehicles, roads, and the cloud" to provide different services to different types of vehicles (including highly automated vehicles, connected vehicles with communication capabilities, and existing public transportation vehicles), thereby improving driving safety and traffic efficiency, and realizing intelligent transportation as soon as possible.
[0003] In the "human-vehicle-road-cloud" collaboration, the system contains a large number of messages of different types and priorities, such as service messages and safety messages. These messages have different triggering mechanisms, different uplink and downlink paths, and different closed-loop methods. For example, event messages sensed by roadside computing units can be periodically broadcast to vehicles with V2X capabilities via vehicle-to-infrastructure (V2X) communication; for ordinary vehicles, the communication can proceed from the roadside to the cloud and then back to the vehicle. Especially in the cloud, various roadside messages converge, resulting in a large volume of messages that need processing. Furthermore, since many messages need to be transmitted in real-time from the cloud to different terminals (such as in-vehicle systems or mobile maps), the message chain is long. Therefore, how to effectively and with low latency process messages with high real-time requirements becomes a critical issue.
[0004] In intelligent transportation scenarios, the cloud serves as the central hub for message aggregation. It is necessary to comprehensively consider factors such as message type, message time validity, and message space validity, and propose suitable message scheduling algorithms by combining various technical means. Summary of the Invention
[0005] This invention analyzes the composition and characteristics of end-to-end systems and, combined with the characteristics of intelligent transportation scenarios, proposes a collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues. This method comprehensively considers message type and the spatiotemporal validity of messages to dynamically generate message priorities, and provides different closed-loop processes based on different priorities. This invention can effectively handle the challenges of massive, bursty, and low-latency data in intelligent connected vehicle scenarios, possessing strong engineering practicality and competitiveness.
[0006] The technical solution adopted by the present invention to achieve the above objectives is as follows:
[0007] The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues includes the following steps:
[0008] 1) The data inflow and preprocessing module sends traffic information to the core scheduling module and the processing and caching module through the message access queue (Ingest Queue);
[0009] 2) The core scheduling module allocates the message ingest queue to different real-time processing queues based on dynamic priority;
[0010] 3) The processing and caching module reads, writes, and caches traffic information in a hierarchical manner through real-time workgroups and hot message caches corresponding to the real-time processing queue.
[0011] Step 1) includes the following steps:
[0012] 1.1) Obtain traffic information through the edge device RCU and store it as raw information in the message access queue (Ingest Queue);
[0013] 1.2) The message ingestion queue is persisted to the L3 weak hotspot message cache and sent to the core scheduling layer.
[0014] Step 2) includes the following steps:
[0015] 2.1) Define dynamic priority;
[0016] 2.2) Based on the messages in the message ingest queue, calculate the dynamic priority score of the messages according to the dynamic priority.
[0017] 2.3) Based on the dynamic priority score and score threshold, the message is assigned to the corresponding real-time processing queue for processing.
[0018] The dynamic priority includes three factors: message type, message time validity, and message space validity, wherein:
[0019] The message time validity defines a message’s time to live (TTL). If the time exceeds this limit, the data is considered expired and invalid.
[0020] The message space validity defines the spatial scope of a message's influence; only application or vehicle messages within this scope are considered valid.
[0021] The dynamic priority score P_score is specifically:
[0022] P_score=α*F(T_remaining) +β*G(S_relevance)+γ* H(Message_type)
[0023] Where F(T_remaining) represents the time urgency function, G(S_relevance) represents the spatial relevance function, H(Message_type) represents the message type function, and α, β, γ are harmonic parameters, and α + β + γ = 1;
[0024] The F(T_remaining) function indicates that the shorter the remaining time, the lower the message value and the lower the score. Specifically:
[0025] F(T_remaining) = exp(-λ * T_remaining)
[0026] T_remaining = Message generation timestamp + Preset validity period - Current time
[0027] Where T_remaining is the upcoming message validity period, i.e. the remaining valid duration of the message, and λ is the decay rate parameter;
[0028] The G(S_relevance) function is calculated by the heat value of the map grid where the message is located. The heat value is calculated by different indicators of a certain grid in a recent period of time.
[0029] The H(Message_type) function is a preset weight value.
[0030] The spatial relevance function G(S_relevance) is specifically as follows:
[0031] When a message belongs to one or more grids, it is assigned to the grid containing its central point. In this case, the message spatial relevance G(S_relevance) is the heat value of that grid, i.e.:
[0032] G(S_relevance) = Heatness_of_Grid(message)
[0033] Furthermore, considering the grid surrounding the message location, the weighted heat of each neighboring grid is calculated, and the maximum value among all weighted heats is taken as the spatial relevance score of the message, i.e.:
[0034] G(S_relevance) = max( Heatness_of_Grid(i) * exp(-μ * distance(grid_i,message_location)) )
[0035] Where μ is the distance decay coefficient, Heatness_of_Grid(i) represents the real-time heat value of the grid, and grid_i,message_location represents the distance from grid i to the message center location.
[0036] Step 2.3) specifically refers to:
[0037] Different queue numbers are set according to the specific scenario. The message with the highest P_score is designated as a strong hot message and assigned to the strong real-time processing queue P0. The message with a P_score that is not the highest but is higher than the threshold is designated as a medium hot message and assigned to the medium real-time processing queue P1. The message with a P_score that is lower than the threshold is designated as a weak hot message and assigned to the weak real-time processing queue P2.
[0038] Step 3) specifically refers to:
[0039] P0 queue messages are assigned to the strong real-time workgroup for processing, and strong hot messages are cached through L1 strong hot messages;
[0040] Distribute P1 queue messages to the real-time workgroup for processing, and cache hot messages in L2 through the hot message cache.
[0041] P2 queue messages are assigned to weak real-time workgroups for processing, and strong hot messages are cached through L3 weak hot messages.
[0042] All caching mechanisms have incorporated eviction policies.
[0043] By setting different numbers of real-time workgroups, resources can be saved. Specifically, the number of strong real-time workgroups should be the largest, followed by medium real-time workgroups, and the number of weak real-time workgroups should be the smallest.
[0044] A collaborative scheduling system based on dynamic priority, multi-level caching, and multi-queues includes:
[0045] The data inflow and preprocessing module is used to send traffic information to the core scheduling module and the processing and caching module through the message access queue (Ingest Queue).
[0046] The core scheduling module is used to allocate messages from the Ingest Queue to different real-time processing queues based on dynamic priorities.
[0047] The processing and caching module is used to read, write, and hierarchically cache traffic information through real-time workgroups and hot message caches corresponding to the real-time processing queue.
[0048] The present invention has the following beneficial effects and advantages:
[0049] This invention achieves refined management of system capabilities through multi-level queues, accelerates data access through multi-level caching, and organically connects these two through a core algorithm of dynamic prioritization, enabling intelligent responses to the spatiotemporal validity of messages. This solution effectively handles the challenges of massive, bursty, and low-latency data in intelligent connected vehicle scenarios, possessing strong engineering practicality and competitiveness. It features the following characteristics:
[0050] Low latency: High-priority messages take the fastest path (high-speed caching, priority scheduling), greatly shortening the end-to-end processing time of critical data.
[0051] High resource utilization: Reserve valuable L1 / L2 cache space for the most needed data and avoid it being occupied by low-value data.
[0052] Dynamic priority: The priority changes dynamically and can adapt to the spatiotemporal changes in traffic flow (such as the formation of new hotspots due to sudden accidents).
[0053] Systematic: It organically combines caching mechanisms and processing scheduling mechanisms to form a complete optimization system.
[0054] Distributed scaling: The implementation of multiple message queues, multi-level caching, and real-time processing workgroups all utilize the system for distributed scaling, which can effectively cope with the continuous expansion of traffic scale and the increasing variety of scenario types. Attached Figure Description
[0055] Figure 1 Framework diagram of the "human-vehicle-road-cloud" collaborative system in intelligent transportation scenarios;
[0056] Figure 2 Flowchart of the method of this invention;
[0057] Figure 3 The present invention provides a flowchart of a collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues. Detailed Implementation
[0058] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.
[0059] like Figure 1 As shown, the "human-vehicle-road-cloud" collaborative system in intelligent transportation scenarios includes:
[0060] 1) Sensors: Components such as cameras and radar are responsible for sensing messages and sending the results to the RCU edge device.
[0061] 2) Roadside communication equipment: A unit that can communicate with vehicles via V2X and can also communicate with edge devices.
[0062] 3) Edge Unit (RCU): It is mainly deployed on the roadside. The common deployment mode is to deploy it at certain intervals on both sides of the road. It is responsible for sending the events or traffic light data sensed by the roadside to the cloud platform, and can also receive downlink messages from the cloud platform.
[0063] 4) Third-party platform: It is associated with the cloud platform and can communicate with each other.
[0064] like Figure 2 and Figure 3 As shown, a collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues is implemented on the platform side. The platform side can be divided into different layers, with different schemes introduced at each layer. It is divided into a data inflow and preprocessing layer, a core scheduling layer, and a processing and caching layer, as detailed below:
[0065] 1) Data Inflow and Preprocessing
[0066] An Ingest Queue is introduced at this layer to receive all raw messages from RCU edge devices and persist them to the L3 weak hotspot message cache. Its function is to maintain order and buffer, ensuring that no data is lost due to platform overload.
[0067] For example, the technology choice is Kafka. It has high throughput and persistence capabilities, and is used to handle massive and sudden bursts of roadside message inbound traffic, achieving first-layer traffic smoothing.
[0068] 2) Core Scheduling Layer
[0069] Next, messages are consumed from the access queue, dynamic priority calculation (P_score) is performed, and messages are delivered to different processing queues based on the scores. This is the intelligent scheduling center of the entire system.
[0070] Processing Queues: A group of queues with different service levels. The number of queues can be set according to the specific scenario; for example, in this case, it can be set to three types of queues:
[0071] Strong real-time processing queue (P0): Processes messages with the highest P_score (such as emergency events).
[0072] Medium-priority processing queue (P1): Processes medium-priority messages (such as the current traffic light at the intersection).
[0073] Weak real-time processing queue (P2): Processes low-priority messages (such as historical data archiving and non-real-time analysis).
[0074] Responsibilities: Isolate message streams of different priorities, allocate different amounts of computing resources to different queues, and ensure that high-priority messages are processed in a timely manner.
[0075] In this layer, the dynamic priority score of a message is calculated as follows:
[0076] Dynamic priority is based on three factors: message type, message event validity, and message space validity.
[0077] Temporal Validity: Defines the valid lifespan (Time-To-Live, TTL) of a message. For example, a "vehicle location" message might have a TTL of only 100ms; after this time, the data is considered expired and invalid. T_remaining = Message generation timestamp + Preset validity period – Current time.
[0078] Spatial Validity: Defines the spatial scope of a message's influence. It's typically represented by a geofence, such as a circular area with a radius of 50 meters, or a road segment polygon. Only applications or vehicles within this area will be interested in the message.
[0079] When a new message arrives at the platform's entry gateway, a dynamic priority score (P_score) is immediately calculated for it.
[0080] P_score = α * F(T_remaining) + β * G(S_relevance) + γ * H(Message_type)
[0081] Where: F(T_remaining): Time urgency function
[0082] G(S_relevance): Spatial relevance function
[0083] H(Message_type): Message type function
[0084] For the F(T_remaining) function, an exponential decay function is used, which closely matches the decay model of "data validity". The shorter the remaining time, the steeper the score decline curve, which greatly highlights the urgency of the message about to expire.
[0085] F(T_remaining) = exp(-λ * T_remaining), where T_remaining represents the validity period of the upcoming message, and λ (lambda) is the decay rate parameter. The larger λ is, the faster the priority decays over time.
[0086] For the G(S_relevance) function, a scheme is adopted that approximates the coverage area using a gridded approach and introduces a distance decay function. The map is pre-gridded (Geohash or Grid ID), and each grid has a real-time "heat value." The heat value can be calculated based on indicators such as the number of messages and vehicles in that grid over a recent period. The location of a message belongs to one or more grids, and S_relevance is simplified to the heat value of the grid where the message is located: Heatness_of_Grid.
[0087] G(S_relevance) = Heatness_of_Grid(message)
[0088] Furthermore, distance decay can be introduced. Even if a data point is not in the hottest grid, it can still obtain a certain correlation score in its vicinity. By traversing all grids, the decayed spatial correlation function can be calculated.
[0089] G(S_relevance) = max( Heatness_of_Grid(i) * exp(-μ * distance(grid_i,message_location)) ) for all grid_i in nearby_grids, where μ is the distance decay coefficient. This avoids messages at the grid edges being completely ignored, resulting in a smoother and more robust performance.
[0090] For the H(Message_type) function, it is a preset weight value. For example:
[0091] Emergency events (such as traffic accidents, road spills): Weight 1.0
[0092] Traffic signals (traffic light status): Weight 0.8
[0093] Ordinary vehicle trajectory: Weight 0.5
[0094] The more important an event is, the greater its weight.
[0095] α, β, and γ are harmonic parameters (α + β + γ = 1) used to adjust the relative importance of the three dimensions. Initially, they can be set to α = 0.5, β = 0.3, and γ = 0.2, and then optimized according to the actual scenario.
[0096] 3) Processing and caching layer
[0097] This layer mainly provides processing workgroups and multiple caching mechanisms. The number and functions of workgroups and caches correspond to the processing queues of the core scheduling layer. Taking three types of processing queues as an example, this layer is set up with three workgroups and a three-level caching mechanism.
[0098] Level 3 processing task force:
[0099] Strong real-time workgroup: processes P0 queue messages, can be configured with a large number of queues, runs on a high-performance CPU, and ensures that the most urgent messages are processed as soon as possible.
[0100] Medium-scale real-time workgroup: processes messages in the P1 queue, in medium quantity.
[0101] Weak real-time workgroup: processes P2 queue messages in the fewest possible quantities, thus saving resources.
[0102] This resource allocation method ensures that high-priority tasks not only have short queuing times but also receive the most abundant computing resources.
[0103] Level 3 cache:
[0104] L1 cache: Stores frequently accessed messages and works in conjunction with high-real-time workgroups.
[0105] L2 cache: Stores frequently accessed messages and works in conjunction with the real-time workgroup.
[0106] L3 cache: Stores weak hotspot messages and works in conjunction with weak real-time workgroups.
[0107] This caching mechanism ensures that frequently accessed hot data is stored in a high-performance cache. When accessing hot data, the L1 cache is accessed directly, ensuring performance and effectiveness. However, all caching mechanisms need to incorporate eviction policies (such as an enhanced LRU algorithm) to prevent performance degradation when the number of data items is too large.
[0108] The above description represents the preferred embodiments of the present invention. Those skilled in the art can make various modifications and improvements to the present invention without departing from its spirit and principles, and such modifications and improvements should also be considered as protections of the present invention.
Claims
1. A collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues, characterized in that: Includes the following steps: 1) The data inflow and preprocessing module sends traffic information to the core scheduling module and the processing and caching module through the message access queue (Ingest Queue); 2) The core scheduling module allocates the message ingest queue to different real-time processing queues based on dynamic priority; 3) The processing and caching module reads, writes, and caches traffic information in a hierarchical manner through real-time workgroups and hot message caches corresponding to the real-time processing queue.
2. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 1, characterized in that, Step 1) includes the following steps: 1.1) Obtain traffic information through the edge device RCU and store it as raw information in the message access queue IngestQueue; 1.2) The message ingestion queue is persisted to the L3 weak hotspot message cache and sent to the core scheduling layer.
3. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 1, characterized in that, Step 2) includes the following steps: 2.1) Define dynamic priority; 2.2) Based on the messages in the message ingest queue, calculate the dynamic priority score of the messages according to the dynamic priority. 2.3) Based on the dynamic priority score and score threshold, the message is assigned to the corresponding real-time processing queue for processing.
4. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 3, characterized in that, The dynamic priority includes three factors: message type, message time validity, and message space validity, wherein: The message time validity defines a message’s time to live (TTL). If the time exceeds this limit, the data is considered expired and invalid. The message space validity defines the spatial scope of a message's influence; only application or vehicle messages within this scope are considered valid.
5. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 3, characterized in that, The dynamic priority score P_score is specifically: P_score=α*F(T_remaining) +β*G(S_relevance)+γ*H(Message_type) Where F(T_remaining) represents the time urgency function, G(S_relevance) represents the spatial relevance function, H(Message_type) represents the message type function, and α, β, γ are harmonic parameters, and α + β + γ = 1; The F(T_remaining) function indicates that the shorter the remaining time, the lower the message value and the lower the score. Specifically: F(T_remaining) = exp(-λ * T_remaining) T_remaining = Message generation timestamp + Preset validity period - Current time Where T_remaining is the upcoming message validity period, i.e. the remaining valid duration of the message, and λ is the decay rate parameter; The G(S_relevance) function is calculated by the heat value of the map grid where the message is located. The heat value is calculated by different indicators of a certain grid in a recent period of time. The H(Message_type) function is a preset weight value.
6. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 5, characterized in that, The spatial relevance function G(S_relevance) is specifically as follows: When a message belongs to one or more grids, it is assigned to the grid containing its central point. In this case, the message spatial relevance G(S_relevance) is the heat value of that grid, i.e.: G(S_relevance) = Heatness_of_Grid(message) Furthermore, considering the grid surrounding the message location, the weighted heat of each neighboring grid is calculated, and the maximum value among all weighted heats is taken as the spatial relevance score of the message, i.e.: G(S_relevance) = max( Heatness_of_Grid(i) * exp(-μ * distance(grid_i,message_location)) ) Where μ is the distance decay coefficient, Heatness_of_Grid(i) represents the real-time heat value of the grid, and grid_i,message_location represents the distance from grid i to the message center location.
7. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 3, characterized in that, Step 2.3) specifically refers to: Different queue numbers are set according to the specific scenario. The message with the highest P_score is designated as a strong hot message and assigned to the strong real-time processing queue P0. The message with a P_score that is not the highest but is higher than the threshold is designated as a medium hot message and assigned to the medium real-time processing queue P1. The message with a P_score that is lower than the threshold is designated as a weak hot message and assigned to the weak real-time processing queue P2.
8. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 1, characterized in that, Step 3) specifically refers to: P0 queue messages are assigned to the strong real-time workgroup for processing, and strong hot messages are cached through L1 strong hot messages; Distribute P1 queue messages to the real-time workgroup for processing, and cache hot messages in L2 through the hot message cache. P2 queue messages are assigned to weak real-time workgroups for processing, and strong hot messages are cached through L3 weak hot messages. All caching mechanisms have incorporated eviction policies.
9. The collaborative scheduling method based on dynamic priority, multi-level caching, and multi-queues according to claim 8, characterized in that, By setting different numbers of real-time workgroups, resources can be saved. Specifically, the number of strong real-time workgroups should be the largest, followed by medium real-time workgroups, and the number of weak real-time workgroups should be the smallest.
10. A collaborative scheduling system based on dynamic priority, multi-level caching, and multi-queues, characterized in that: include: The data inflow and preprocessing module is used to send traffic information to the core scheduling module and the processing and caching module through the message access queue (Ingest Queue). The core scheduling module is used to allocate messages from the Ingest Queue to different real-time processing queues based on dynamic priorities. The processing and caching module is used to read, write, and hierarchically cache traffic information through real-time workgroups and hot message caches corresponding to the real-time processing queue.