Message scheduling method and device, electronic equipment and storage medium

Abstract

This application relates to the field of vehicle technology, providing a message scheduling method, apparatus, electronic device, and storage medium. The method involves determining target attribute data for a message to be processed (a message sent from the cloud to the vehicle); determining a target scheduling strategy for sending the message based on the target attribute data and the target driving scenario of the vehicle; the target scheduling strategy indicative of the timing, method, and / or quality of service (QoS) level of the message; and processing the message according to the target scheduling strategy. Applying this technical solution improves the adaptability of message scheduling in dynamically changing vehicle network environments.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a message scheduling method, apparatus, electronic device, and storage medium. Background Technology

[0002] In a typical connected vehicle telematics service provider (TSP) platform architecture, the cloud sends remote vehicle control messages (such as air conditioning control and door unlocking), over-the-air (OTA) upgrade notification messages, and intelligent configuration messages to the vehicle via Message Queuing Telemetry Transport (MQTT).

[0003] Existing MQTT message scheduling systems pre-determine a fixed Quality of Service (QoS) level for message types during the design phase and directly trigger message delivery based on this level.

[0004] However, during vehicle operation, the above solution is greatly affected by network conditions and cannot improve the adaptability of message scheduling. Summary of the Invention

[0005] This application provides a message scheduling method, apparatus, electronic device, and storage medium to improve the message scheduling adaptability under dynamic changes in the vehicle network environment.

[0006] In a first aspect, embodiments of this application provide a message scheduling method, comprising:

[0007] Determine the target attribute data of the message to be processed, which is a message that the cloud will send to the vehicle;

[0008] Based on the target attribute data and the target driving scenario in which the vehicle is located, a target scheduling strategy for sending the message to be processed is determined. The target scheduling strategy is used to indicate the timing, method, and / or quality of service level of the message to be processed. The target driving scenario is determined based on the real-time operating data uploaded by the vehicle.

[0009] The messages to be processed are processed according to the target scheduling strategy.

[0010] In one or more embodiments, the target attribute data includes: business priority;

[0011] Accordingly, determining the target scheduling strategy for sending the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located includes:

[0012] Based on the business priority and the target driving scenario, the target scheduling strategy is determined in the preset scheduling mapping relationship;

[0013] The scheduling mapping relationship records the correspondence between different priorities, different driving scenarios, and different scheduling strategies.

[0014] In one or more embodiments, the different driving scenarios include at least one of the following: underground parking garage weak network scenario, tunnel weak network scenario, parking and dormancy scenario, urban congestion scenario, high-speed stable scenario, and other scenarios;

[0015] The different priorities include at least one of the following: urgent, important, normal, and non-urgent;

[0016] The scheduling strategy corresponding to each driving scenario and each priority includes any one of the following: immediate sending, delayed sending, buffering and waiting, delayed batching, SMS wake-up, MQTT wake-up, and waiting for self-recovery;

[0017] Among them, the scheduling strategy corresponding to at least one driving scenario and at least one priority carries a preset service quality level.

[0018] In one or more embodiments, the target attribute data further includes: timeliness requirements, wherein the target scheduling strategy is delayed transmission or buffering and waiting;

[0019] Accordingly, before processing the message to be processed according to the target scheduling strategy, the method further includes:

[0020] Based on the real-time operating data and the vehicle's historical operating data, the estimated time window for the vehicle to restore its network connection is determined;

[0021] If the estimated time window is less than the timeliness requirement, the target scheduling strategy is updated to delayed transmission.

[0022] If the estimated time window is greater than or equal to the timeliness requirement, the target scheduling strategy is updated to send immediately.

[0023] In one or more embodiments, determining the estimated time window for the vehicle to restore network connectivity based on the real-time operating data and the vehicle's historical operating data includes:

[0024] Based on the location data and vehicle speed data in the real-time operation data, the estimated position sequence of the vehicle within a preset time period is determined;

[0025] Based on the location data within the geofence data within the preset range, determine the estimated time corresponding to each location point in the estimated location sequence;

[0026] The estimated time window is determined based on the estimated time corresponding to each location point and the historical operation data.

[0027] In one or more embodiments, the target attribute data further includes: message type, and the target scheduling strategy is delayed batching;

[0028] Accordingly, processing the message to be processed according to the target scheduling strategy includes:

[0029] Obtain at least one other message that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the message to be processed, and classify the message to be processed and the at least one other message to be processed as messages of the same type;

[0030] The batch time window is started with the timestamp of the first message of the same type entering the batch queue as the starting point;

[0031] When the batch time window expires, the payloads of similar messages in the batch queue are merged into the same JSON array and deduplicated.

[0032] The merged and deduplicated loads are then sent to the vehicle.

[0033] In one or more embodiments, before determining the target scheduling strategy for issuing the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located, the method further includes:

[0034] Based on the real-time operating data and the preset scene recognition strategy, at least one driving scene in which the vehicle is located is determined. The scene recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds.

[0035] According to a preset priority strategy, the target driving scenario is determined in the at least one driving scenario, wherein the priority strategy records at least one driving scenario arranged in priority order.

[0036] Secondly, embodiments of this application provide a message scheduling apparatus, comprising:

[0037] The first determining module is used to determine the target attribute data of the message to be processed, which is a message that the cloud will send to the vehicle.

[0038] The second determining module is used to determine the target scheduling strategy for sending the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located. The target scheduling strategy is used to indicate the timing, method and / or quality of service level of the message to be processed. The target driving scenario is determined based on the real-time operation data uploaded by the vehicle.

[0039] The processing module is used to process the message to be processed according to the target scheduling strategy.

[0040] In one or more embodiments, the target attribute data includes: business priority;

[0041] Accordingly, the second determining module determines a target scheduling strategy for issuing the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located, specifically for:

[0042] Based on the business priority and the target driving scenario, the target scheduling strategy is determined in the preset scheduling mapping relationship;

[0043] The scheduling mapping relationship records the correspondence between different priorities, different driving scenarios, and different scheduling strategies.

[0044] In one or more embodiments, the different driving scenarios include at least one of the following: underground parking garage weak network scenario, tunnel weak network scenario, parking and dormancy scenario, urban congestion scenario, high-speed stable scenario, and other scenarios;

[0045] The different priorities include at least one of the following: urgent, important, normal, and non-urgent;

[0046] The scheduling strategy corresponding to each driving scenario and each priority includes any one of the following: immediate sending, delayed sending, buffering and waiting, delayed batching, SMS wake-up, MQTT wake-up, and waiting for self-recovery;

[0047] Among them, the scheduling strategy corresponding to at least one driving scenario and at least one priority carries a preset service quality level.

[0048] In one or more embodiments, the target attribute data further includes: timeliness requirements, wherein the target scheduling strategy is delayed transmission or buffering and waiting;

[0049] Accordingly, before processing the message to be processed according to the target scheduling strategy, the second determining module is further configured to:

[0050] Based on the real-time operating data and the vehicle's historical operating data, the estimated time window for the vehicle to restore its network connection is determined;

[0051] If the estimated time window is less than the timeliness requirement, the target scheduling strategy is updated to delayed transmission.

[0052] If the estimated time window is greater than or equal to the timeliness requirement, the target scheduling strategy is updated to send immediately.

[0053] In one or more embodiments, the second determining module determines an estimated time window for the vehicle to restore network connectivity based on the real-time operating data and the vehicle's historical operating data, specifically for:

[0054] Based on the location data and vehicle speed data in the real-time operation data, the estimated position sequence of the vehicle within a preset time period is determined;

[0055] Based on the location data within the geofence data within the preset range, determine the estimated time corresponding to each location point in the estimated location sequence;

[0056] The estimated time window is determined based on the estimated time corresponding to each location point and the historical operation data.

[0057] In one or more embodiments, the target attribute data further includes: message type, and the target scheduling strategy is delayed batching;

[0058] Accordingly, the processing module processes the message to be processed according to the target scheduling strategy, specifically for:

[0059] Obtain at least one other message that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the message to be processed, and classify the message to be processed and the at least one other message to be processed as messages of the same type;

[0060] The batch time window is started with the timestamp of the first message of the same type entering the batch queue as the starting point;

[0061] When the batch time window expires, the payloads of similar messages in the batch queue are merged into the same JSON array and deduplicated.

[0062] The merged and deduplicated loads are then sent to the vehicle.

[0063] In one or more embodiments, before determining the target scheduling strategy for issuing the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located, the second determining module is further configured to:

[0064] Based on the real-time operating data and the preset scene recognition strategy, at least one driving scene in which the vehicle is located is determined. The scene recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds.

[0065] According to a preset priority strategy, the target driving scenario is determined in the at least one driving scenario, wherein the priority strategy records at least one driving scenario arranged in priority order.

[0066] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0067] The memory stores computer-executed instructions;

[0068] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0070] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0071] This application provides a message scheduling method, apparatus, electronic device, and storage medium. The method determines the target attribute data of a message to be processed (a message sent from the cloud to a vehicle). Based on the target attribute data and the target driving scenario of the vehicle, a target scheduling strategy for sending the message to be processed is determined. The target scheduling strategy indicates the timing, method, and / or quality of service level of the message to be processed. The target driving scenario is determined based on real-time operational data uploaded by the vehicle. The message to be processed is then processed according to the target scheduling strategy. This solution determines the target scheduling strategy for sending the message to be processed by jointly using the target attribute data of the message to be processed and the target driving scenario of the vehicle. This allows the scheduling decision to simultaneously consider the importance of the message itself and the vehicle's current actual operating environment, avoiding the one-sidedness of single-dimensional decision-making. By processing the message to be processed through the target scheduling strategy, the determined scheduling decision is implemented, enabling the message to be processed to adaptively match the vehicle's movement state and network conditions, improving the reliability and timeliness of message transmission. Attached Figure Description

[0072] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0073] Figure 1 A schematic diagram of the structure of a message scheduling system provided in the embodiments of this application;

[0074] Figure 2 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 1 ;

[0075] Figure 3 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 2 ;

[0076] Figure 4 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 3 ;

[0077] Figure 5 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 4 ;

[0078] Figure 6 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 5 ;

[0079] Figure 7 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 6 ;

[0080] Figure 8 A schematic diagram of the structure of a message scheduling device provided in the embodiments of this application;

[0081] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0082] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0083] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0084] With the rapid development of intelligent connected vehicles, message communication between vehicles and the cloud has become a core component of the Internet of Vehicles (IoV) system. The MQTT protocol, with its lightweight nature, low bandwidth consumption, support for publish / subscribe modes, and built-in three-level QoS, has become the mainstream protocol for vehicle-to-cloud communication in the IoV field.

[0085] In a typical vehicle-to-everything (V2X) platform architecture, the cloud sends various command messages to the vehicle via the MQTT protocol, including: remote vehicle control commands (such as turning on the air conditioner and unlocking the doors), OTA upgrade notifications, intelligent recommended configuration distribution, and vehicle data collection requests.

[0086] Meanwhile, the vehicle reports real-time location (GPS / BeiDou positioning data), vehicle status (speed, battery level, mileage), alarm information and other data to the cloud via the MQTT protocol.

[0087] However, as high-speed mobile communication nodes, vehicles experience drastic fluctuations in their network environment depending on the driving scenario. For example, the network signal is good when a vehicle is driving steadily on a highway, but it weakens sharply or even drops completely when entering an underground parking garage or tunnel, and may frequently switch between strong and weak signals in congested urban areas.

[0088] Current vehicle-to-everything (V2X) MQTT message scheduling solutions typically employ static configuration: all message types are assigned a fixed QoS level (such as QoS 1 or QoS 2), all offline vehicles are restored using SMS wakeup, and all messages are sent sequentially according to a fixed priority queue.

[0089] This one-size-fits-all static scheduling strategy cannot adapt to the dynamic changes in vehicle driving scenarios, leading to the following technical problems:

[0090] Technical Issue 1) When the network is unstable, the retransmission mechanism for high QoS level messages causes a large amount of unnecessary network overhead and message delay;

[0091] Technical Issue 2) When a vehicle briefly enters a signal blind spot (e.g., underground parking lot, tunnel), immediately triggering SMS wake-up not only incurs unnecessary SMS charges, but also causes wake-up failure because the vehicle has not yet left the blind spot;

[0092] Technical Issue 3) The timeliness of messages and their relevance to driving scenarios were not taken into account, resulting in emergency messages (such as safety alarms) not being given priority in weak network scenarios, while non-emergency messages (such as configuration updates) consume too many resources in high-quality network scenarios.

[0093] Accordingly, in response to the technical problems existing in the prior art, the technical concept of this application is as follows: Since the operational data such as vehicle location, speed and operating status can reflect the current network connection environment between the vehicle and the cloud and its changing trends, by using real-time operational data as the basis for scenario judgment, first identifying the driving scenario in which the vehicle is located, and then combining the attribute data of the message to be processed to determine the message processing method, the scheduling logic can be transformed from static rules to dynamic decision-making that adjusts with changes in vehicle and network conditions. Based on this, it can be inferred whether the message is more suitable to be sent immediately, sent later, or processed using different reliability levels, thereby improving the adaptability of message scheduling in dynamic network environments.

[0094] Based on the above technical concepts and technical issues... Figure 1 This is a schematic diagram of the structure of the message scheduling system provided in the embodiments of this application, as shown below. Figure 1 As shown, the system includes: Module 1: Operational Data Acquisition Module; Module 2: Driving Scene Recognition Module; Module 3: Adaptive Scheduling Decision Module; and Module 4: Message Execution Module.

[0095] The system includes a data acquisition module for acquiring vehicle-reported operational data and caching it in real time (e.g., storing it in Redis, MySQL, or RocksDB), then sending the operational data to the driving scenario recognition module. This module determines the corresponding target driving scenario based on a scenario recognition rule base (i.e., a scenario recognition strategy carrying geofence data). The adaptive scheduling decision module, upon acquiring the target driving scenario, determines the corresponding target scheduling strategy based on a scheduling decision matrix (i.e., a scheduling mapping relationship carrying priorities). The message execution module schedules specific messages (i.e., messages to be processed) based on this target scheduling strategy, such as using an MQTT Broker or SMS gateway.

[0096] Among them, persistent database storage (MySQL, RocksDB) serves as the underlying storage for the offline message queue, preventing offline messages from being lost due to system restarts.

[0097] It should be understood that the schematic diagram is only a simple description of the solution involved in the embodiments of this application, and the details not described in detail can be found in the following embodiments.

[0098] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0099] It should be understood that this method is applied to electronic devices, which can be the cloud server corresponding to the vehicle.

[0100] Figure 2 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method includes:

[0101] Step 21: Determine the target attribute data of the message to be processed;

[0102] Among them, the messages to be processed are the messages that the cloud will send to the vehicle;

[0103] In this step, the messages to be processed can be message objects that have entered the cloud scheduling process but have not yet been sent to the vehicle, such as remote vehicle control commands, vehicle status query requests, alarm notifications, upgrade task distribution notifications, result feedback messages, etc.

[0104] Optionally, for any message, the message may include: message type, business priority, and timeliness requirements; correspondingly, the message to be processed may also include: message type, business priority, and timeliness requirements (detailed in the following embodiments).

[0105] In one possible implementation, the target attribute data can be extracted directly from the message template or message metadata pre-stored in the cloud; alternatively, when a request to generate a message to be processed is received in the cloud, the target attribute data can be generated based on the message content, the message source interface, and the results returned by the business rule engine.

[0106] Step 22: Determine the target scheduling strategy for sending messages to be processed based on the target attribute data and the target driving scenario in which the vehicle is located;

[0107] The target scheduling strategy is used to indicate the timing, method, and / or quality of service level of the message to be processed. The target driving scenario is determined based on the real-time operation data uploaded by the vehicle.

[0108] In this step, the real-time operational data is a set of data reported periodically by the vehicle through the vehicle-to-everything (V2X) link or triggered by events, which is used to reflect the vehicle's current operating trajectory and operating status.

[0109] Furthermore, after obtaining the target attribute data, the system reads the real-time operation data reported by the vehicle and determines the target driving scenario in which the vehicle is currently located based on the real-time operation data. After determining the target driving scenario, the system makes a joint decision based on the target attribute data and the target driving scenario to determine the target scheduling strategy.

[0110] Among them, the Quality of Service (QoS) level is used to characterize the reliability control requirements during message transmission.

[0111] In one possible implementation, Table 1 is a table showing the corresponding collection fields for the running data provided in the embodiments of this application. The description of the collection fields for any one piece of running data is shown in Table 1:

[0112] Table 1

[0113]

[0114] Optional, target attribute data includes: business priority.

[0115] Accordingly, the implementation of step 22 may include: determining the target scheduling strategy in the preset scheduling mapping relationship based on the business priority and the target driving scenario;

[0116] The scheduling mapping relationship records the correspondence between different priorities, different driving scenarios, and different scheduling strategies.

[0117] In this implementation, the scheduling mapping relationship is pre-stored in the cloud. It is associated with different priorities, different driving scenarios, and different scheduling strategies. After receiving a message to be processed, the business priority corresponding to the message to be processed is first parsed, and then the target driving scenario identified by the real-time vehicle operation data is obtained. Based on this, the scheduling strategy that matches both of them is retrieved in the mapping relationship and used as the target scheduling strategy.

[0118] Examples can be found in Table 3 below.

[0119] For example, different driving scenarios include at least one of the following: underground parking garage weak network scenario, tunnel weak network scenario, parking and dormancy scenario, urban congestion scenario, highway stable scenario, and other scenarios (e.g., default scenario, which does not belong to the above other items, can be used as the default scenario).

[0120] For example, different priorities include at least one of the following: urgent, important, normal, and non-urgent;

[0121] In one possible implementation, Table 2 is a priority correspondence table provided by the embodiments of this application, as shown in Table 2:

[0122] Table 2

[0123]

[0124] For example, the scheduling strategy corresponding to each driving scenario and each priority includes any one of the following: immediate sending, delayed sending, buffering and waiting, delayed batching, SMS wake-up, MQTT wake-up, and waiting for self-recovery;

[0125] Among them, the scheduling policy corresponding to at least one driving scenario and at least one priority carries a preset quality of service level (i.e., QoS 0, QoS 1, and QoS 2).

[0126] In one possible implementation, Table 3 is a scheduling mapping relationship correspondence table provided by the embodiments of this application, as shown in Table 3:

[0127] Table 3

[0128]

[0129] In other words, QoS can be left unset for non-urgent priority scenarios such as underground parking garage weak network scenarios, tunnel weak network scenarios, and parking hibernation scenarios.

[0130] Optionally, for scheduling strategies marked as cache waiting or waiting for self-recovery, QoS may not be set because the messages to be processed are not sent immediately; QoS will be re-determined based on the driving scenario and scheduling strategy at the time of actual sending.

[0131] Accordingly, in one possible implementation, Table 4 is a table showing the scheduling strategies provided in the embodiments of this application, as shown in Table 4:

[0132] Table 4

[0133]

[0134] For MQTT wake-up, a precondition can be set: the TBOX maintains a long MQTT connection by using the Session Present flag of the MQTT Broker (i.e., Clean Session=0 in the CONNECT message and Session Present=1 in the Broker's CONNACK response); if Session Present=0 (TBOX is completely offline), then MQTT wake-up is unavailable and should be downgraded to SMS wake-up or wait for self-recovery strategy.

[0135] Optionally, a multi-factor weighted scoring model can be adopted: assign weights to three dimensions, namely driving scenario (network quality), message priority, and message timeliness requirements, and obtain a comprehensive scheduling score by weighted summation, and then map the score range to the corresponding QoS level and sending strategy.

[0136] Step 23: Process the messages to be processed according to the target scheduling strategy.

[0137] In this step, the target scheduling strategy is the executable control result output in step 22 above. It can indicate the specific action path of the message to be processed in the sending and execution phase. Based on the specific action path, the message to be processed is processed so that the vehicle can obtain the message to be processed.

[0138] Here are some possible processing implementations as examples (examples only):

[0139] 1) When the target scheduling policy indicates delayed transmission, the message is not immediately sent through the vehicle communication channel. Instead, the message to be processed, along with the target scheduling policy and the expected transmission time (i.e., the preset time window), is written into the delay queue or cache database. After the expected transmission time is reached, the message to be processed is reread and the scenario is verified in conjunction with the latest real-time vehicle operation data. If the policy conditions are met, the transmission is executed. If the driving scenario has changed, the target scheduling policy can be redefined based on the latest driving scenario before processing is executed.

[0140] 2) When the target scheduling policy indicates that the cache is waiting, the message to be processed can be saved to the cache pool with the vehicle identifier as the dimension, and the release condition can be registered for the message to be processed. During the caching period, the vehicle target driving scenario is continuously updated according to the real-time running data uploaded by the vehicle. Once the release condition is detected to be met, the corresponding message to be processed is retrieved from the cache pool and sent or enters a new policy calculation process. If the message to be processed exceeds the allowed processing time limit during the caching period, the message to be processed is marked as expired and the processing ends.

[0141] 3) When the target scheduling policy indicates wake-up related processing, first determine whether the wake-up trigger condition is met; if it is met, trigger wake-up to the vehicle through the corresponding channel; after wake-up is completed or the vehicle is detected to be online, execute the delivery of pending messages according to the service quality level in the target scheduling policy; if it is not met, retain the pending messages and execute delivery when the conditions are met later.

[0142] In addition, after the pending messages are processed, the processing results can be written to the message processing record, including: the final target driving scenario, target scheduling strategy, actual sending time, number of sending times, receipt results, whether wake-up was required, and reasons for failure.

[0143] Optionally, before any sending operation is performed, the timeliness requirements of the message to be processed (e.g., maximum tolerable delay time) are checked. The waiting time T_wait for the message to be processed is calculated. If T_wait has exceeded the maximum tolerable delay time, the message to be processed is determined to have expired.

[0144] The handling strategy for expired messages is as follows: For expired important and urgent messages (priority levels 1-2), we will still attempt to send them immediately with QoS 0 (make every effort to deliver them, but do not trigger retransmission or wake-up); for expired ordinary and non-urgent messages (priority levels 3-4), we will discard them directly and record the expiration log.

[0145] The message scheduling method provided in this application determines the target attribute data of the message to be processed, which is a message that the cloud will send to the vehicle. Based on the target attribute data and the target driving scenario in which the vehicle is located, a target scheduling strategy for sending the message to be processed is determined. The target scheduling strategy indicates the timing, method, and / or quality of service level of the message to be processed. The target driving scenario is determined based on real-time operating data uploaded by the vehicle. The message to be processed is then processed according to the target scheduling strategy. This solution determines the target scheduling strategy for sending the message to be processed by jointly using the target attribute data of the message to be processed and the target driving scenario in which the vehicle is located. This allows the scheduling decision to simultaneously consider the importance of the message itself and the vehicle's current actual operating environment, avoiding the one-sidedness of a single-dimensional decision. By processing the message to be processed through the target scheduling strategy, the determined scheduling decision is implemented, enabling the message to be processed to adaptively match the vehicle's movement state and network conditions, improving the reliability and timeliness of message transmission.

[0146] Based on the above embodiments, the target attribute data also includes: timeliness requirements; and the target scheduling strategy is delayed transmission or buffering.

[0147] but, Figure 3 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 2 ,like Figure 3 As shown, prior to step 23, the method further includes:

[0148] Step 31: Determine the estimated time window for restoring the vehicle's network connection based on real-time operating data and the vehicle's historical operating data;

[0149] In this step, the time it takes for a vehicle to restore its network connection can be estimated based on real-time operational data uploaded by the vehicle and combined with historical operational data. This estimate can be obtained through rule matching, regression prediction, or statistical window analysis and output as a predicted time window.

[0150] Optionally, step 31 may include:

[0151] Step 1: Based on the location data and vehicle speed data in the real-time operation data, determine the estimated position sequence of the vehicle within the future preset time period;

[0152] In this implementation, based on the vehicle's current location data (e.g., longitude lon, latitude lat) and speed data (e.g., speed v (km / h) and direction of travel theta (degrees)), a preset uniform motion model is used. With a time step delta_t = 5 seconds and an estimated number of steps N = 60 (i.e., estimating the position within a preset time period, such as 5 minutes), the estimated position sequence can be calculated using the following formula:

[0153] lon_i=lon+i×delta_t×v×cos(theta) / 111320;

[0154] lat_i=lat+i×delta_t×v×sin(theta) / 110540.

[0155] Where i = 1, 2, ..., N, 111320 and 110540 are the approximate values ​​in meters corresponding to 1 degree of longitude and 1 degree of latitude, respectively, and can be adjusted according to the actual situation.

[0156] In addition, for scenarios where the vehicle speed is zero or below 5 km / h (such as parking scenarios), correction steps based on historical operating data can be performed directly.

[0157] Step 2: Based on the location data within the geofence data of the preset range, determine the estimated time corresponding to each location point in the estimated location sequence;

[0158] In this implementation, each location point (lon_i, lat_i) in the estimated location sequence is matched with geofence data within a preset range indicated by the location data, such as a geofence database. This geofence database can pre-store the polygon boundary coordinates of known signal blind spots (e.g., basement exit, tunnel exit, signal blind spot boundary). Each fence record contains a fence ID, fence type (exit / boundary), and a list of polygon vertex coordinates.

[0159] At this point, the matching algorithm uses the ray casting method: a ray is emitted from the point to be determined in any direction, and the number of intersections between the ray and the edge of the fence polygon is counted. If the number of intersections is odd, the point is determined to be inside the fence; if the number of intersections is even, the point is determined to be outside the fence.

[0160] If a location point lon_i falls within the fence of a signal blind zone exit, then record the estimated time t_i = i × delta_t corresponding to that location point.

[0161] Step 3: Determine the estimated time window based on the estimated time and historical operation data corresponding to each location point.

[0162] In this implementation, if a location point matches the exit of the signal blind zone, the earliest estimated time t_min is taken as the candidate time window for reconnection, that is, the vehicle is expected to drive out of the signal blind zone after t_min seconds.

[0163] If no location point matches the exit fence, but some location points still fall within the signal blind zone boundary fence, then the estimated time t_last corresponding to the last location point falling within the blind zone is taken as a conservative estimate of the candidate time window.

[0164] If none of the estimated location points are within any signal blind zone fence, the current driving scenario is determined to be a short-term network fluctuation, and the candidate time window takes the default value (e.g., 30 seconds).

[0165] Furthermore, the candidate time windows identified above can be updated by combining historical operational data to obtain the estimated time windows.

[0166] That is, if the vehicle's historical operation data indicates that there is a frequently traveled route (e.g., the number of historical trajectory records (e.g., N) in the same time period plus or minus 1 hour and in the same direction of origin and destination is greater than or equal to 3), then the K historical trajectories most similar to the current trajectory are retrieved from the historical operation data (K=5, and the similarity measure can be a weighted comprehensive score of the Euclidean distance between the origin and destination and the direction angle difference), and the average time of these K historical trajectories passing through the signal blind zone is used as the historical passage time T_hist.

[0167] The final connection recovery time window is set to T_final=max(t_min, T_hist), which is the larger value between the candidate time window and the historical transit time, to ensure that the prediction results are conservative.

[0168] In addition, if no historical route data is available for the vehicle, the candidate time window can be used directly as the estimated time window.

[0169] Furthermore, it is also possible to evaluate the prediction confidence based on the estimated number of location points N_matched and the number of historical trajectory matches K_matched.

[0170] The confidence level is marked as high when N_matched / N is greater than or equal to the first value (e.g., 0.5) and K_matched is greater than or equal to the second value (e.g., 3); the confidence level is marked as medium when N_matched / N is greater than or equal to the first value or K_matched is greater than or equal to the third value (e.g., 1); otherwise, it is marked as low.

[0171] When the confidence level is low, the judgment of the estimated time window should be conservative: if the difference between the estimated time window and the message timeliness requirement is lower than the preset safety threshold (e.g., 30 seconds), it will not be handled according to the delay strategy, but will be upgraded to immediate sending and triggering a wake-up, in order to avoid the message expiring due to inaccurate prediction.

[0172] Optionally, a pattern matching method based on historical trajectory data in historical operation data can also be used: determine the K historical trajectories that are most similar to the current trajectory (starting point, direction, time period) from the historical trajectory data, and use the statistical characteristics of these historical trajectories (e.g., average transit time) as the estimated time window for reconnection.

[0173] Step 32: If the estimated time window is less than the timeliness requirement, update the target scheduling strategy to delayed transmission;

[0174] In this step, if the estimated time window is less than the timeliness requirement, it means that the vehicle can restore the connection quickly. The target scheduling policy is then updated to delayed sending, so that the messages to be processed enter the delayed delivery state before the connection is restored.

[0175] Step 33: If the estimated time window is greater than or equal to the timeliness requirement, update the target scheduling strategy to send immediately.

[0176] In this step, if the estimated time window is greater than or equal to the timeliness requirement, it means that waiting for recovery will exceed the timeliness period of the message to be processed. The target scheduling policy can be updated to send immediately, so that the message to be processed can be sent directly under the currently available channel.

[0177] The updated result then serves as the basis for executing pending messages, so that subsequent step 23 is executed based on it.

[0178] The message scheduling method provided in this application determines the estimated time window for vehicle network connection restoration based on real-time operating data and historical vehicle operating data. If the estimated time window is less than the timeliness requirement, the target scheduling strategy is updated to delayed sending; if the estimated time window is greater than or equal to the timeliness requirement, the target scheduling strategy is updated to immediate sending. This technical solution determines the estimated time window for vehicle network connection restoration by using real-time operating data and historical vehicle operating data, enabling the cloud to predict the future network reachability of the vehicle. If the estimated time window is less than the message's timeliness requirement, choosing delayed sending avoids invalid immediate delivery attempts when the vehicle's network is unreachable, saving network resources. If the estimated time window is greater than or equal to the timeliness requirement, choosing immediate sending, combined with a wake-up mechanism, makes every effort to deliver the message before it expires, avoiding message failure due to waiting for restoration.

[0179] Based on the above embodiments, the target attribute data also includes: message type; and the target scheduling strategy is delayed batching.

[0180] but, Figure 4 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 3 ,like Figure 4 As shown, step 23 may include:

[0181] Step 41: Obtain at least one other message to be processed that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the message to be processed, and classify the message to be processed and at least one other message to be processed as messages of the same type;

[0182] In this step, after determining that the target scheduling strategy is delayed batching, among all messages in the same vehicle (i.e., which can be determined based on VIN), messages with the same message type as the message to be processed and messages with the same MQTT Topic prefix (e.g., both published to the vehicle configuration topic) are recorded as at least one other message to be processed.

[0183] Then, treat the pending message and at least one other pending message as the same type of message.

[0184] Step 42: Start the batch time window with the timestamp of the first message of the same type entering the batch queue as the starting point;

[0185] In this step, since it is necessary to send the messages to be processed in batches, each message to be processed of the same type can be sent to the batch queue in real time. When the first message to be processed is received in the batch queue, the timing starts from the corresponding timestamp and the preset batch time window is started.

[0186] The batch time window executes subsequent batch distribution operations when the timer ends; for example, the duration of the batch time window can be set to 60 seconds.

[0187] Step 43: When the batch time window expires, merge the payloads of similar messages in the batch queue into the same JSON array and remove duplicates.

[0188] In this step, when the batch time window expires, the payloads of similar messages in the batch queue are merged into a single JSON array.

[0189] For example, the payloads of the messages to be processed are as follows:

[0190] {"key":"param1","value":1} and {"key":"param2","value":2};

[0191] The combined load is:

[0192] [{"key":"param1","value":1},{"key":"param2","value":2}],

[0193] Subsequently, the message is sent via a single MQTT PUBLISH message; the receiving end of the vehicle (e.g., TBOX) automatically determines whether the message is a batch merged message based on the JSON type (object or array) of the payload.

[0194] In addition, when the same configuration item is issued multiple times within a batch time window (e.g., the same parameter is modified multiple times), only the latest value of the configuration item is retained. That is, the value of the previous message is overwritten by the later message with the same key field to achieve deduplication.

[0195] Optionally, for configuration-related messages (with a key-value payload), the above deduplication rules can be executed; for non-configuration-related messages, deduplication can be omitted, and messages can be merged one by one in chronological order.

[0196] Step 44: Send the merged and deduplicated loads to the vehicles.

[0197] In this step, the merged and deduplicated payloads are sent to the vehicle via a single MQTT PUBLISH message.

[0198] In addition, if an urgent message (priority level 1) is received during the batch window and needs to be sent immediately, similar messages in the current batch queue will be merged and sent in advance without waiting for the batch window to expire, so as to avoid the urgent message being delayed by batch waiting.

[0199] The message scheduling method provided in this application involves obtaining at least one other message to be processed that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the message to be processed, and treating the message to be processed and at least one other message to be processed as messages of the same type; starting a batch time window with the timestamp of the first message of the same type entering the batch queue as the starting point; when the batch time window expires, merging the payloads of messages of the same type in the batch queue into the same JSON array and deduplicating them; and sending the merged and deduplicated payload to the vehicle. This technical solution accurately identifies and categorizes mergeable messages, avoiding the incorrect merging of unrelated messages. By starting the batch time window with the timestamp of the first message of the same type entering the batch queue as the starting point, a unified batch merging time benchmark is established, enabling multiple messages within the same window to be processed centrally. When the batch time window expires, the payloads of similar messages in the batch queue are merged into the same JSON array and deduplicated, reducing the number of times messages that originally needed to be sent independently multiple times. At the same time, deduplication avoids redundant sending of the same configuration item. By sending the merged and deduplicated payload to the vehicle, the content update of what would have been multiple messages can be completed in one processing at the receiving end, thereby improving the efficiency of batch message sending while ensuring message integrity.

[0200] Based on the above embodiments, Figure 5 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 4 ,like Figure 5 As shown, prior to step 22, the method may further include:

[0201] Step 51: Based on real-time operating data and preset scene recognition strategies, determine at least one driving scenario in which the vehicle is located;

[0202] The scene recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds.

[0203] In this step, after determining the real-time operating data, location data, vehicle status, and other data can be extracted from the real-time data. The extracted data is then judged using a scene recognition strategy to determine at least one driving scenario in which the vehicle is currently located.

[0204] If a driving scenario is identified, then that driving scenario is directly designated as the target driving scenario; if two or more driving scenarios are identified, then step 52 is executed.

[0205] Optionally, the scene recognition strategy records at least one driving scene and the judgment conditions for each driving scene.

[0206] In one possible implementation, Table 5 is a table showing the scene recognition strategies provided in the embodiments of this application, as shown in Table 5:

[0207] Table 5

[0208]

[0209] It should be understood that all the specific values ​​given above are just examples. In actual implementation, they can be set based on preset thresholds, such as system defaults, user settings, or specific values ​​given after summarizing vehicle data.

[0210] Step 52: Based on the preset priority strategy, determine the target driving scenario in at least one driving scenario;

[0211] The priority strategy records at least one driving scenario arranged in priority order.

[0212] In this step, after identifying at least one driving scenario, the at least one driving scenario is prioritized according to the priority order in the priority strategy, and the driving scenario with the highest priority is taken as the target driving scenario.

[0213] For example, the driving scenarios with the highest priority recorded in the priority strategy are: underground parking garage weak network scenario > tunnel weak network scenario > parking and dormant scenario > urban congestion scenario > highway stable scenario > other scenarios (default scenario).

[0214] Optionally, driving scenario recognition can also be based on a lightweight machine learning model (such as a decision tree or random forest classifier). The lightweight machine learning model is trained using multiple historical driving data of the vehicle and the labeled driving scenario corresponding to each historical driving data. In actual use, the target driving scenario can be obtained by directly inputting real-time driving data.

[0215] The message scheduling method provided in this application determines at least one driving scenario of a vehicle based on real-time operating data and a preset scenario recognition strategy. The scenario recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds. A target driving scenario is determined from at least one driving scenario according to a preset priority strategy. The priority strategy records at least one driving scenario arranged in priority order. This technical solution determines at least one driving scenario of a vehicle using real-time operating data and a preset scenario recognition strategy. It can utilize the real-time operating data uploaded by the vehicle to make a multi-dimensional preliminary judgment of the current environment, providing a candidate set for subsequent scenario selection. Then, by using the at least one driving scenario arranged in priority order recorded in the priority strategy, the selection of the target scenario becomes deterministic and predictable, providing a reliable input basis for matching subsequent message scheduling strategies.

[0216] Based on the above embodiments, Figure 6 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 5 ,like Figure 6 As shown, one possible implementation example of this method could be:

[0217] Step 61: Real-time data collection during operation;

[0218] Step 62: Real-time driving scenario recognition (determined based on scenario recognition strategy);

[0219] Step 63: Determine the message scheduling strategy (based on the scheduling mapping relationship);

[0220] Step 64: Process pending messages based on scheduling strategies (including immediate sending, delayed sending, buffering and waiting, delayed batch processing, SMS wake-up, MQTT wake-up, and waiting for self-recovery, etc.; and updating the scheduling strategy based on trajectory prediction).

[0221] Example:

[0222] If the scheduling policy is to send immediately, the message to be processed will be sent immediately through the MQTT Broker according to the QoS level of the scheduling policy.

[0223] If the scheduling strategy is delayed sending, the message to be processed is added to the delayed sending queue, a delay timer is set, and the vehicle scene status is rechecked after the timer expires. If the scene has improved, the message is sent immediately; otherwise, the delay or downgrade processing continues.

[0224] If the scheduling strategy is to wait in a cache, the messages to be processed will be stored in an offline message queue and sent out in batches after the vehicle reconnects (the vehicle goes online event is received).

[0225] If the scheduling strategy is SMS wake-up, a wake-up SMS is sent to the vehicle's TBOX (Telematics Box, vehicle communication terminal) through the SMS gateway, and a polling timer is started to monitor the vehicle's online status. Once online, pending messages are sent out immediately.

[0226] If the scheduling strategy is MQTT wake-up, then a wake-up command is sent to the vehicle TBOX via the MQTT Broker (suitable for scenarios where the TBOX maintains a long MQTT connection but the application layer is in sleep mode).

[0227] Step 65: Scene switching process;

[0228] Example:

[0229] When a change in the vehicle's driving scenario is detected (e.g., from a weak network scenario in the underground parking garage to the default scenario), the scenario switching process is triggered:

[0230] (a) Check if there are any cached messages in the vehicle's offline message queue and delayed delivery queue;

[0231] (b) If so, these messages are re-entered into the scheduling decision module to re-determine the QoS level and transmission strategy for the new scenario after the switch;

[0232] (c) If the new scheduling policy is to send immediately, then send immediately; if the new scheduling policy is still to wait in a buffer or send with a delay, then keep it in the queue.

[0233] This mechanism ensures that after a vehicle leaves a signal blind spot, cached messages can be delivered promptly under the optimal scheduling strategy, preventing messages from remaining in the queue for too long and exceeding timeliness requirements.

[0234] Step 66: Message TTL expiration check;

[0235] Example:

[0236] Before sending the message, you can check the timeliness requirements of the message to be processed (e.g., set the maximum tolerable delay time) and calculate the waiting time T_wait from when the message enters the schedule to the current time. If T_wait has exceeded the maximum tolerable delay time of the message, the message is determined to have expired.

[0237] The strategy for handling expired messages can be as follows: For expired important and urgent messages (priority levels 1-2), still attempt to send them immediately with QoS 0 (make every effort to deliver them, but do not trigger retransmission or wake-up); for expired ordinary and non-urgent messages (priority levels 3-4), discard them directly and record the expiration log.

[0238] This mechanism prevents expired pending messages from consuming network and resources, while also preventing vehicles from receiving outdated instructions.

[0239] Step 67: Message delivery complete.

[0240] Based on the above embodiments, Figure 7 A flowchart illustrating the message scheduling method provided in this application embodiment. Figure 6 ,like Figure 7 As shown, a message scheduling sequence diagram for a basement scenario can be:

[0241] The entities involved in the execution include electronic devices (including the TSP platform, driving scenario recognition module, and adaptive scheduling decision module, etc.) and vehicles.

[0242] Step 701: The TSP platform reports the operating data to the driving scene recognition module;

[0243] Step 702: The driving scenario recognition module identifies the weak network scenario in the underground parking garage based on the operating data;

[0244] Step 703: The TSP platform sends the message to be processed to the adaptive scheduling decision module;

[0245] Step 704: The adaptive scheduling decision module determines whether to delay transmission for QoS 1 or buffer and wait for QoS 0 based on the scheduling mapping relationship;

[0246] Step 705: Based on trajectory prediction, the TSP platform determines that the vehicle will exit the underground parking garage in 3 minutes.

[0247] Step 706: The driving scene recognition module determines the scene to switch (exiting the underground parking garage).

[0248] Step 707: The driving scene recognition module notifies the adaptive scheduling decision module of scene switching;

[0249] Step 708: The adaptive scheduling decision module re-decides and immediately issues the cache;

[0250] Step 709: The adaptive scheduling decision module sends the message to the vehicle immediately based on QoS 1 or QoS 2.

[0251] Step 710: The TSP platform sends an ACK response to the vehicle upon receiving the detection message.

[0252] It should be understood that the execution of steps 701 to 710 is in chronological order.

[0253] The message scheduling method provided in this application embodiment has the following technical effects:

[0254] Technical Effect 1) Improved Message Delivery Rate: By dynamically adjusting QoS levels and sending strategies based on driving scenario perception, the problem of high QoS level messages being lost due to repeated retransmission failures in weak network scenarios is avoided. In the weak network scenario of an underground parking garage, emergency messages are downgraded to QoS 1 and coupled with offline caching, and are immediately resent after the vehicle leaves the garage, thus significantly improving the expected message delivery rate.

[0255] Technical benefit 2) Reduced SMS wake-up cost: By predicting the estimated time window for vehicle reconnection through trajectory prediction, unnecessary SMS wake-ups are avoided when vehicles briefly enter signal blind spots. Based on an average reduction of one unnecessary SMS wake-up per vehicle per day and an SMS cost of approximately 0.05 yuan per message, a fleet of 100,000 vehicles could save approximately 1.8 million yuan in SMS costs annually.

[0256] Technical effect 3), reducing message transmission latency: In high-speed and stable scenarios, urgent messages are automatically upgraded to QoS2 to ensure reliable delivery, while non-urgent messages are kept at QoS0 to reduce unnecessary acknowledgment (ACK) interactions, and the overall average message latency is expected to be significantly reduced;

[0257] Technical effect 4) Reduce network bandwidth waste: In urban congestion scenarios, a delayed batch merging strategy is adopted for non-urgent messages, which aggregates multiple similar messages into a batch for unified distribution, reducing the message header overhead of the MQTT protocol and the number of Transmission Control Protocol (TCP) connection interactions, and is expected to save a significant amount of downlink bandwidth.

[0258] Technical effect 5) Improved system scalability: The scheduling decision matrix adopts a configurable design. When adding a new driving scenario or adjusting the scheduling strategy, only the configuration needs to be updated without modifying the code, which facilitates continuous iterative optimization of the system.

[0259] Figure 8 This is a schematic diagram of the structure of the message scheduling device provided in the embodiments of this application, as shown below. Figure 8 As shown, the message scheduling device includes:

[0260] The first determining module 81 is used to determine the target attribute data of the message to be processed, which is the message that the cloud will send to the vehicle.

[0261] The second determining module 82 is used to determine the target scheduling strategy for sending messages to be processed based on the target attribute data and the target driving scenario in which the vehicle is located. The target scheduling strategy is used to indicate the timing, method and / or quality of service level of the messages to be processed. The target driving scenario is determined based on the real-time operation data uploaded by the vehicle.

[0262] The processing module 83 is used to process the messages to be processed according to the target scheduling strategy.

[0263] In one or more embodiments, the target attribute data includes: business priority;

[0264] Correspondingly, the second determining module 82, based on the target attribute data and the target driving scenario in which the vehicle is located, determines the target scheduling strategy for issuing messages to be processed, specifically for:

[0265] Based on business priorities and target driving scenarios, the target scheduling strategy is determined from the preset scheduling mapping relationship;

[0266] The scheduling mapping relationship records the correspondence between different priorities, different driving scenarios, and different scheduling strategies.

[0267] In one or more embodiments, different driving scenarios include at least one of the following: underground parking garage weak network scenario, tunnel weak network scenario, parking and dormancy scenario, urban congestion scenario, high-speed stable scenario, and other scenarios;

[0268] Different priorities include at least one of the following: urgent, important, normal, and non-urgent;

[0269] The scheduling strategy corresponding to each driving scenario and each priority includes any one of the following: immediate sending, delayed sending, buffering and waiting, delayed batching, SMS wake-up, MQTT wake-up, and waiting for self-recovery;

[0270] Among them, the scheduling strategy corresponding to at least one driving scenario and at least one priority carries a preset service quality level.

[0271] In one or more embodiments, the target attribute data further includes: timeliness requirements, and the target scheduling strategy is delayed transmission or buffering and waiting;

[0272] Accordingly, before processing the message to be processed according to the target scheduling strategy, the second determining module 82 is also used for:

[0273] Based on real-time operational data and historical vehicle operational data, the estimated time window for restoring the vehicle's network connection is determined;

[0274] If the estimated time window is less than the timeliness requirement, update the target scheduling strategy to delayed transmission;

[0275] If the estimated time window is greater than or equal to the timeliness requirement, update the target scheduling strategy to send immediately.

[0276] In one or more embodiments, the second determining module 82 determines an estimated time window for the vehicle to restore its network connection based on real-time operating data and historical operating data of the vehicle, specifically for:

[0277] Based on the location and speed data in the real-time operation data, determine the estimated position sequence of vehicles within a preset time period in the future;

[0278] Based on the location data within the geofence data of the preset range, determine the estimated time corresponding to each location point in the estimated location sequence;

[0279] The estimated time window is determined based on the estimated time and historical operation data corresponding to each location point.

[0280] In one or more embodiments, the target attribute data further includes: message type, and the target scheduling strategy is delayed batching;

[0281] Correspondingly, processing module 83 processes the message to be processed according to the target scheduling strategy, specifically for:

[0282] Retrieve at least one other pending message that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the pending message, and classify the pending message and at least one other pending message as messages of the same type;

[0283] Start the batch time window with the timestamp of the first message of the same type to enter the batch queue as the starting point;

[0284] When the batch time window expires, the payloads of similar messages in the batch queue are merged into the same JSON array and deduplicated.

[0285] The merged and deduplicated loads are then sent to the vehicles.

[0286] In one or more embodiments, before determining the target scheduling strategy for issuing messages to be processed based on target attribute data and the target driving scenario in which the vehicle is located, the second determining module 82 is further configured to:

[0287] Based on real-time operating data and a preset scene recognition strategy, at least one driving scene in which the vehicle is located is determined. The scene recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds.

[0288] According to a preset priority strategy, a target driving scenario is determined in at least one driving scenario. The priority strategy records at least one driving scenario arranged in priority order.

[0289] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical element, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls, or entirely in hardware. Alternatively, some modules can be implemented through processing element calls in software, while others can be implemented in hardware. Moreover, these modules can be integrated together or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0290] As can be seen from the above, the message scheduling device provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.

[0291] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device provided in this embodiment includes at least one processor 91 and a memory 92.

[0292] Optionally, the electronic device also includes a communication component 93.

[0293] The processor 91, memory 92, and communication component 93 are connected via bus 94.

[0294] In a specific implementation, at least one processor 91 executes computer execution instructions stored in memory 92, causing at least one processor 91 to perform the above-described method.

[0295] The specific implementation process of processor 91 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0296] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0297] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0298] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0299] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0300] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0301] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0302] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0303] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0304] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0305] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0306] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0307] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0308] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A message scheduling method, characterized in that, include: Determine the target attribute data of the message to be processed, which is a message that the cloud will send to the vehicle; Based on the target attribute data and the target driving scenario in which the vehicle is located, a target scheduling strategy for sending the message to be processed is determined. The target scheduling strategy is used to indicate the timing, method, and / or quality of service level of the message to be processed. The target driving scenario is determined based on the real-time operating data uploaded by the vehicle. The messages to be processed are processed according to the target scheduling strategy.

2. The method according to claim 1, characterized in that, The target attribute data includes: business priority; Accordingly, determining the target scheduling strategy for sending the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located includes: Based on the business priority and the target driving scenario, the target scheduling strategy is determined in a preset scheduling mapping relationship, which records the correspondence between different priorities, different driving scenarios, and different scheduling strategies.

3. The method according to claim 2, characterized in that, The different driving scenarios include at least one of the following: underground parking garage weak network scenario, tunnel weak network scenario, parking and dormancy scenario, urban congestion scenario, highway stability scenario, and other scenarios; The different priorities include at least one of the following: urgent, important, normal, and non-urgent; The scheduling strategy corresponding to each driving scenario and each priority includes any one of the following: immediate sending, delayed sending, buffering and waiting, delayed batching, SMS wake-up, MQTT wake-up, and waiting for self-recovery; Among them, the scheduling strategy corresponding to at least one driving scenario and at least one priority carries a preset service quality level.

4. The method according to claim 3, characterized in that, The target attribute data also includes: timeliness requirements, and the target scheduling strategy is delayed transmission or buffering and waiting; Accordingly, before processing the message to be processed according to the target scheduling strategy, the method further includes: Based on the real-time operating data and the vehicle's historical operating data, the estimated time window for the vehicle to restore its network connection is determined; If the estimated time window is less than the timeliness requirement, the target scheduling strategy is updated to delayed transmission. If the estimated time window is greater than or equal to the timeliness requirement, the target scheduling strategy is updated to send immediately.

5. The method according to claim 4, characterized in that, The step of determining the estimated time window for the vehicle to restore network connectivity based on the real-time operating data and the vehicle's historical operating data includes: Based on the location data and vehicle speed data in the real-time operation data, the estimated position sequence of the vehicle within a preset time period is determined; Based on the location data within the geofence data within the preset range, determine the estimated time corresponding to each location point in the estimated location sequence; The estimated time window is determined based on the estimated time corresponding to each location point and the historical operation data.

6. The method according to any one of claims 3-5, characterized in that, The target attribute data also includes: message type, and the target scheduling strategy is delayed batch processing; Accordingly, processing the message to be processed according to the target scheduling strategy includes: Obtain at least one other message that belongs to the same vehicle, the same message type, and the same MQTT Topic prefix as the message to be processed, and classify the message to be processed and the at least one other message to be processed as messages of the same type; The batch time window is started with the timestamp of the first message of the same type entering the batch queue as the starting point; When the batch time window expires, the payloads of similar messages in the batch queue are merged into the same JSON array and deduplicated. The merged and deduplicated loads are then sent to the vehicle.

7. The method according to any one of claims 1-5, characterized in that, Before determining the target scheduling strategy for issuing the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located, the method further includes: Based on the real-time operating data and the preset scene recognition strategy, at least one driving scene in which the vehicle is located is determined. The scene recognition strategy is determined based on communication signals, vehicle speed thresholds, location, vehicle status, and / or duration thresholds. According to a preset priority strategy, the target driving scenario is determined in the at least one driving scenario, wherein the priority strategy records at least one driving scenario arranged in priority order.

8. A message scheduling device, characterized in that, include: The first determining module is used to determine the target attribute data of the message to be processed, which is a message that the cloud will send to the vehicle. The second determining module is used to determine the target scheduling strategy for sending the message to be processed based on the target attribute data and the target driving scenario in which the vehicle is located. The target scheduling strategy is used to indicate the timing, method and / or quality of service level of the message to be processed. The target driving scenario is determined based on the real-time operation data uploaded by the vehicle. The processing module is used to process the message to be processed according to the target scheduling strategy.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images